I'm having some trouble getting a proper mental grip on the concepts of Container & Containment. Can you help?
In a physical sense, I can understand the concept of a castle being a container, and being within a castle as a form of containment. While in the castle, I am nurtured by the master of the castle and protected from forces exterior to the castle; the master is the steward (i.e.; the careful and responsible management of something entrusted to one's care ) of my existence.
I think we need to be clear about the implications of the CIM
(Computationally Independent Model). The target domain can only be the real world. Thus if we are defining abstractions and other definitions that we wish to apply to the CIM, they have to be valid for the Real World model.
Thus, your use of the castle as an example is perfectly valid and appropriate!Where I get into trouble is when I abstract these concepts into a logical realm and try to think crisply about them in a CIM way. I think the [size=13]Java Tutorial[/size] on Collections provides a good starting point for clearing up my thoughts.
I think this is where we start having problems. While it is a starting point, if we don't recognise that computer languages are very limited (both syntactically and semantically), we run the risk of limiting ourselves. One of my colleagues at work, Vince Phillips (and a manager no less!) made the very astute observation that
we are limited in our thinking by the language that we use. He was speaking generally, but the observation is most valid for computer languages.
My view is that we should be able to construct an abstraction that is valid for the CIM and via (possible) transformations be also applicable to the PIM
(Platform Independent Model), PSM
(Platform Specific Model) and the applicable code.
An example of the language limitation I referred to is the statement:
Note also that the hierarchy consists of two distinct trees: a Map is not a true Collection. This is patent nonsense! Maps are just different kinds of collections. In my ontology there are two principal types of Collections: Sequenced Collections (which include (some of) those types on the left tree: List, Queue) and Associative Collections (which include those types on the right hand tree: Map and Set - from the left...)
Please, take a look (two pages ought to do it) and let me know if you agree that the abstract concepts presented there map well into the UML Context as a CIM. Don't spend time on the Java implementation code unless it it helpful to you; I'm only interested in the abstract concepts presented therein.
Here, Jim, you make the correct observation that one shouldn't spend time on the Java. I'm going further, I'm saying that the semantics of a coding language change the uses that certain concepts are put to. So long as we are aware of that, we can proceed with the appropriate caution.
In addition, much documentation created by people on the net is very sloppy...
My concerns are:- Are Collections a specialization of Container? (Default = no, they are synonyms.)
Yes, Collection is NOT a specialization of Container. But They aren't synonyms either. As I (in a Homer Simpson moment
) observed
[size=13]elsewhere[/size]:
Collection is about grouping, Containment is about access They are orthogonal concepts.
[/list]- Do you agree that a Nest is a specialization of physical Container (default = yes), and further, can a Nest be a specialization of a logical Collection (Default no, this is a mixed metaphor)?
See! You said it yourself!
[/list]- With the possible exception of a nest, saying that a object "A" is contained by object "B" does not mean we are modeling the concept that "A" is physically within a "B", but that we are saying that "A"s features fall within a defining boundary criteria allowing it to participate, along with other objects, in an association that is logically hosted by an object named "B". Am I making the distinction clear here? Is there a better way to say this?
I think we need to be careful here. bruce (sargasso) pointed out in his post on
[size=13]Ownership[/size] we need to differentiate between instance containment and classifier containment. I make that distinction in observing that while a class might be nested in more than one other class. The instance is
only ever physically in one containing instance.
Getting back to Containment... And Castles.
The Castle is the container. The master of the the castle isn't (and hasn't got anything to do with containment). When I'm in the castle, I'm not in another castle. I think that's the essence of containment.
For a given Class, if I can only be in one Instance of that Class at a time, then the Class is a Container, otherwise it isn't.
- Do you accept the abstractions of the Collections Framework at the CIM level? (Default = yes)
- If all of this is good so far, then my questions have been answered.
As I said above, This isn't relevant.
Now do you see why the Java Collections article isn't useful?
Apart from the first sentence:
A collection — sometimes called a container — There is actually
NO mention of containment (that which containers do) in the article.
Perhaps the article should start: A collection — sometimes (erroneously) called a container — ...
HTH,
Paolo
