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"........

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.

You do an excellent job of demonstrating that UML is philosophical BS substituting for design.

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. ;¬)

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.