It looks like nobody has responded to this yet, so I'll take a crack at it.

What I've witnessed is that a missing DNC object tends to imply a missing or future requirement. 

That is to say, you've looked at your requirements, and you just can't see where this hole in your model is covered by anything you've been asked to build.  However, once management or the customer gets their hands on a prototype of the application, they're going to say, "Hey, this is pretty neat, but why can't I do..." and then you'll find yourself with a change request that, surprise surprise, fills in a couple of those holes.

Sometimes I see these while going over the requirements docs for the first review, especially when they're boundary conditions (what should I do when this data has/hasn't already been entered before?  What if there are two of these, or worse, 500?  How should I present that?).  This makes requirements meetings with me take a lot longer, but it leads to less frustration among my peers as the delivery approaches and, I hope, a better product.

Other times, they're features to be built in version 2 or 3 of the product.  In these cases I find it helpful to know that some day I'm going to have to add this object to the model (just not today).  Sometimes management finds it helpful for doing long-term planning ("Oh yeah, I didn't think of that.  Good idea.  We'll add that to the schedule for the next version."). 

Mostly, the knowledge that something belongs there but hasn't been defined yet helps me when picking implementations for the surrounding code.   I'm not talking about writing the first version so that all of the support for the 'someday, maybe' features is already in the code.  That road leads to the unemployment line (by way of project failure).  I mean that sometimes the most innocuous-looking changes to a design can make all the difference between a difficult feature request and a simple one.  I think about these when I know ahead of time that a feature is or might be coming.  Thirty seconds spent considering the hypothetical, "Okay, now how would I refactor this code to support a one-to-many relationship here, instead of a one-to-one?" frequently saves me days of rework later on, and costs the current milestone hardly anything at all.

-Jason

On 1/11/07, Michal Matula < michal_matula@...> wrote:

Hi everyone!

 

As it seems there is still some activity here I'd like to post some (probably dumb :-) ) questions here as I am quite new to both modeling and modeling in color and DNC.

 

We have tried to model a few relatively simple systems using DNC and we have always got to the question:

 

Does DNC require to have always all three "legs" aka associations (i.e. - party+place+thing) from the moment-interval class  or simply for some of the moment-interval classes certain association are naturally missing and we should not spend our time looking for the "missing link" :-)

 

Or, is the missing link a sign of not correctly chosen moment-interval class?

Or, is the missing link a sign of our low experience with modeling or lack of analytical thinking?

 

Thanks in advance for any info or links to other resources I might not know.

 

Best Regards

 

Michal Matual

www.billboard.cz

---

Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers .

--
- Jason