" All of a sudden an email starts to decompose into a group of objects, including several PPTs and a MI."
 

This is a fertile example indeed and I'll live you all to it. What i'm trying to say while not creating much of a confusion into our minds is that the DNC may be as well the DNA of every model. Meaning that the archetypes and colors of the DNC are atomic by nature (indivisible) and so are their associations.

 

Now in practice the scope of the problem is all that matters. If a problem scope is as simple as an email dispacher one may as well only need one class, email, painted in pink. The more broad the problem scope becomes, one may start to unfold the class exposing its DNA and you may or not arrive to a full blown balanced DNC shape (a string). But this does not mean that the initial model is a bad one, it means that the scope became bigger and you needed to refactor the class in several different ones to cope with the complexity. Another approach is start with the most complex and try to make it simpler (Steve's article)

 

A good model is one that solves with the problem at hand, nothing less, nothing more. Don't make a model more complex just becouse you might need in the future that extra complexity or just becouse it doesn't quite resemble the DNC. Just be assured that when the time comes for extra complexity you already have a mental road map to deal with it.

 

My own experience is that is very easy to make a complex model, but to make a simple one that can grow steadly in complexity that is another matter. And for this matter the concept of DNC is excellent but one needs to master it for multple angles. Otherwise one may get tangled up in with concerns that are less the practical.

 

Nuno

 

 

 

On 2/12/07, jason marshall <jdmarshall@...> wrote:

That's a pretty fertile example there.  I'd like to continue along this line of thought.

Think about how you'd implement a threaded email client, with folders.  All of a sudden an email starts to decompose into a group of objects, including several PPTs and a MI.  Once you consider an email not as simply a 'message' but a  part of a conversation, taking place in a particular venue (eg, the Color Modeling list), then the information that doesn't relate to the body of the messages becomes as important as the body itself (and with the corner case of spam, the body is the LEAST important part of the message).

-Jason

On 2/12/07, Nuno Lopes <nbplopes@...> wrote:

Another example?

Take for instance a message in your email system. How would you caracterize it? As an MI? Humm, I can argue that it can be a Thing if the transaction "Send" or "Receive" (puts a date on the message) is decoupled from the Message. Or you can argue that is an MI as the information regarding the transaction "Send" does not need to be decoupled.

In this case I would choose the color Green (Thing) as the transactions are quite "simple", there is a one to one relationship between message and the transactions, a the message can actually exist without the transactions.

Nuno

On 2/8/07, Nuno Lopes < nbplopes@...> wrote:

There are certain objects in the world that act as containers that are disposed once used. In a system this containers have a reference. In this cases usually there is a a one to one relationship between the container (place) the object it contains (thing with its own reference) and is stamped with the date it was used (MI). In such cases one need to choose which color better caracterizes the concept as it can have any color.

It happens all the time if you think about. In the example above I would choose a Green Color as the I would concider the concept as a packaged product with composite key (ref of the container + ref of tht thing it contains).

A less abstract example? Take for instance you body, is a place for human organs and lives for a period of time.

Nuno

On 2/2/07, michal_matula <michal_matula@... > wrote:

Hi Nuno,

thanks for the examples. I think it makes things clearer.
What I am not sure about is - did you say that the same class can be
of different "colors" in the same system? How would you cope with
that if you followed the recommendations and model using colored
sticky-notes? :-)
I can understand that what is for one MI a "Place" may be a "Thing"
for other MI (still keeping the green color though) but it is hard
for me to see the same class acting as a Place and MI for instance.

Thanks again anyway.

Regards

Michal

--- In colormodeling@yahoogroups.com, "Nuno Lopes" <nbplopes@...>
wrote:
>
> "Could you please post an example of those three for let's
say "sendE-
> Mail" MI class?
> I can imagine that "Message" could be a thing here, "DeliverTo"
> could be a party....what is the place here?"
>
> Example:
>
> 1) First Part
> [Person] - Comprises the personal name and other personal
identification
> [Place] - Information regarding where the person is (Office, Home,
etc)
> [MI] - Contact Information (It's an MI as contact information can
change
> along time and you want to track it)
>
> 2) Second Part
> [Role] - Email Address (Role of Contact Information in an Message
> transaction, The MI becomes a Place)
> [Role] - Sender (The Role of a Person in a Message Transaction)
> [Role] - Receiver (The Role of in Message transaction)
> [MI] - Message (The Subject)
> [Role] - Message Body.
> [Thing] - Peace of Text
>
>

--
- Jason