ODP Object Model

0. Intended Use

1. Basic Concepts

2. Objects

2.1 Operations

ODP has specified construction models for each of its languages, theseare specified at length in RM-ODP Part 3 - Prescriptive Model.

2.2 requests

Computationally, supports requests

2.3 messages

Generally, messages are used in object interactions, but not explicitlyidentified. Rather, only the notion of interaction is identified.

2.4 specification of behavioral semantics

Behavior (of an object) is defined as follows" "A collectionof actions with a set of constraints on the circumstances in which theymay possibly occur. The nature of the constraints which may be expresseddepends on the specification language in use. In general, there existsa set of possible sequences of observable actions consistent with any givenbehavior. A behavior may include internal actions. The actions that actuallytake place are restricted by the environment in which they object is placed.(part 2). The set of all sequences of operations that can occur from theinitial state based on legal state transitions determined by the pre-conditionsand post-conditions of the operations. (part 4).

Part 4 of the Reference Model for Open Distributed Processing describeshow architectural semantics of the Prescriptive Model (Part 2) may be specifiedusing several formal description techniques. These descriptions provideda very useful feedback for clarifying corresponding Clauses of Part 2.

Integrity constraints are considered a property of the model generatedfor the Information Language. Constraints are special relationships, whereeach relationship is associated with a predicate.

2.5 methods

Treated as a hidden property of a Technology Language object. That is,methods are considered implementation-only related properties of an object.

2.6 state

An object is characterized in RM-ODP Part 2 by its behavior and, dually,by its state.

State is defined in RM-ODP Part 2 as the condition of an object thatdetermines the set of all sequences of actions in which the object cantake part. Since, in general, behavior includes many possible series ofactions in which the object might take part, knowledge of state does notnecessarily allow the prediction of the sequence of actions which willactually occur. [In other words, a given state may imply the truth valueof preconditions for several different actions. In accordance with RM-ODPPart 4, legal state transitions are defined by the preconditions and postconditionsof the operations.] State changes are effected by actions; hence a stateis partially determined by the previous actions in which the object tookpart. An object is encapsulated, i.e. any change in its state can onlyoccur as a result of an internal action or as a result of an interactionwith its environment.

To be more specific, Part 4 of RM-ODP defines state as the values ofthe variables declared in the state schema associated with the class schemaof which the object is an instance. (Part 4).

2.7 object lifetime

Lifecycle issues are treated differently in ODP depending on whetherthe issue is being dealt with from an engineering (functional architecturalpackaging) or an implementation perspective.

ODP distinguishes between creation and introduction ofan object. Creation of an object is the action of instantiation,resulting in the existence of a new object. Instantiation of an objecttemplate is an object produced from a given object template and other necessaryinformation. The object exhibits the features specified in the object template.A template is the specification of the common features of a collectionof objects in sufficient detail that an object can be instantiated usingit. (An object template is an abstraction of a collection of objects).Instantiation of an object template may involve actualization of parameters,which may in turn involve instantiating other (object) templates or bindingof existing interfaces. Introduction of an object is instantiationof an object, when it is achieved by a mechanism which is not covered bythe model. (Any object is either created or introduced, but not both.)

Deletion of an object is the action of destroying an instantiated object.

Editor's Note: I believe that from a computational perspective, referencesmay exist to objects or interfaces that "disappear", either becausethey are deleted, or because of failures.

2.8 behavior/state grouping

Action: Something which happens. Every action of interest for modelingpurposes is associated with at least one object. (Part 2). The performanceof an operation is defined by an operation schema. The effect is the simultaneouschange of the state of an object or group of objects. (Part 4).

Contract: An agreement governing part of the collective behavior ofa set of objects. A contract places obligations on the objects involved.(Part 2, Clause 10.2.2)

Invariant: A predicate that a specification requires to be true forthe entire life time of a set of objects."

2.9 communication model

2.10 events

2.11 transition rules

3. Binding

In general, the binding process involves the establishment of supportingcommunication functions and the initialization of functions. This processcontinues recursively until it is terminated by the use of binding (contexts)which already exist and can thus already support interactions. A bindingis characterized by:

Binding can refer to a process - "binding A to B". This ideacorresponds to the notion of an establishing behavior.

Binding can refer to a state of affairs - "a binding exists betweenA and B". This idea corresponds to the notion of a context. When abinding exits, there is an appearance of an end-to-end path between theobjects bound. A binding (context) represents the commitment of resourcesand the assumption of stability of aspects of a configuration. The thingmade possible by a binding is an enabled behavior.

A (necessary but not sufficient) precondition for the establishing behavioris the possession of an interface reference. The fulfillment of this preconditioncorresponds to the notion of a reference binding.

The process of unbinding corresponds to the notion of a terminationbehavior (not to be confused with an interrogation termination). In orderfor two interfaces to bind, at least one interface must posses an interfacereference to the other. This information may be passed some type of intermediary.

A binding is composed of:

an interface offer: information declaring the existence of an interfaceto which other objects may bind. The information will include the interfacereference and the interface type reference. The term service offer is equivalentbut is not used here.

an acquire: obtaining an interface offer

an acquirer: the object which obtains an interface offer

an exporting: making an interface offer available to a trader

an importing: obtaining an interface offer from the trader

Editor's Note: this is a more general definition of "binding"than is used in the current feature definition, which restricts itselfto binding a method to an operation request.

4. Polymorphism

A fundamental notion of ODP, used extensively. The property of satisfyingmany types is known as polymorphism (literally: many forms). Polymorphismis the property that instances of one type can also behave or be treatedas though they are instances of another type. Subtyping automatically generatespolymorphism, but the two concepts are independent.

5. Encapsulation

A fundamental notion of ODP, used extensively. It is not possible to"look inside" any object.

The state of an object is accessible only through invocation of theservices supported by the object. Users (i.e., clients) of objects arepermitted only to know what the object does, not how it does it.

Encapsulation is enforced by only allowing an object to be accessedthrough invoking the operations defined in its interface. This kind ofde-coupling limits dependencies between objects, permitting them to bere-implemented, modified and extended without affecting existing clients.

Editor's Note: there is a need at this point to describe the abilitywithin the ODP model to define multiple interfaces for the same object.

6. Identity, Equality, Copy

The RM-ODP Descriptive model recognizes the notion of identity (andall naming actions in general) only relative to a given naming context.A naming context is defined as a relation between a set of names and aset of entities, whereby the set of names belongs to a single name space.An identifier is defined as an unambiguous name of an entity in such acontext.

As an object is a model of an entity, and an object is distinct fromany other object, it follows that every object has a unique identity (theidentity of a naming context and of the object within that context). Althoughnaming is explicitly defined only for entities, RM-ODP refers in additionto action identities [it may also be possible to consider an action asan entity because an action is a thing of interest, and an entity is definedas any concrete or abstract thing of interest]. As an interface is a setof (inter)actions, it has an identity; there exists also a reference inRM-ODP to a unique interface. As behavior is a collection of actions, italso has an identity.

Establishing object equality by comparing their properties (e.g., behaviors)is possible only at some abstraction level whereby details irrelevant forthis level are suppressed.

7. Types and Classes

A fundamental notion of ODP, used extensively.

A type is defined by a set of conditions and constraints, known as apredicate. An object instance is said to be of a particular type if itsatisfies the predicate. A type therefore identifies a collection of objectinstances (i.e., the instances that satisfy the predicate). Conversely,every arbitrary collection of object instances defines a type.

Strengthening a predicate (i.e., adding further conditions), definesa subtype. Under these circumstances the original (weaker) predicate issaid to define a supertype. Any object instance satisfying the subtypepredicate will also, by definition, satisfy the supertype predicate. Ifa type is thought of as identifying a set of instances, then a subtypeidentifies a subset of those instances. Each of subtype may in turn beused to generate further subtypes. Therefore, the subtyping relationshipdefines a type hierarchy.

It is necessary to describe the information associated with modelingconcepts, irrespective of the actual specification language. This is accomplishedthrough a template or a "form'' which supplies a syntactic frameworkto present the information employing these concepts.

Among the many possible groupings of object instances, some will beof greater interest than others. ODP allows these interesting collectionsof objects to be explicitly identified and named, through the use of templatetypes. A template type is a particular example of a type, carefully chosenby the specifier to identify a specific group of objects known as a class.The template type defines the type of each object instance belonging tothe class.

To provide a completely general model of classes, a template type ismodeled as a template and associated instantiation rules. The templatespecifies the common features of the object instances belonging to theclass, while the instantiation rules specify how to generate instancesfrom the template. Together they specify the template type. Note that,in practice, the instantiation rules will normally be fixed for a giventemplate specification language in a given environment. Under these circumstances,template type becomes synonymous with class template.

A subclass is defined by incrementally modifying the class template.The class, corresponding to the original template, is termed the superclass.Instances of the subclass do not necessarily form a subset of instancesof the superclass. That is, a subclass does not necessarily form a subsetof instances of the superclass and a subclass does not necessarily definea subtype. This depends upon the nature of permissible incremental modifications.If the class predicate can only be strengthened by incremental modificationsto the class template, then the type of a subclass will correspond to asubtype of the superclass' type. If, however, the predicate can be arbitrarilymodified, then this relationship will not necessarily hold.

In the same manner as types, classes can be arranged in a class hierarchyaccording to the superclass-subclass relationship.

8. Inheritance and Delegation

Supports multiple inheritance of which single inheritance is a constraint.

The inheritance mechanisms are implementation dependent.

Two major forms of inheritance are possible:

a. Incremental inheritance - related to the class hierarchy, occurswhen a new class template is explicitly represented in terms of an existingtemplate.

b. Subtyping - related to the type hierarchy, occurs when a new classtemplate, together with the instantiation rules, produces a stronger predicatethan the old template with the (same) instantiation rules.

9. Noteworthy Objects

9.1 relationships

Treated as an Information Viewpoint concept where virtually any conceptof a binary relationship can be defined.

9.2. attributes

Technically, treated as a relationship

9.3 literals

Only objects are addressed, of which literals could be considered aspecial type of object.

9.4 containment

ODP makes extensive use of composition of objects.

9.5 aggregates

In ODP, aggregates would likely be treated as a composition of object(i.e., a new object) with a particular behavior.

9.6 other

10. Extensibility

10.1 dynamic

See entry under 7. Types and Classes.

10.2 metaclasses/metaobject protocol

Considered a property of the model generated for the Information Language.Meta - whatever are considered second order constraints in the InformationLanguage.

10.3 introspection

Not a concept required or considered for ODP due the strong generalnotions of encapsulation.

But, every object instance is associated with an object type which inturn has a predicate.

Editor's note: I believe there is some misunderstanding here, sincethe ODP Trader function appears to involve providing some form of accessto descriptive information at run time in order to match client servicerequirements with service offerings. Perhaps the Trader is not requiredto actually allow the client to read the descriptions of service offerings.

11. Object Languages

RM-ODP Part 3 - The Prescriptive Model prescribes five conceptual languagescorresponding to the five ODP Viewpoints:

All five languages strongly adopt notions of the object paradigm.

It is likely that concrete programming languages for at least the Computationaland Engineering Language will evolve. It is also likely that "Z"(pronounced ZED) will be applied to the Information Viewpoint.

12. Semantics of Base Classes (+type constructors)

Described by the objects behavior

13. Background and References

ODP or Open Distributed Processing and specifically the Reference Modelfor ODP (RM-ODP) contains its own model for objects to support the ODPconcepts.

References:

[Part 1] ISO/IEC 10746-1. Information Technology - Open DistributedProcessing - Basic Reference Model of Open Distributed Processing - Part1: Overview and Guide to Use. (ISO/IEC JTC1/SC21 N 7053, September 1992).

[Part 2] ISO/IEC JTC1/SC21/WG7, Basic Reference Model of Open DistributedProcessing - Part 2: Descriptive Model. (CD 10746-2.3, June 1993).

[Part 3] ISO/IEC 10746-3. Information Technology - Open DistributedProcessing - Basic Reference Model of Open Distributed Processing - Part3: Prescriptive Model. (ISO/IEC JTC1/SC21 N 7055, September 1992).

[Part 4] ISO/IEC 10746-5. Information Technology - Open DistributedProcessing - Basic Reference Model of Open Distributed Processing - Part4: Architectural Semantics. (ISO/IEC JTC1/SC21 N 7056, September 1992).

featuresmatrix intro page