Feeds

Telltale signs your model is stuck

Analysis paralysis: part two

The Power of One eBook: Top reasons to choose HP BladeSystem

Teams can get stuck wallowing in trivial details when modeling in UML. Sweating such details can lead to frustration and premature, and rash, decisions on using UML later in a project. But how do you know when a particular nuance is inconsequential and when it's an important item to specify?

You learn to recognize the signs of analysis paralysis - aside from the obvious one, that no progress is being made: the team is having a profound philosophical discussion around the whiteboard, and it has virtually nothing to do with the project, and virtually everything to do with splitting hairs. The line from the Gershwin classic on "tomato" versus "tom-ah-to" sums up these debates pretty well.

It's understandable that people spend ages arguing over the finer details, because most UML books describe each part of the notation with equal weight. You might see a description of dependencies between packages - not terribly important, except maybe as a high-level overview - right next to a description of relationships between classes.

One rule of thumb is: will it affect the source code that falls out of the end of the design process? If you use <<precedes>> instead of the <<invokes>> stereotype to link up your use cases, will the code - or the unit tests, or the test specs - be any different? Answer: Almost certainly not.

Similarly, modeling the dependencies between packages will have absolutely no effect whatsoever on the resultant source code. It's also debatable whether it would add any value to your documentation. However, modeling the relationships between classes definitely will affect the source code - especially if you're generating code directly from the model.

Another rule of thumb: is the distinction less about the semantics of your problem domain or design, and more about the semantics of the modeling language? If so, the distinction probably isn't an important one.

And finally: are you worrying about finer details at the wrong stage? For example, debating the multiplicity between domain objects before you've even begun to think about the design, or debating too early - when the domain model is only just emerging, all wide-eyed and blinking in its innocence, from the customer's subconscious - whether two real-world domain objects should be connected with aggregation or composition. When teams discuss this stuff too early, you end up with some deep discussions that border on philosophy and existentialism: is object A object B's keeper? If A pings out of existence, what happens to B? Is an A without its B really an A? And so on.

In the song, the tomato versus tom-ah-to impasse produces the exasperated cry of: "Let's call the whole thing off!". This is pretty much what people decide to do with UML after they have wasted time and effort getting into the not-very-important and extremely arcane aspects of modeling.

And that's a shame, because they miss out on all the useful, pragmatic aspects such as allocating behavior, eliminating ambiguity in your requirements descriptions, and identifying code "hot spots" ripe for unit and functional testing.

Analysis paralysis is an insidious beast that pounces when you have disagreements over issues that seem important and takes things off track. Keep an eye out for this creature's tell tale signs, and you'll quickly start to recognize when your project is spinning its wheels over non-issues.®

Matt Stephens has co-authored Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to step nimbly from use cases to code while avoiding the dreaded analysis paralysis.

Boost IT visibility and business value

More from The Register

next story
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Captain Kirk sets phaser to SLAUGHTER after trying new Facebook app
William Shatner less-than-impressed by Zuck's celebrity-only app
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
EU dons gloves, pokes Google's deals with Android mobe makers
El Reg cops a squint at investigatory letters
Chrome browser has been DRAINING PC batteries for YEARS
Google is only now fixing ancient, energy-sapping bug
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
The Essential Guide to IT Transformation
ServiceNow discusses three IT transformations that can help CIO's automate IT services to transform IT and the enterprise.