featuresmatrix intro page0. Intended Use
1. Basic Concepts
2. Objects
See entry under 2.1 operations
2.1 Operations
Various object models embody various concepts of "object".All models consider an "object" to be an identifiable thing whichplays a role with respect to a "request" for an "operation".The request invokes the operation which defines some service to be performed.From a user's viewpoint, an object may be a "recipient" of therequest, a parameter in the request, or something returned as a resultof the request.
There are two broad categories of object models, which we refer to as"generalized" and "classical object models." Classicalmodels are, in many ways, subsets of generalized object models but theyare founded on different metaphors.
"Generalized object models" do not distinguish a recipientfrom other request parameters. In generalized models, a request is definedas an event which identifies an operation and optional parameters. Forexample, an AddToInventory(part1, lot2, bin3) request does not givespecial significance to either the part, the lot, or the bin. These objectsparticipate uniformly in the request.
"Classical" or "messaging object models" do distinguisha recipient. In classical models, a request is defined as an event whichidentifies and operation, a recipient, and optional parameters. Eitherthe part, the lot, or the bin could be designed to be the recipient ofthe AddToInventory request. The request to a specific recipientis called a message. A common syntax places the recipient first:part1.AddToInventory(lot2, bin3).
The "protocol"5, or "interface",of an object describes the operations in which the object can participate.In classical models, the interface of an object includes the operationsfor which it can be a recipient. In generalized models, the interface includesoperations for which the object can play the role of any parameter. Theprotocol completely specifies the behavior of an object but does not providevisibility to the implementation of the object's operations. Only operationsspecified in the protocol are allowed.
Objects may be static ("passive") recipients of requests ordynamic ("active") agents capable of such activities as sendingrequests.
5 Here, the term "protocol" is used asa synonym for "interface." This usage is different from the usagein communications.
2.2 requests
See entry under 2.1 operations.
2.3 messages
2.4 specification of behavioral semantics
Object models differ in how and to what extent the behavior of objectsis specified. Most object models limit the declarative specification ofobject behavior (operations) to the specification of a signaturefor each operation. The signature consists of the name of the operation,and the argument and result types. The semantics of the operations areoften defined operationally (by means of the code of the methods providedto implement the operations). Other object models allow declarative specificationof behavioral semantics, in the form of invariants that should be preservedby all operations, pre- and post-conditions for operations, other formsof constraints on the operations' behavior, or by a declarative specificationof the methods themselves. These models specify behavioral semantics ina precise and implementation-independent manner. Some of the models useformal notations based on mathematics (like Z, Object Z, LOTOS, etc.) fordoing so. These formal specifications may be translated into stylized English,in order to enhance their understanding by customers who are not mathematically-trained.See also entries under 2.1 operations.
Editor's note: Since we changed the heading from "interactionmodels" to "specification of behavioral semantics", someof the following entries must now be updated. The former feature 11.Integrity Constraints has been merged with this feature.
2.5 methods
A "method" provides the implementation of an operation forcertain objects. Different objects may have different methods for the sameoperation.
In the classical object model, a method is considered to implement theinterfaces of operation recipients, but not the interfaces of other parameters.In generalized models, a method is considered to implement the interfacesof all parameters.
2.6 state
Some operations alter the behavior of future requests. For example,if the ContainsPart operation returns TRUE or FALSE depending on whethera certain bin contains a certain part, then the result of ContainsPart(bin1,part2)may be changed by the request StoreInBin(bin1,part2).
The general concept of "state" concerns the information thatmust be remembered when a request alters the future behavior of other requests.Some models equate state with structural "attributes", i.e.,state consists of the current values of attributes. In other models statemay be defined as the results returned by certain operations, or statemay not be precisely defined.
2.7 object lifetime
The "life" of an object is the period during which it exists.An object's life begins as the result of a "create" operation.An object's life ends as the result of a "destroy" operation.An object whose life begins and ends within a single process is calleda "transient". An object which lives longer than the executionof the process that created it is called a "persistent". Someprimitive objects such as literals, have eternal lives, are neither creatednor destroyed, and represent themselves.
An object is "reachable" if and only if there is an operationthat returns the object as a result. The "transitive closure"of an object is all objects contained directly or indirectly within theobject, or more generally all objects reachable from the object directlyor indirectly by repeated application of some filtering predicate. Theterm "navigation" is often used when moving from object to object,possibly through a sequence of move operations.
An object is perceived to exist if and only if it is reachable. If nooperation exists that will return the object as a result, then the objectis "unreachable" (though it may or may not be physically destroyedand system-internal operations may or may not still keep track of the object.)Destruction of an object makes it unreachable. Operations which renderan object unreachable have the effect of destroying the object.
Rules for creating and destroying objects are system dependent. In someobject models systems, the application explicitly invokes creation anddestruction operations; in others, some sort of implicit scheme based on"referential integrity" insures that objects that other objectsdepend on cannot be explicitly destroyed as long as the other objects continueto exist. See entries under 9.4 containment and 2.4 specificationof behavioral semantics.
At the implementation level, destruction or deletion of objects mayinvolve reclaiming the storage space occupied by such objects. Some systemsallow a destroyed object's object identifier to be reclaimed for laterreuse; others do not. Schemes like "garbage collection" or "referencecount" may be used to manage and reclaim space associated with destroyedobjects.
2.8 behavior/state grouping
As noted in the OODBTG Reference Model entry under 2.1 operations,there are two broad categories of object models, which we refer to as "generalized"and "classical object models." Classical models are, in manyways, subsets of generalized object models but they are founded on differentmetaphors. "Generalized object models" do not distinguish a recipientfrom other request parameters. In generalized models, a request is definedas an event which identifies an operation and optional parameters. Forexample, an AddToInventory(part1, lot2, bin3) request does not givespecial significance to either the part, the lot, or the bin. These objectsparticipate uniformly in the request. An object in a classical model canbe thought of as a "hunk of state", with a collection of methodsgrouped around it. An object in a generalized model can also be thoughtof as a "hunk of state" with a collection of methods, but a givenmethod may be related to multiple hunks of state. For example, the AddToInventorymethod handling the request above would be related to the part, lot, andbin objects.
By using a generalized object model, the complexity of a real-worldsituation does not have to be always carved up into discrete self-containedobjects. In other words, relationships or complex operations do not haveto be artificially packaged as part of one particular object. The generalizedobject model considers a complex operation as jointly owned by all itsparameters and considers a relationship as shared by its participatingcollection of objects. Therefore there is no need to artificially choosea distinguished owner of an operation or of a relationship.
2.9 communication model
2.10 events
2.11 transition rules
3. Binding
"Binding" chooses a method or methods to be executed in responseto a request, based on the operation and objects in the request.
Note: CLOS allows method combination and may bind to multiple methods.
In classical models, the binding choice is based on the class of therecipient. In generalized models, the binding choice may depend on theclasses of several parameters.
Different object languages support different criteria and times forbinding an operation to a method for execution. Examples are "earlybinding" at compile-time and "late binding" at run-time.See entries under 11. Object Languages.
4. Polymorphism
"Polymorphism" means that the binding of a request involvesa choice among alternative implementations of the operation. Polymorphismallows "overloading" of operations, which means that an operationmay be implemented in several alternative methods, associated with differentclasses of parameters.
5. Encapsulation
A key concept of the object paradigm is "encapsulation", whichis defined as a kind of abstraction that enforces a clean separation betweenthe external interface of an object and its internal implementation.
Users of objects are people or programs which send requests to objects.Users of objects observe the behavior of objects in terms of the operationswhich may be applied to objects, and in terms of the result objects returnedby such operations. An operation may be implemented (i.e., supported orrealized) by a variety of different program code and data structures. Encapsulationmeans that these implementations are not visible to the user of the object,hiding details of whether and what data structures or code are used inan implementation. The importance of encapsulation is that it insulatesapplications from object implementations allowing them to be modified withoutrequiring applications that use them to be modified.
Some classical object models define a stronger form of encapsulation,in which the states of objects are isolated from each other; the implementationof objects is disjoint between objects; all methods and states belong exclusivelyto individual objects.
An assumption that attributes or other structural constructs are necessarilyimplemented as stored data would violate encapsulation. An attribute suchas the age of a person, the weight of an assembled object, the circumferenceof a circle, or the font of a word within a document might be stored insome implementations and computed in others. Violations of encapsulation,if allowed at all, should be made explicit (e.g. PUBLIC data in C++).
6. Identity, Equality, Copy
Each object has a unique, immutable "identity" which providesa means to denote or refer to the object independent of its state or behavior.The definition of identity includes the concepts of identity compare operation,logical identifiers, object identifiers, and object creation.
The identity concept can be described in terms of a primitive "identitycompare operation" "==" such that, if X and Y are the sameobject, X == Y. Some consequences of identity compare are:
o h(X) and h(Y) have the same result for any operation h(), where
h() has no "side effects" (i.e., h() is not a state-changingmethod), and
o the mathematical set {X, Y} has cardinality 1.
An abstract representation of object identity is by means of a "logicalidentifier" ("LID"), which is an implementation-free tokenthat is uniquely associated with a specific object. The term "objectidentifier" ("OID") refers to a specific implementationof a logical identifier. OIDs are normally system-generated, with a fixedformat, and are not changeable by the user. In models which consider literalsor extensional sets to be objects, such objects have LIDs but possiblynot OIDs.
An LID is meaningful within some limited scope which we shall call an"object space". Object creation occurs within an object space.Each creation event results in a LID that identifies the created objectuniquely within that space. The creation event creates a representationof the object in the space.
An LID is unique within a particular object space. If X and Y are objectswithin an object space, X == Y if X and Y have the same LID. In many implementations,simple comparison of OID and literal representations is used as the basisfor "==". An LID from one object space is not a valid LID inanother object space. Identity comparison between LIDs only makes sensewhen they are defined in the same object space. Object identifiers arehandled differently in different systems when objects are exported, imported,replicated, versioned, or distributed.
7. Types and Classes
The object paradigm deals with both abstract, external behavior, andimplementation. Objects may be grouped into types by commonality of behavior(interface), and into classes by commonality of implementations7.
A "type" defines a protocol shared by a group of objects,called "instances" of the type. The type itself may be an object.
A "class" defines an implementation (methods and data structures)shared by a group of objects. A class may be considered an implementationof a type. There may be several classes (implementations) per type. Theclass itself may be an object; methods may also be objects.
The "signature" of an operation identifies the number andtypes of the operation's arguments and results. In classical object models,an operation is associated with the type of its recipient, and a methodis associated with the class of its recipient. In generalized models, anoperation is associated with the types of its parameters, and a methodis associated with the classes of its parameters. Thus, in generalizedmodels, operations and methods may be "jointly owned" by multipletypes and classes. In general, objects can have multiple types and classes,and these can change. Not all models permit this.
A "parameterized type" is the result of a compile-time operationthat takes classes as parameters and returns one or more derived classes,e.g., set<employee> might return "class set-employee,"the definition of a set class corresponding to a set of employee classinstances.
7 Within this section, the terms "type"and "class" are used prescriptively. While it is important todefine precisely the terms "type" and "class," almosteverywhere in this document except this section, the terms are used interchangeably.The term "class" is used uniformly in the rest of the documentbecause it is used in X3J13 Common Lisp (CLOS), X3J16 C++, and Smalltalk.Some programming languages like C++ define "type" to be a restrictedform of class without encapsulation, inheritance, and behavior and "class"to include these object concepts.
8. Inheritance and Delegation
"Inheritance" and "delegation" both involve derivingnew definitions from existing ones.
In "class-class inheritance", classes are arranged as nodesin a graph, with unidirectional links between nodes defining inheritancepaths. "Subclasses" ("derived classes") are "specializations"of their more general parent classes. "Superclasses" ("baseclasses") represent "generalization" of their child classes.
Conflicting definitions of protocol, behavior, and state may be inheritedalong paths of the inheritance graph and are resolved in system-dependentways. Different "conflict resolution" and "method combination"strategies are used in different systems to define the semantics of inheritance.When creating a subclass, attributes and operations may be added to thoseinherited from the superclasses, or they may selectively "override"(replace), or "block" (hide) those from the superclass.
The two most common forms of class-class inheritance are "singleinheritance", where the graph is a tree, and "multiple inheritance",where the graph is a directed acyclic graph.
In "class-instance inheritance", instances of a class inherita common interface and an initial state (default or initial values of certainattributes) from the class.
In "delegation", which can be characterized as "instance-instanceinheritance", an object assigns or transfers behavioral definitionsor implementations or state to another object. Some delegation-based systemsdo not differentiate between class and instances. Object-to-object delegationgeneralizes both class-class inheritance and class-instance inheritance.
9. Noteworthy Objects
Different object models may distinguish or provide special support forthe noteworthy objects identified in the following subsections. The listis not exhaustive nor are the objects with the characteristics identifiedhere necessarily mutually exclusive. Some may not be treated as objectsin all object models.
9.1 relationships
A "relationship" ("association") is a logical relationbetween instances of one or more classes of objects. Relationships canbe binary or n-ary. Binary relationships may be one-to-one, one-many, ormany-many.
In generalized object models, a relationship may be realized as a separateclass, as an operation along with its result, as a separate modeling construct,or not at all. In different object systems, relationships can be established,traversed, or removed, and may be system or user defined. In differentsystems, the implementation of relationships may be unidirectional or bi-directional.
9.2. attributes
In some object models, object interfaces only contain explicitly definedoperations. In other models, interfaces include operations which are implicitlydefined in terms of logical "attributes" ("properties","instance variables", "data members") or other structuralconstructs (independent of implementation). Typically, defining an attributeA implicitly defines the inclusion of operations such as Get A and/or SetA in the interface of an object.
Attribute values are defined by a class which constrains possible values.Attribute values may be single- or multi-valued. Attributes are sometimesused to represent binary relationships.
9.3 literals
"Literals" are objects such as numbers and character strings.Literal values are similar to created objects in that both may occur asoperands of operations. Literal values are different from created objectsin that they have immutable state and they do not have a create operationbecause their representations are explicitly recognized. For example, multipleoccurrences of the same literal number are all references to the same pointon the number line. Operations which return literal values are constructingreferences to objects, not creating objects. In most object systems, ifX and Y are literals, X == Y only if X and Y represent the same literal.
9.4 containment
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.
9.5 aggregates
"Aggregate objects" such as sets, bags, lists, tuples, arrays,etc.,\footnote{These are logical constructs distinct from implementation-specificdata structures.} are containment constructs that group other objects organizedin some manner. Aggregates typically support operations to access individualmembers, and to iterate over all members, as in queries. Aggregates maybe "homogeneous", containing only objects from the same classor from classes inheriting from the same class, or they may be "heterogeneous",containing objects from any class.
With respect to identity, there are two kinds of aggregate objects."Intensional" aggregates have an identity based upon their creationevent. "Extensional" aggregates have an identity based upon theirmembership. If X and Y are the LIDs of extensional sets, then X == Y isequivalent to X and Y having the same members. For an intensional set,the membership at any time corresponds to an extensional set. Two intensionalsets remain distinct objects if they have the same members. If the membershipof an intensional set changes, the identity of the set does not change.
9.6 other
In various object models, the following may not be treated as objects
o operations.
o classes/types.
o some of the arguments of an operation.
o the result of an operation.
o relationships and attributes.
o literals.
o aggregates.
10. Extensibility
"Extensibility" allows additions and modifications to existingclasses. There are several kinds of extensibility:
o New classes may be defined, commonly based on existing classes.
o Existing classes may be modified to add new operations, attributes,constraints, or implementations. This extends the protocol of the class.
o Existing instances may acquire or lose a type (e.g. as when a "student"becomes an "employee").
The term "schema evolution" is used for operations that modifyexisting class definitions or the inheritance graph; the term "instanceevolution" is used for the process of making existing instances consistentwith modified class definitions.
10.1 dynamic
See entry under 10. Extensibility.
10.2 metaclasses/metaobject protocol
Not addressed.
10.3 introspection
Not addressed except implicitly as a requirement for schema or instanceevolution to occur.
11. Object Languages
Closely related to an object model is a language, referred to as an"Object Language" ("OL"): it can be used to specifygeneral programming operations. In other cases, it may be restricted, e.g.to a query language. An OL may or may not be an existing programming language(which may also support non-object-oriented programming).
12. Semantics of Base Classes (+type constructors)
Not addressed.
13. Background and References
X3/SPARC/DBSSG/OODB Task Group was commissioned in 1989 to characterizeOODB systems and determine a roadmap for standards in the OODB area. Itsfinal report was completed in September, 1991. As part of its referencemodel characterizing OODBs, a stand alone section was written that defines"General Characteristics of Object Models." Material from thischapter is included in this features matrix.
The document reference is:
"General Characteristics of Object Models," section 3.2 in:Bill Kent, Allen Otis, Craig Thompson (editors), "Object Data ManagementReference Model", section 3 in: Elizabeth Fong, William Kent, KenMoore, and Craig Thompson (editors). "X3/SPARC/DBSSG/OODBTG FinalReport," 17 September, 1991. Available from NIST (Elizabeth Fong atFONG@ECF.NCSL.NIST.GOV)