Sorry that I have been MIA over the last week.  I had a customer visit out of the country, and then had tons of work to catch up on ... Let me return to my thread on modeling guidelines. 

A good design separates out different conctexts and aspects into different class (or type) definitions.  That seems logical - "don't try to put everything together into a single class definition".  Duh!  But, we all fall into this trap because we think of our "current" context as the only context, and then merge new aspects (properties) into the existing class definition.  And, I think this is one reason that people have problems with the concept of containment, and why aspect-oriented programming is growing in popularity.

Well, I will get back to that last statement a bit later in the post. First, I want to discuss what I mean by separation of contexts and aspects. One example of the separation of aspects can be seen in the software lifecycle. Software development, packaging, deployment and runtime each have their own lifetimes and security implications. They therefore should be defined as separate entities in the model library.  But, this may be a relatively obvious example.  What about non-obvious scenarios? 

An example of a lack of separation (where it is needed) is to model the values of the tunable properties (i.e., “settings” or “knobs”) of an installed piece of software, as part of the software instance itself.  At first blush, this seems a reasonable approach since the values are indeed used locally by the software when it is running the computer. However, it is necessary to step back from the world of a single computer, and look at the world of a business.  That world has (potentially) hundreds of copies of the software installed on hundreds of different computers, usually all configured exactly the same.  With this perspective, it is easy to see that you could have one instance of the values of the tunable properties of the software, that all the installed software instances reference.  Building on this approach, an IT department could make a change to the values in that one instance, and the change would be propagated to all the installed software. In the other modeling approach, where the data is embedded, one is forced to change the values for each piece of software, individually.

A more subtle point related to tunable properties is that there won’t be just a single instance of the values – but many instances based on the environment or defined over time.  An organization may have one configuration for production and one for test installations, or may have one instance when the computers on which the software runs has SAN-attached storage and another when the storage is direct-attached.  In another location, IT may want to experiment with other settings on a single machine in order to evaluate options, or may need to deviate from the standard configuration during troubleshooting.  This is why separate instances are needed, handled by reference and not embedding, as well as needing the concept of time (past, present and future) and intent (actual, desired or proposed).

Make sense?  I hope so - if not just send me a comment. 

Let's go back to the problem of containment ... "Problem of containment? What problem?" you might exclaim. I have had many developers say containment "just doesn't work".  (In this case, containment is the UML concept described by a solid diamond at the end of an association.  It is a strong form of aggregation where the lifetime of the contained entity is dictated by the container.) Back to the developers that don't like containment ... they say "You can't possibly define an object as contained by a single entity, since that object may be contained by different entities - there is never just one containment context."  In reply, I say "hogwash" (actually, I probably say something stronger but this is the web :-)).  The real problem is that the developers have not separated their contexts and aspects sufficiently to use the semantics of containment. 

Many times developers throw out containment for the expediency of fewer objects and relationships - and then throw out valuable semantics. Containment really does exist. My employment and rules about how I measured, etc. are described by my 'containment" in an organizational unit and ultimately my "containment" in a company context.  But, my identity is more than my employment.  I am described by my family, the clubs that I belong to, etc. Some aspect of me (some data) is "contained" in each of these scoping contexts - and if they go away, then it might make sense that my data goes with them (data without context seems a bit ambiguous to me).  

So, my conclusion is that containment doesn't work when there is only one global instance to represent something. Containment does work when there is one instance for each aspect - where the individual aspects (data) are then contained in a context, and there is a way (an association to a collecting entity) to tie the aspects together.

Andrea