Unformatted text preview:

The Object Model3.1 Overview3.2 Object Semantics3.2.1 Objects3.2.2 Requests3.2.3 Object Creation and Destruction3.2.4 Types3.2.5 Interfaces3.2.6 Operations3.2.7 Attributes3.3 Object Implementation3.3.1 The Execution Model: Performing Services3.3.2 The Construction ModelA Discussion of the Object Management Architecture 3-1The Object Model33.1 OverviewThe object model provides an organized presentation of object concepts and terminology. It defines a partial model for computation that embodies the key characteristics of objects as realized by the submitted technologies. The OMG object model is abstract in that it is not directly realized by any particular technology. The model described here is a concrete object model. A concrete object model may differ from the abstract object model in several ways:• It may elaborate the abstract object model by making it more specific, for example, by defining the form of request parameters or the language used to specify types• It may populate the model by introducing specific instances of entities defined by the model, for example, specific objects, specific operations, or specific types• It may restrict the model by eliminating entities or placing additional restrictions on their useAn object system is a collection of objects that isolates the requestors of services (clients) from the providers of services by a well-defined encapsulating interface. In particular, clients are isolated from the implementations of services as data representations and executable code.The object model first describes concepts that are meaningful to clients, including such concepts as object creation and identity, requests and operations, types and signatures. It then describes concepts related to object implementations, including such concepts as methods, execution engines, and activation.The object model is most specific and prescriptive in defining concepts meaningful to clients. The discussion of object implementation is more suggestive, with the intent of allowing maximal freedom for different object technologies to provide different ways of implementing objects.3-2 A Discussion of the Object Management Architecture3There are some other characteristics of object systems that are outside the scope of the object model. Some of these concepts are aspects of application architecture, some are associated with specific domains to which object technology is applied. Such concepts are more properly dealt with in an architectural reference model. Examples of excluded concepts are compound objects, links, copying of objects, change management, and transactions. Also outside the scope of the object model is the model of control and execution.This object model is an example of a classical object model, where a client sends a message to an object. Conceptually, the object interprets the message to decide what service to perform. In the classical model, a message identifies an object and zero or more actual parameters. As in most classical object models, a distinguished first parameter is required, which identifies the operation to be performed; the interpretation of the message by the object involves selecting a method based on the specified operation. Operationally, of course, method selection could be performed either by the object or the ORB.3.2 Object SemanticsAn object system provides services to clients. A client of a service is any entity capable of requesting the service.This section defines the concepts associated with object semantics, that is, the concepts relevant to clients.3.2.1 ObjectsAn object system includes entities known as objects. An object is an identifiable, encapsulated entity that provides one or more services that can be requested by a client.3.2.2 RequestsClients request services by issuing requests. A request is an event, i.e. something that occurs at a particular time. The information associated with a request consists of an operation, a target object, zero or more (actual) parameters, and an optional request context.A request form is a description or pattern that can be evaluated or performed multiple times to cause the issuing of requests. As described in the OMG IDL Syntax and Semantics chapter, request forms are defined by particular language bindings. An alternative request form consists of calls to the dynamic invocation interface to create an invocation structure, add arguments to the invocation structure, and to issue the invocation. A value is anything that may be a legitimate (actual) parameter in a request. A value may identify an object, for the purpose of performing the request. A value that identifies an object is called an object name. More particularly, a value is an instance of an OMG IDL data type.OMA Object Semantics January 1997 3-33An object reference is an object name that reliably denotes a particular object. Specifically, an object reference will identify the same object each time the reference is used in a request (subject to certain pragmatic limits of space and time). An object may be denoted by multiple, distinct object references. A request may have parameters that are used to pass data to the target object; it may also have a request context which provides additional information about the request. A request causes a service to be performed on behalf of the client. One outcome of performing a service is returning to the client the results, if any, defined for the request. If an abnormal condition occurs during the performance of a request, an exception is returned. The exception may carry additional return parameters particular to that exception.The request parameters are identified by position. A parameter may be an input parameter, an output parameter, or an input-output parameter. A request may also return a single result value, as well as any output parameters.The following semantics hold for all requests:• Any aliasing of parameter values is neither guaranteed removed nor guaranteed to be preserved• The order in which aliased output parameters are written is not guaranteed• Any output parameters are undefined if an exception is returned• The values that can be returned in an input-output parameter may be constrained by the value that was inputDescriptions of the values and exceptions that are permitted, see 3 and 7. 3.2.3 Object Creation and DestructionObjects can be created and destroyed. From a client’s point of view, there is no special mechanism for creating or destroying an object.


View Full Document

Toronto ECE 1770 - The Object Model

Download The Object Model
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view The Object Model and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view The Object Model 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?