features matrixintro pageOODBTG Reference Model
There are various sorts of "containment constructs" in objectmodels. They can be characterized by how containment is established andwhat it signifies. Models which support an attribute concept sometimesconsider all the values of an object's attributes to be contained in theobject. Some models assume that objects have a natural intrinsic content,in the sense that a document consists of some text, or a file consistsof a byte string. In other models, literal values are considered to becontained in the object, while non-literals are not. In some models attributevalues may be either objects or pointers to objects; objects which arepointed to are not considered part of the object. There may be an explicit"contains" relationship among objects, so that an object containsthose objects which are so related to it. Containment may be treated asa property of a relationship, allowing various relationships to be designatedas implying containment.\footnote{The notion of containment captures theimplementation notion of "reference".}
Abstractly, the semantics of containment can be described in terms of"propagation" of operations, resembling a form of inheritance.A request to print or move a document is expected to print or move thetext of the document, along with any diagrams or other sub-objects containedin it. Thus, for certain operations "f", if "x" "contains""y" then "f(x)" is expected to cause "f(y)".Details vary. There may be different decompositions of a given object intoconstituents: a book may be composed of chapters and paragraphs, and alsoof pages and lines. Different operations may propagate in different waysalong different containment paths. Destroying an object might or mightnot destroy a contained object. This might or might not depend on whetherthe latter is also contained in some other object. The authors and fontof a book may or may not be the authors and font of its chapters.
Object systems often support value-based "equality comparison operations"which allow objects to be "equal" even if they are not identical.Equality is defined differently in different systems, may be system- oruser-defined, and may be class-dependent. Equality comparison operationsmay depend on the primitive identity comparison operation "==",on value comparison operations, on containment comparison operations, orin terms of equivalent behavior.
OMG CORBA IDL
See entry under 7. Types and Classes.
EXPRESS
EXPRESS has no concept of containment.
Open Distributed Processing
ODP makes extensive use of composition of objects.
Management Information Model
(See entry under 9.1 relationships for an overview of relationships.)
The managed objects in an information model are often interrelated.(Note that inheritance is a relationship between managed object classesnot objects.) The relationships between managed objects are a criticalaspect of the information model. Modification to these relationships requireintegrity constraints to be maintained. Currently, there are three waysto represent relationships in an information model: a) containment throughnaming, b) relationship attributes, and c) relationship objects. However,within ISO, a model [ISO/IEC GRM] for formally specifying the behaviorof relationships between managed objects is being developed independentof how the relationships are represented.
a) Containment
Containment describes how an object may physically or logically be partof another object. An object may only be contained in one other object.Containment relationships are formally defined by the use of name bindings,which specify the superior and subordinate objects, the attribute usedfor naming, and any creation and deletion rules. More than one name bindingmay be defined for a particular object class, but only one name bindingmay be supported by an instance of the object class.
To allow access or referencing of managed objects, common unique namesare needed for the objects. The management information model adopts thecontainment relationship for naming managed objects within a givencontext. This relationship describes how an object may be, physically orlogically, part of another object.
The contained object is termed the subordinate object, and thecontaining object is termed the superior object. Superior and subordinateobjects may be instances of the same object class or different object classes.Additionally, an object class may have more than one containment relationship,depending on the application. However, each subordinate object instanceis directly contained within one, and only one, superior object instance.The hierarchy of superior and subordinate object instances is used fornaming object class instances and is called the Naming Tree, orContainment Tree.
A name binding identifies a valid naming relationship in whichinstances of the subordinate object class may be named with respect toinstances of the superior object class. Along with the names of the subordinateand superior object classes, a name binding definition includes the attributeused for naming, and information about how instances that use this namebinding may be created and deleted. Additionally, a name binding definitionmay indicate if the name binding also applies to all subclasses of thesubordinate and to all subclasses of the superior object classes.
b) Attributes
Other relationships are defined using relationship attributes, alsocalled "keys". Relationship attributes are not differentiatedfrom other attributes in the templates but are attributes that interrelatemanaged objects. The attribute values, having ASN.1 syntax of Object Instance(which is either Distinguished Name [DN] or local name), are pointers toobjects to which the managed object is related to. The behavior definitionsof the relationship attribute and the related objects are used to characterizethe behavior of the relationship.
c) Relationship Objects
Objects can also be used to represent relationships when a relationshipitself has information associated with it. Objects of this type are called"relationship objects", and the information associated with therelationship is made visible through the attributes. Operations that affectthe relationship may be directed to this object.
Relationship objects may also have relationship attributes that pointto the objects participating in the relationship. The behavior of a relationshipobject is used to indicate the behavior of the relationship itself. However,relationship objects are not differentiated from the other managed objectsin a managed system.
General Relationship Model
However, using the model in [ISO/IEC CD 1016507, GRM], relationshipclasses may be explicitly defined independently of managed object classdefinitions. These relationship class definitions may be used to providegeneric reusable relationship classes that are common to multiple applications.These relationship classes may be reused by many applications via subclassing.Examples of these relationship classes include:
General Composition: There exists two roles for the general compositionrelationship class: composite role and component role. Exactly one participantin the composite role must exist and correspond to one or more participantsin the component role for an instance of the general composition relationshipclass to exist. Participants in the component role may be of differentmanaged object classes with 0 or more instances of each of the managedobject classes bound to the component role. At least one property of acomposite participant exists such that it depends upon properties of itscomponents. A composite must also have at least one property that is independentof its components' properties (at least, identity). Creating updating ordeleting a component does not change the identity of the composite.
Dependency Relationship: There exist two roles in the dependency relationshipclass: parent role and dependent role. The existence of a participant inthe dependent role implies the existence of a corresponding participantin the parent role. The participant fulfilling the parent role must existbefore another participant can fulfill the dependent role. In other words,a participant in the dependent role cannot exist by itself. The objectclass cardinality of the dependent role is exactly equal to one, that isparticipants fulfilling the dependent role must all belong to the sameobject class.
Symmetric Relationship: There exists two roles for the symmetricRelationshiprelationship class: sR role and participating entity role. Exactly oneparticipant in the sR role must exist and correspond to two or more participantsin the participating entity role for an instance of the symmetric relationshipclass to exist. Both roles in the symmetricRelationship are static: onceestablished, nothing can be changed.
SQL3
SQL3 supports the concept of values being contained within values (e.g.,instances of row types, or collections of such instances, can be containedin a column of a row) or within ADTs. A form of containment semantics canalso be implemented by specifying triggers to enforce cascaded manipulationsof a collection of data structures when one of them is manipulated. Thiskind of containment must be specified by the user.
Matisse
Complex structures can be embedded in a Matisse object as a literalvalue. For relationships, OIDs are specified and the linked objects arenot contained in the sense that deletion and other actions are not automaticallypropagated unless the user specifies an appropriate trigger.
C++
A data member of an object class can be defined as having a type thatis either a type defined by an object class (in which case it will containan actual object) or a type that is a reference to an object class, e.g.,as being either type X or type X* (a pointer) or X& (a reference).A class can be declared within another class; such a class is called anested class. The name of a nested class is local to its enclosingclass. A class can also be declared within a function definition; sucha class is called a local class. The name of a local class is localto its enclosing scope.
Smalltalk
Smalltalk furnishes a number of different types of "collection"classes that support containment groupings of objects in various ways thatprovide specific behavior for the given type of collection. The followingcollections are standard in most Smalltalk implementations:
Eiffel
Containment of objects can be realized by using an expanded object.An object that contains another can either have a reference to that objector hold the object itself. When an object holds another directly it iscalled an expanded type.
This can be declared in two ways. The class to be referenced may bedeclared as expanded:
expanded class A
...
or the entity (attribute) may be declared as expanded:
a: expanded A
In both of these cases the object will be contained within another.There is no need for dereferencing. See entry under 2.6 state.
Emerald
See 9.6 other.
System Object Model (SOM)
SOM is a basic technology and therefore does not have a notion of oneobject containing another. However, since SOM is a library packaging technologyit supports the construction of SOM objects which can contain other SOMobjects.
OLE Component Object Model
See entry under 8. Inheritance and Delegation.
Analysis and Design Methods
[Note: The contributor takes 'containment'to refer to the concept whereby objects are considered to be composite,that is, to be composed of other objects which are contained within thecomposite object. This sense corresponds to the implementation wherebycomponent objects are 'physically contained' within the composite object(thinking of a composition mechanism is possible in C++, but not in Smalltalk).As will be seen, the term is used differently by most authors.]
SA: Containment is considered to be akind of ordinary relationship. An object is not 'within' another object;rather, an object has a "referential attribute," identifyingthe other object. Instances of containment relationships are not necessarilyobjects.
RD: "Many implementation data structuresare instances of container classes. Such data structures includearrays, lists, queues, stacks, sets, bags, dictionaries, associations,trees, and many variations on these..."
JA: "A special type of acquaintanceassociation [See 9.1 relationships] is the consists-of association,which is used to express that an object is composed of other objects. Sucha structure where a uniting object has associations with participatingparts is sometimes called an aggregate." Instances of this relationshipare not necessarily objects.
WD: Containment is modeled by the "is-part-of"relationship. A distinction is made between "composite classes"and "container classes." A composite class has responsibilitieswith respect to its parts and will commonly collaborate with or delegateto them. An example is car, composed of wheels and other parts. A containerclass has a weaker relationship to its contents. Examples are array andhash table. Instances of both kinds of classes are, of course, objects;however, container classes are designed specifically to model containment.
MD: "It is often convenient to introduce... objects that refer to other objects. ... One technique is to allowobjects to contain other objects... This technique is indeed possible...[b]ut it does not permit sharing. To allow for shared objects, fields maycontain references to other objects."
EA:
OA: "Composition is often confusedwith containment or topological inclusion. Topological inclusion is therelationship between a container, area, or temporal duration and that whichis contained." See 9.5 aggregates.
BD: "Aggregation may or may notdenote physical containment."
HA: "A structure that may be usefulin Implementation is that of the composite class: a class defined withinternal classes whose definitions are local and are not externally visible,i.e. lexically included classes"
NA: "...[W]e should define a standardset of generic [container] classes ... for use as specification elementsfor very high-level information structures." [See matrix entry forEiffel.]features matrixintro page