Uml Doesnt Work For Design

Supposedly, UML is for design. At least that's what the UmlCaseVultures say. Their idea is that you slap up a big chart with all your class dependencies, and/or all your states, and/or all your sequences, and/or all your packages and/or ... and just by eye you pick out where there are redundancies and cycles and demeteric problems and so on. If you don't have time to slap it up they'll reverse-engineer your code and slap it up for you ...

Now the trouble is UmlHasNeitherSemanticsNorMetrics and AutomaticVisualizationDoesntWork ... so for any system of scale you're going to find it impossible to figure out which of those bubbles and lines are in a good place and which are in a bad place. The UML diagrams indicate only topological relationships, and humans are notoriously bad at separating topology from the covering in which it is embedded.

Worse, these spiderweb diagrams make it impossible to understand the true topology of the system because they don't have enough representative power to distinguish all the various patterns and relationships that exist in the source.

If we do XP, then we have a pretty good idea about WhenToRefactorWhenToSpike. But then the UmlCaseVultures claim their diagrams help us see opportunities to do this. Or, worse, that they help inexperienced programmers see opportunities to do this.

There has never been any occasion, anywhere, where this has worked. Instead the inexperienced programmers waste time trying to move things around on the page to reflect their (the programmers') purely internal and projective interpretation of the spiderwebs. They have big fussy meetings where they argue about their interpretations. But they can't document any agreements because UML gives them no way to do that. They go away with individual intents to deploy changes and extensions consistent with their undocumented resolutions ... then they come back with new wall-covering ambiguous projective diagrams and get still more confused.

Eventually some one of them thinks through an ArchitectureDiagram?. Or if they know enough to do CRC, then a small group of them do it. The rest gather around, see almost immediately that this documents the SystemMetaphor, and finally resolve that anything that diverges from this agreement is unholy. DefiningDiagrams are an effective use of UML.

But you don't need any automated tool or standard diagramming language to do this. And it's really not design anyway - it's architecture. So when the UmlCaseVultures tell you that they do round-trip design or reverse-engineering or whatever your vulture is pushing today, they're selling unadulterated extra-virgin snake oil. A DefiningDiagram is small - it has to be because otherwise no programmers, no matter how bright (or how dim) could manage to agree on it. And you don't need any tools to work with it except pencil, paper, and maybe a xerox machine.

So, that tears it. For any practical purpose at all, UmlDoesntWork.

It's a single standard notation. That alone has value, in my experience.

Um, so all you're saying is "does too"? Come on, put up yer dukes and argue like a human! If this "standard" is any more useful than a pack of CRC cards, then tell us why. If it's just an exercise in XmlAbuse, then admit it and stand down. What's the value of a standard that encodes neither metrics nor semantics?

CRC doesn't capture inheritance (is-kind-of) well once you've put the cards back into a stack.

That's what source code is for.

You've missed the point. There's this space of time between putting the cards in the stack and writing the source code during which people forget things.

If you'd done XP you'd know the CRC for a single UserStory is quick. It's like someone telling a joke; then you go code it up. If you sat down and did CRC all day then you failed to do adequate IterationPlanning to break your requirements down into stories. These UserStories are small things - they fit on 3x5 cards. They're not like UseCases or functional specs.

Yes, a PairProgramming session should be extremely short, but often a single diagram to capture the stuff ALREADY agreed in the CRC session helps the pair remember what they were talking about earlier.

Again it seems you failed to break your requirements down into UserStories. Let me hazard a guess. You didn't have a reliable OnSiteCustomer. You had a spec thrown over the wall and you did BigDesignUpFront to break it into things you called stories ... but which you didn't prioritize or estimate ... am I getting warm?

CRC doesn't capture the subtle differences in container references (aggregation vs. composition) well.

And that's bad because?

Because it will come back to bite you in a test later.

How?

Would you rather write the test, immediately fail it because you forgot an easily captured bit (which you can, by the way write on the back of a card, which I've done ZILLIONS of times -- but that's not strict CRC, is it?) or have the test run green the first time?

I want the test to fail the first time, of course. That's why I write the test. See, we take the UserStory and break it down into EngineeringTasks. Then you and I sit down to pair on an EngineeringTask. We think of a ProgrammerTest, we write it, and we watch it fail. Then we DoTheSimplestThingThatCouldPossiblyWork to make it succeed.

Then we ReFactor. Then we do the next EngineeringTask ... until we've got a working AcceptanceTest. Oh, I forgot: the first EngineeringTask we do for any UserStory is to write an AcceptanceTest.

So if we forgot an easily captured bit, we failed to create an adequate AcceptanceTest. Since our OnSiteCustomer specifies and reviews all our AcceptanceTests, he or she will tell us if we were forgetful.

No big deal. Just do XP, and stop fussing.

CRC doesn't capture state transitions well.

Beg to differ strongly. If you role-play the transitions, they come out just fine. Now I'm in this state ... and so I tell you this and now you're in that state ...

Don't get me wrong -- there's nothing better for flushing out the behavior of different objects and running through scenarios, but UML is capable of capturing some of the subtleties of the design process that CRC just can't -- after all, that's why RebeccaWirfsBrock added additional diagrams to CRC to arrive at ResponsibilityDrivenDesign...

And that's good because?

The fact is that human memory (which is what you have besides what's on the CRC cards) is pretty fallible.

What, did your OnSiteCustomer die? Did they somehow forget what they wanted?

Look, this is silly. If you can remember the plot to Goldilocks and the Three Bears then you can remember a CRC session for a UserStory. They're just not that complicated. Or if they are, they exceed a UserStory's estimate granularity and you have to chop 'em up. That's called the PlanningGame.

That's totally different than my experience (of over 11 years) with CRC -- I find more often than not that 10 minutes after you've done the role play you're asking "now did he say this, or did she say that?"

You may think you have a defective memory, but I bet you dollars to donuts your OnSiteCustomer does not. Just break up your work properly with correct IterationPlanning, use nice one-week iterations so there's no room for ambiguities to creep in, and XP works.

So why not just write it down after everyone agrees?

You do write it down. You write it down as tests and code.

It's nice to have a standard way to capture the stuff that comes up in a design discussion that won't fit on the cards...and don't tell me that it should all be in the code -- design discussions are things that usually happen with > 2 people at once (making pair programming cumbersome)

Rubbish. Design discussions are pointless. CRC is for analysis. ReFactoring is for design. Don't let old ideas encumber you. BDUF only wastes time and money.

Who brought up BDUF? 15 minutes to 8 hours of design is certainly NOT BDUF and you can't convince me it is. I've had discussions about design (of that length) in XP projects lots of times and NO ONE has complained about it. And how do you know that I'm "encumbered by old ideas?" Sometimes you need to examine your prejudices and see if they make sense...

I don't know - who can tell when everyone is anonymous. You say you did 8 hour design meetings on a regular basis ... documenting them in UML ... I bet your design spec was more than 200 pages long. And I bet it went completely stale inside 6 months. And I bet you had to write another one. It's the same story over, and over and over again ... how nice that now we have a way off that treadmill.

I'm not anonymous anymore. This is KyleBrown. BTW, you've been anonymous too... And I never said that I did 8 hour design meetings on a regular basis. I said they lasted from 15 minutes to 8 hours (the outlier by far), and I never mentioned "a regular basis" once! There was never a design spec (I never said that either!). I was trying to say that it's a nice point solution for a specific problem that occurs often, but not every time. If you read down at the bottom you found that I said UML does NOT, repeat, NOT belong on paper or (even worse) in a computerized tool -- it belongs on Whiteboards only (or maybe the single 8 1/2 by 11 sheet drawn in pencil)...

-- the discussion may be 15 minutes long or it may be all day long; if it's greater than 15 minutes you're going to forget some of the details.

You spend all day in a design discussion? And you expect to get paid for it? Try ExtremeProgramming - it's a blast!''

Don't be patronizing. I HAVE done this in XP projects.

No, you did this on projects you called XP. Maybe you conned other people into calling it XP too. But if you did BigDesignUpFront, if you failed to do IterationPlanning, and if you did ResponsibilityDrivenDesign instead of TestDrivenDesign, then you did something other than XP.

This isn't something to be embarrassed about. Lots of people have successful projects without doing XP. Well, a few people do. But now there's a distressing tendency for people to say they do XP when actually they don't. It's like the old "We do OO because we write C-style code in C++" thing. That is something to be embarrassed about.

''' Was Evant XP? Well, most people would say that it was... and I once spent 4 hours drawing diagrams there to explain some points and get some ideas across... No one complained. I once spent a week at a Daimler-Chrysler project headed by some of the original members of the C3 team and we spent up to 2 hours a day drawing little UML diagrams (in little 15 minute to 1/2 hour increments spread throughout the day, and not every day). I could go on -- there are 5 or 6 more projects like that I could mention.

And what do you mean "if you did ResponsibilityDrivenDesign instead of TestDrivenDesign then you did something other than XP"? The two are not mutually exclusive. We come up with what the test would be, play through the roles in CRC, and capture it (using UML if we choose). Then we write the test, write the code, and refactor if necessary (NOT updating the diagram unless we need to talk about "this way or that way" for some reason). That seems an awful lot like both... '''

It happens more often than not -- you get to the point in refactoring where many people (visual thinking types) want to say "would it be better this way or that way".

(META: I'm not a UML fan. I think that, one the whole, it gave the IllusionOfControl over a software project, not the actual control. But if it worked for you, I'm not going to call you 'wrong' - that's like a doctor prescribing medication without ever examining the patient! To paraphrase the old man of avalon - "There are more ways to develop software found under heaven and earth than are drempt of in your philosophy" --MattHeusser UDPATE: It's now September of 2011, and I have /yet/ to see a /single/ instance where UML worked long-term for design for any reasonable definition of "worked." I'm still reluctant to say someone is "wrong" when it's working for them, but, to be honest, I've never actually met this hypothetical person for whom UML-as-a-mandated-process-for-design is working. UML as a sketch, maybe, but that's much more like "drawing on a whiteboard" than UML.)

You use diagrams for ReFactoring? See, what you do in XP is, you look through the relationships between the SimplestThingThatCouldPossiblyWork and the rest of the CodeBase. You look for CodeSmells in these relationships. You apply tiny little Refactorings iteratively to fix the CodeSmells until nothing smells any more. Then you're done.

If you needed diagrams for any of that, you failed to do ReFactoring as well. I don't know what you did instead, but I'm very curious. Why not describe this strange new practice in a page here - it might even have value!

Ahem. I think MartinFowler might object to that overly strict definition. I draw diagrams with him to say "do you mean this, or that" on a regular basis. The fact is you can often draw a diagram a lot faster than you can refactor 5-6 classes to eliminate a code smell. Does drawing the diagram eliminate the smell? No, but it does allow you to say, what if we moved this over here, or here, and work through the quick consequences to see which way is less "smelly".

A diagram can capture the "this way" or "that way". So can spatially arranging your cards, but the problem is that people do NOT necessarily have a good memory for what all of the subtleties of spatial arrangements mean.

On the contrary, people have incredibly good memories for spatial arrangements - that's why all the mnemonic tricks encode information by arranging and associating it spatially.

The next time you have a long list of requirements to memorize (i.e., the next time you're not doing XP IterationPlanning :-) try mentally assigning them to various places you pass by on some well known route - your commute if you like. It's astonishing how well this works - this is how the card counters beat the casinos.

Who said there was a long list of requirements!? You keep trying to paint this as BDUF, when it's not. I'm simply stating that some people (myself included) use diagrams for capturing small things because CRC just doesn't quite capture ALL of the interaction you get in a CRC session after the fact. And don't tell me that I'm wrong on this, dammit, I've HAD more than 11 years experience in doing CRC. And a lot of that was working with folks like SamAdams that originally pioneered CRC. I'll still model things with the cards first -- but then I'll sometimes draw a diagram to capture it (one page, never more, and not always). Once the design is coded from the information in both the cards and the diagram, I throw the silly thing away. And where did I learn this horrid, terrible, apparently non-XP practice of using occasional diagrams along with my CRC? Oh my, it was from people like Sam and Rebecca, and Martin.

So, it's nice to have an intermediate representation slightly higher than code to capture this sort of stuff.

UML isn't higher than code. It's worse than code. It's more ambiguous, has vastly less up-front testability, and grows stale much faster than code. It doesn't work for anything at all - with the possible exception of a DefiningDiagram.

Now, don't get me started on CASE tools -- IMHO, UML belongs in projects, but on whiteboards only...

Okay, we agree that far ...

Most of the (seemingly dismissive and intolerant) arguments about the uselessness of UML seem to me to attempting to argue "UmlAddsNothingToXp?" - dismissing someone's view that UML is useful to them with "but you're not doing XP properly") isn't particularly convincing. XP isn't the only way software is (or should be) developed...

May I suggest, the almost heretical, ItsAllRightNotToDoXp??

Hi everyone, I am new to here and I am a student. Just want to express some of opinion about UML and I might be wrong.

I am currently doing third year engineering course, one of the subject I took is known as Object-Oriented Software Design. Probably because I got a very horrible lecturer who well-known as "knows nothing in programming", I personally feels very bad about UML.

I think that UML is generally a tool for end user to express what they want in a way that understandable by programmer.... therefore, it is not hard to understand why some programmer find UML doesn't make any sense. UML might helps to improve some really obvious design problems but when the size of the software going to develop is really large, UML just mess everything up. I suggest that UML is more like a business analysis tool rather than for software design.

Furthermore, according to my lecturer, one aim of UML is to get rid of some "design smells". So when upgrade of software is required, we just have to add extra code instead of change exist code. I generally think that is a good idea, but it leads to another problem.... generic vs efficiency.

The point mentioned above implies we have to write generic code, but if you have several programming experience, it is easy to find that generic == inefficient. That ends up contradicts with the starting purpose of having a good software design.

Welcome to Wiki. There are really two different parts to the whole UML design question. One is whether or not UML can be useful for design. The other is how much effort should we put into design. You can over-design things with or without UML. For more on 'over-design', see BigDesignUpFront. The current XP/Agile thinking is that the design should evolve during development, so instead of doing a BigDesignUpFront, we do ContinuousDesign throughout the project.

So now the question remains, is UML useful for design at all? I would say that it is one of those things that you need to know, and can be useful on occasion. The primary benefit of UML is that it is spatial and visual, using shapes and formatting to indicate relationships. Other methods such as CrcCards are even more spatial, but not very visual. One of the limitations that is annoying about UML is that it is too static. If you print it out on paper, you're basically stuck with that 'snapshot'. If you're working on a whiteboard, you can't rearrange things without erasing and re-drawing. If you're working on a computer, you've got all the limitations of collaborating on a computer. It's a bit harder to brainstorm with UML. CRC cards are a more collaborative tool. UML is better for taking snapshots of the design: Here's what we've got, or Here's what we want to make. The question of how much time to spend doing this is a different question altogether. XP and most other agile approaches would say not to spend too much time on it, and to toss the snapshots once they become obsolete. Other BDUF approaches would tell you to spend lots of time on it and to keep all your old designs.

By the way, UML was invented by software developers, not end users.