Sign in / up

back to article Telltale signs your model is stuck

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 …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    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.

    0 0
  2. Anonymous Coward
    Thumb Down

    Tomatoes

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

    0 0
  3. Anonymous Coward
    Thumb Up

    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.

    0 0
  4. Curtis W. Rendon
    Flame

    made my day

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

    0 0
  5. Justin O'Dwyer
    Thumb Up

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

    0 0
  6. Anonymous Coward
    Happy

    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.

    0 0
This topic is closed for new posts.