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 …
Relationships between packages
I'm on the same lines for many things but relationships between packages *are* really vital: they are used for dividing the whole project into layers and avoiding spaghetti dependencies between packages. Basically, you are asking and answering the question: "may classes from package A know and use those of package B?". Not only does it affect the resulting code but it also affects the whole rest of the design.
**"The line from the Gershwin classic on "tomato" versus "tom-ah-to" sums up these debates pretty well."**
They sound the same to me. I think you mean the difference between "tomato" and "tom-AY-toe"........
Great article, but packaging is *really* important
This (and the previous) article really struck a chord with me. I will hold my hand up and admit to making many of these mistakes myself.
UML design is no different than a lot of disciplines, in that good practice comes with experience and some of your lessons have to be learned the hard way. Unfortunately it seems to be the way that whole teams jump into a new methodology without the benefit of seasoned practitioners to help them along - it should come as no surprise when you get burnt, as happened to us when we first tried it.
However, as the first poster says, the article shouldn't dismiss package dependencies as automatically less important than (say) class relationships. As projects get bigger, dependencies become proportionally a bigger issue. And you can easily make the argument that dependency problems are a lot harder to fix once they've gone wrong, compared to fixing up class relationships within a single package.
Still, I reckon the book must be worth a punt. Thanks for the article.
made my day
You do an excellent job of demonstrating that UML is philosophical BS substituting for design.
OK Curtis, I'll bite
UML is merely a notation, using which a design may be formulated, recorded, amended and communicated. It's just as possible to produce a rambling incoherent mess using UML as it is when posting comments on here.
I agree with Evil Graham, this series of articles is thought provoking and seems to make a lot of sense - well, enough to have convinced me to buy the book anyway. ;¬)
UML doesn't bullshit - people do
Curtis - it's almost a fair point, but it's not UML per se that's BS. It's just that UML and the software modelling industry in general attract more than their fair share of bullshitters and snake oil salesmen.
If you've never seen it used well, you're naturally going to diss it.
But if you truly have any better suggestions for managing and architecting large software products, which is how I make my living, then I'm all ears. If you're selling something better I'll even make time to listen to your presentation. Can't say fairer than that.
- Xmas Round-up Ghosts of Christmas Past: Ten tech treats from yesteryear
- Analysis Microsoft's licence riddles give Linux and pals a free ride to virtual domination
- Review Hey Linux newbie: If you've never had a taste, try perfect Petra ... mmm, smells like Mint 16
- Special Report How Britain could have invented the iPhone: And how the Quangocracy cocked it up
- Massive! Yahoo! Mail! outage! going! on! FOURTH! straight! day!