1parameters with names xi and types si, and m0results with names yi and types ri. 0. Intended Use
1. Basic Concepts
4.2.1 Basic Concepts
The OMG Object Model is based on a small number of basic concepts: objects,operations, types, and subtyping. An object can model any kind of entity,for example a person, a ship, a document, a department, a tuple, a file,a window manager, or a lexical scanner. A basic characteristic of an objectis its distinct identity, which is immutable, persists for as long as theobject exists, and is independent of the object's properties or behavior.
4.1.5 Profiles
There exists a wide range of domains that place requirements on theobject model, for example databases, user interfaces, and programming languages.Unfortunately, not all of these domains agree on the importance/relevanceof all aspects that could be defined to the object model. Thus, the CoreModel, defined in section 4.2, has been defined to capture a set of objectmodel concepts that all domains must support, and components, describedin the OMG OM Components Guide, have been defined to permit important extensionsto the core model.
Editor's note: the OMG OM Components Guide exists in draft form only.
Profiles exist to group components. A particular domain will group componentswhich provide extensions that the domain considers important to meet theneeds to its specific user community. Profiles can be technology-based;for example databases or programming languages. Profiles can also be application-based;for example CAD or Finance.
Some example profiles that are being considered include:
o Object request broker
o Object database
o Requirements and Analysis
o User interface
2. Objects
See entry under 2.1 operations
2.1 Operations
4.2.1 Basic Concepts
...
Operations are applied to objects1.Thus, to determine a person's date of birth, the date_of_birth operationis applied to the appropriate person object. The relationship betweena person and his/her spouse may be modeled as an operation spouseon one person object which returns another person object. The operationsassociated with an object collectively characterize its behavior.
...
1 This chapter speaks in terms of 'operationsbeing applied to objects.' This same concept can be described as 'sendingrequests to objects.' For the purposes of the Core Object Model the twophrases mean the same thing.
4.2.5 Operations
An operation describes an action that can be applied to arguments. Anoperation invocation, called a request, is an event (like a procedureinvocation or function call) that indicates an operation and possibly listssome arguments on behalf of a requester (client), possibly causing resultsto be returned. The consequences of a request can include:
1. An immediate set of results.
2. Side effects, manifested in changes of state.
3. Exceptions (currently not part of the Core Object model). An exceptionpackages information indicating that some unusual event has occurred andpasses that information to an exception handler.
Each operation has a signature. The signature includes the operation'sname, list of arguments, and list of return values, if any. For example,
operation_name (param-1, ..., param-n) returns (res-1, ..., res-m)
param-i ::= parameter_name: parameter_type res-i ::= result_name: result_type
The Object Model does not describe the syntax of operation specification.For example, it does not specify how results are to be associated withvariables. The above syntax is simply for illustrative purposes.
Formally, an operation W has the signature
w : (x1:s1, x2:s2,...,xn:sn) --> (y1:r1,y2:r2,..., ym:rm)
w is the name of the operation. The operationsignature specifies n1parameters with names xi and types si, and m0results with names yi and types ri.
In the Core Object Model, operations are always specified with a controllingparameter. For discussion purposes this section will assume that thefirst parameter (x1) is the controlling parameter although the Core modeldoes not require this. Each object type T
OTypeshas a set of operations Ops(T) = {WT1, WT2,...}.
An operation is part of the interface of its controlling parameter'stype and the interface of all subtypes of that type (see section 4.2.6).An operation is defined on the type of its controlling parameter;for example, W is defined on s17.All operations defined on a type have distinct names. In the Core Model,an operation is defined on a single type (the type of the controlling parameter,so there is no notion of an operation independent of a type, or of an operationdefined on two or more types8.
In the Core Object Model, operations can only be defined on object types,not on non- object types. The controlling parameter type may only be anelement of OTypes. However, with the exception of the controlling parametertype s1, si and rican be elements of OTypes » NTypes.
An operation may have side effects. The model does not distinguish asubcategory of operations that are side-effect free.
The Core Object Model does not address exception handling. Exceptionsare intended to be introduced as a component and can therefore be includedin profiles.
The Core Object Model does not specify anything about the executionorder for operations. For example, whether or not clients issue requestssequentially or concurrently is not part of the Core Model. Furthermore,whether or not requests get serviced sequentially or concurrently is alsonot part of the Core Model. Although the Core does not specify supportfor sequential or concurrent operations, it does not preclude an implementationfrom providing such support.
The Core Model does not require support for atomic operation execution;nor does it preclude it. An implementation might chose to provide atomicoperations in lieu of separate transaction_begin, transaction_commit, andtransaction_abort operations.
In the Core Object Model, operations (definitions of signatures) arenot objects. Requests (operation invocations) are also not defined to beobjects.
The Core Object Model does not require a formal specification of thesemantics of an operation, although it is good practice to include a commentthat specifies the purpose of the operation, any side effects it has, andany invariants it is intended to preserve.
7 Note that 'defined on' does not referto a lexical scope or context where the operation is syntactically specified.]
8 Requiring operations to be definedon a single type is sometimes referred to as the 'classical' object model.Relaxing this constraint to allow operations to be defined on zero or moretypes is called the 'generalized' object model. The Core Object Model isa 'classical' model.
2.2 requests
4.2.6.3 Operation Dispatching
When an operation request is issued, a specific operation implementation(method) is selected for execution. This selection process is called operationdispatching. In the Core model, the process of selecting an implementationto invoke is based on the type of the object supplied as the controllingargument of the actual call11. The operationof the given name defined on the immediate type of the controlling argumentis chosen for invocation. In some cases this can be done at compile timewith no loss of flexibility, in others it must be delayed to executiontime.
4.2.7 Argument Passing and Results
Consider an operation W with the signature
w : (x1:s1, x2:s2,...,xn:sn) --> (y1:r1,y2:r2,..., ym:rm)
An invocation (request) of W might be writtenas:
r1,..., rm <-- w (E1,...,En)
where w is the name of W,Ei are expressions providing the input arguments, and ri accept the returnresults.
The request is legal if the expressions E1,...,En evaluate to a1,...,anand the immediate type of ai £si (£ is thesubtype relationship). The signature guarantees that the request returnsa set of results, b1,...,bm,and the immediate type of bi £ri.
Note that if the types of the arguments or results of Wbelong to NTypes then the subtype check is defined by the component thatdefines the non-object types. In most cases this is likely to be type equality.
The execution semantics consists of binding arguments and return valuesto formal parameters. The expressions Ei result in either non-objects orOIDs (collectively dvals). Operationally, these dvals are copied into theformal parameters. How the effect of copying is accomplished is not specified,nor is it required that the OIDs be the same, only that the object theyrefer to be the same. The objects that the OIDs refer to are notcopied. For example, consider the following operation specification andinvocation:
operation X defined in Type T
...
X (x: T)
X being invoked in some code
...
X (a_T)
Following the invocation, x refers to the same object as a_T. Operationrequests made to the OID in x will function exactly as if they had beenmade to the OID in a_T. It is not the case, however, that an assignmentto x will change a_T (or even the object x refers to). In this sense, theCore Model defines a pass-by-value parameter passing semantics.
11 The single controlling argument restrictioncan be relaxed in a component and generalized to multiple argument dispatching.
2.3 messages
2.4 specification of behavioral semantics
2.5 methods
2.6 state
4.2.1 Basic Concepts
...
State is required in an object system because it captures the informationneeded to affect operations. For example, the operation marry takestwo person objects as input arguments and produces side effectson these two objects. State captures these side effects, and, presumably,a subsequent application of the spouse function to either objectwill now yield a different result from what it did before. In the CoreObject Model, operations are used to model the external interface to state.Attributes and relationships, which can be used to model the externallyvisible declarations of state more succinctly, are currently defined inthe OMG OM Components Guide.
...
Editor's note: the OMG OM Components Guide exists in draft form only.
4.2.8.1 Example type interface
...
The Core Object model does not formally define state but acknowledgesthat the execution of some operations may affect the way the same operationor other operations behave in the future.
2.7 object lifetime
2.8 behavior/state grouping
2.9 communication model
2.10 events
2.11 transition rules
3. Binding
4.2.6.3 Operation Dispatching
When an operation request is issued, a specific operation implementation(method) is selected for execution. This selection process is called operationdispatching. In the Core model, the process of selecting an implementationto invoke is based on the type of the object supplied as the controllingargument of the actual call11. The operationof the given name defined on the immediate type of the controlling argumentis chosen for invocation. In some cases this can be done at compile timewith no loss of flexibility, in others it must be delayed to executiontime.
11 The single controlling argument restrictioncan be relaxed in a component and generalized to multiple argument dispatching.
4. Polymorphism
The Core Object Model supports the kind of polymorphism generated bysubtyping, and does not rule out other forms of polymorphism. See entriesunder 2.2 requests, 7. Types and Classes, and 8. Inheritanceand Delegation.
5. Encapsulation
4.2.8 Interfaces of a Type
In the Core Object Model a type exports all of the operations that aredefined on it. There is no notion of multiple named interfaces definedon a type that exports less than the full type specification. Visibilityattributes such as private, public, subtype_visible, and friends are notsupported either. These may be defined by components.
There is also no notion of a program binding to a subschema that restrictsa program's access to some subset of the types defined in the system, andfor any type within this subset, further restricts access to some subsetof the characteristics defined by the type. Subschemas and subschema-specificinterfaces to types may also be defined in a component.
4.2.8.1 Example type interface
A type's interface defines the externally visible state and behaviorof instances of the type. Behavior is defined as a set of operation signatures.The following example shows the interface portion of an object type definitionthat illustrates these concepts. The syntax is illustrative only.
type IMAGE supertypes: OBJECT
operations: INTEGER get_length (i:IMAGE) set_length (i:IMAGE, length: INTEGER) INTEGER get_width (i:IMAGE) set_width (i:IMAGE, width: INTEGER) scale (i:IMAGE, by:FACTOR) rotate (i:IMAGE, by:DEGREES) IMAGE crop (i:IMAGE, to:SIZE)
end_type
6. Identity, Equality, Copy
4.2.2 Object Identity and Object Identifiers
Each object has a unique identity that is distinct from and independentof any of its characteristics. Characteristics can vary over time whereasidentity is constant.
In the Core Model, each object has an identifier that providesa means to denote or refer to the object. This identifier is called anOID3. OIDs label (or refer to) objects.The set of all OIDs is denoted as Obj.
The Core Object Model does not require systems to support a comparisonoperation for OIDs. In other words, you may not be able to ask if two OIDsrefer to the same object. However, if two OIDs, A and B, refer to the sameobject, then invoking an operation with A as an argument is the same asinvoking that operation with B in place of A.
The implementation of OIDs is not within the realm of the Object Model.The Object Model does not specify if OIDs are fixed length or varying insize. For example, there is no assumption that OIDs are 32, 64, or 128-bitstrings. Furthermore, the Model does not care about the internal structureof an OID. For example, it does not state that the location of the objectis encoded within an OID in some way known to the system or its users.OIDs are opaque as far as the Object Model is concerned.
3 OIDs in the Object Model denote thesame concept as object references in CORBA.
7. Types and Classes
4.2.1 Basic Concepts
...
Objects are created as instances of types2(for example, integer, person, ship, stack).A type characterizes the behavior of its instances by describing the operationsthat can be applied to those objects. Types can be related to one anotherthrough supertype/subtype relationships. ...
2 Saying that an object is 'an instanceof type T' is the same as saying that an object is 'of type T' in thismodel.
4.2.3 Object Types
Objects support only certain operations. The operations applicable toan object collectively characterize its behavior. Types describe theseoperations and thus characterize the behavior of objects. Objects are createdas instances of their types and in the Core Object Model objects do notchange their type.
Each operation has a signature, which consists of a name, set of parameters4,and set of results (see section 4.2.5). The set of operation signaturesdefined on a type is called the type's interface. A type's interfaceincludes signatures that are inherited from supertypes (see section 4.2.6).Every instance of a type satisfies the interface of that type.
Types are arranged into a type hierarchy that forms a directed acyclicgraph. The root of this type hierarchy is the type Object. Applicationsintroduce new types by subtyping from Object. Having a single root allowsprograms to specify that an argument can take an object of any type. Theset of all object types is referred to as OTypes.
A type is distinct from its interface and its set of instances (extension).Both its interface and extension can change over time, without changingthe identity of the type. Although the Core defines types and operationsas concepts, systems that comply to the model need not provide objectsthat correspond to these concepts. Types and operations as objects willbe considered for inclusion in the Meta_data component of the OMG OM ComponentsGuide.
Editor's note: the OMG OM Components Guide exists in draft form only.
4 In the Core Model, the term parameteris used when referring to the declaration of an operation's interface.Argument is used when referring to an operation invocation.
4.2.9 Implementation
As noted earlier, the Object Model formally specifies only the semanticsof objects. It has nothing to say about their implementation. It neitherrequires nor excludes systems in which there is more than one implementationfor a given type. It permits systems in which each object type has a separateimplementation, or in which clusters of related types share an implementation.
The combination of a type specification and one of the implementationsdefined for that type is termed a class. An individual object, atany given point in time, is an instance of one class. The model makes nostatement about whether an object must retain the implementation chosenfor it at the time it was created or whether an object can change implementationsover its lifetime. Moreover, implementations may vary among different instancesof a type, and even for the same instance over time.
Allowing multiple implementations for a given type specification seemsnecessary to support several domains including databases that span networksthat include machines with different architectures, and mixed-languageenvironments. But even in a single- machine, single-language environmentthere are cases where the programmer wants to have available differentimplementations of a type based on different data structures or algorithms.In the absence of multiple implementations for a single type, the typeprogrammer would be forced to abuse the subtype mechanism to achieve thisdifferentiation; for instance, by defining a distinct subtype for eachdistinct implementation of a type. Set_as_Btree and Set_as_Linked_Listwould be introduced, for example, as subtypes of the type Set,rather than as alternate implementations for the type Set.
8. Inheritance and Delegation
4.2.6 Subtyping and inheritance
Subtyping is a relationship between types based on their interfaces.It defines the rules by which objects of one type are determined to beacceptable in contexts expecting another type. Inheritance is amechanism for reuse. It allows a type to be defined in terms of anothertype. Many object systems do not distinguish between subtyping and inheritance.This section defines the two concepts separately, but then explicitly stateshow they are related in the Core Object Model.
4.2.6.1 Subtyping
The Core Object Model supports subtyping for Object types. Intuitivelyone type is a subtype of another if the first is a specialization or arefinement of the second. Operationally, this means that any object ofthe first type can be used in any context which expects an object of thesecond type; that is, if S is a subtype of T, an object of type S may beused wherever an object of type T may be used. In other words, objectsof type S are also of type T. Subtypes can have multiple parent types,with the implication that an object that is an instance of a type S isalso an instance of all supertypes of type S. The relationships betweentypes define a type hierarchy, which can be drawn as a directed acyclicgraph.
An object is a direct instance of a type if it is an instance of thattype and not an instance of any subtype of that type. The Core Object modelrestricts objects to be direct instances of exactly one type. That onetype is the object's immediate type. The Core Object model has nomechanism for an object to change its immediate type.
In the Core Model, the type designer is required to declare the intentthat a type S is a subtype of T. Formally, if S is declared to be a subtypeof T (and conversely, T is a supertype of S), then for each operation WTiOps(T)there exists a corresponding operation WSjOps(S)such that the following conditions hold:
1. the name of the operations match
2. the number and types of the parameters are the same (except thatthe controlling parameter types may differ)
3. the number and types of the results are the same.
Thus, for every operation in T there must be a corresponding operationin S, though there may be more operations in Ops(S) than Ops(T). The specificationsof corresponding operations must match precisely (with the exception ofthe controlling argument).
The Core Object Model presents very strict typing rules that ensurethat substitutability9 can be guaranteedusing the information in the specifications. These rules can be relaxedsomewhat and still guarantee substitutability. One of the components definedin the OMG OM Components Guide describes a modified set of rules that loosenthe above conditions to allow argument and result types to differ but stillpreserve substitutability.
Editor's note: the OMG OM Components Guide exists in draft form only.
A single type can have multiple supertypes in the Core Object Model.The above typing rules, however, prevent two types that have an operationwith the same name but different signatures from having a common subtype.
Supertypes are used to characterize functionality that is common totheir subtypes. Often a supertype's interface is incomplete as a standalonetype. It relies on its subtypes to extend the interface. Other times, asupertype specifies a complete definition of some type, but the type isuseful only when it is combined with other types in a new subtype. In bothcases the supertype does not have any direct instances of its own. Onlysubtypes of this supertype can have direct instances. The Core Object modelrefers to these types as Abstract types.
4.2.6.2 Inheritance
Inheritance is a notational mechanism for defining a type S interms of another type T. The definition of S inherits all the operationsof T and may provide other operations. Intuitively, inherit means thatthe operations defined for T are also defined for or can be used by S10.
Subtyping is a relationship between interfaces (types). Inheritancecan apply to both interfaces and implementations; that is both interfacesand implementations can be inherited. The Core Object model is concernedwith inheritance of interfaces. It does not specify what can happen withimplementations of inherited operations (for example, whether they maybe changed or overridden by a subtype).
The Core Object Model relates subtyping and inheritance. If S is declaredto be a subtype of T, then S also inherits from T. The Core Object modelsupports multiple inheritance, which allows a subtype to have multiplesupertypes. The Core does not provide a name conflict resolution mechanismnor does it allow subtypes to redefine inherited operation signatures.These two constraints are relaxed in a component defined in the OMG OMComponents Guide.
Editor's note: the OMG OM Components Guide exists in draft form only.
Consider the following type definitions
type Person abstract supertypes: Object
operations: String social_security (P: Person) String name (P: Person)
end type
type Employee supertypes: Person
operations: Department dept (E: Employee) Money salary (E: Employee)
end type
In this example, type Employee is declared to be a subtype of type Person.In the Core Object Model this implies that
1. all instances of type Employee are also instances of type Person,and so an Employee object can be used wherever a Person object is expected.
2. Employee inherits the name and social_security operations from Person.
Furthermore, Person is declared to be an abstract type and so it cannothave any direct instances.
9 Substitutability means being ableto substitute an object of some type S when an object of type T is expected,where T is a supertype of S, while guaranteeing that that the substitutedobject will support the same operations as specified by the supertype T.
10 Whether Ops(S) is a superset of Ops(T)or the two are disjoint sets is an implementation issue and does not affectthe Core semantics.
9. Noteworthy Objects
4.2.1 Basic Concepts
...
State is required in an object system because it captures the informationneeded to affect operations. For example, the operation marry takestwo person objects as input arguments and produces side effectson these two objects. State captures these side effects, and, presumably,a subsequent application of the spouse function to either objectwill now yield a different result from what it did before. In the CoreObject Model, operations are used to model the external interface to state.Attributes and relationships, which can be used to model the externallyvisible declarations of state more succinctly, are currently defined inthe OMG OM Components Guide.
Editor's note: the OMG OM Components Guide exists in draft form only.
9.1 relationships
See entry under 9. Noteworthy Objects.
9.2. attributes
See entry under 9. Noteworthy Objects.
9.3 literals
4.2.4 Non-object types
Many object systems, for example C++ and CORBA, explicitly distinguishbetween objects and things that are not objects5.The Core Object Model has chosen to recognize that this distinction exists.Things that are not objects are called non-objects6.Objects and non-objects collectively represent the set of denotable valuesin the Object Model.
In the Core Object Model, non-objects are not labeled by an object reference,and therefore cannot be the controlling parameter for an operation request.Each non-object can be considered to belong to a type of value, calleda Non-object type. This is analogous to objects being instancesof types. Non-object types, however, do not belong to the Object type-hierarchy.Thus non-object types are not subtypes of Object. Moreover, the rules forsubtyping and inheritance defined later in this section do not apply tonon-object types. Components can add more structure to the non-object types;for example, a component could define subtyping and inheritance rules fornon-object types.
The Core does not specify a set of non-object types; these types aredefined in a component and chosen for inclusion in a Profile. For example,CORBA would define in its profile that the non-object types would include:Short, Long, UShort, Ulong, Float, Double, Char, String, Boolean, Octet,Enum, Struct, Sequence, Union, and Array. The set of non-object types canbe extended by adding new types to the Non-object component.
Editor's Note: Presumably, any operations defined for non-objecttypes would also have to be defined in components, since operations canonly be defined on object types in the Core.
Profiles can choose which non-object types to support. In a pure objectsystem, such as Smalltalk, all denotable values are expressed as objectsand so the set of non-object types may be empty. Thus profiles are allowedto make the difference between the set of objects and set of non-objectsthat they recognize as wide or as narrow as needed.
The set of all non-object types is called NTypes. The set ofall non-objects is called Nobj. The complete set of values thatmay be manipulated in the Core Object Model is described as DVal = Obj» Nobj. DVal can be thought of as thedenotable values in the Core Object Model. The elements of DVal are calleddvals. DVal is not a type in the Core Object Model. It does notexist as a supertype of Object and the types in NTypes. Therefore, youcannot specify, for example, an operation parameter that may be eitheran object or a non-object. This eliminates the difficulty of systems havingto provide run-time discrimination of objects and non-objects.
The remainder of this section deals primarily with objects. Unless otherwisenoted, when this chapter refers to type it means object type.
5 In the sense that objects have beendefined in the Core Model.
6 Examples of non-objects are the basicand constructed values as defined in the CORBA specification.
9.4 containment
9.5 aggregates
9.6 other
10. Extensibility
10.1 dynamic
10.2 metaclasses/metaobject protocol
10.3 introspection
4.2.3 Object Types
...
Although the Core defines types and operations as concepts, systemsthat comply to the model need not provide objects that correspond to theseconcepts. Types and operations as objects will be considered for inclusionin the Meta_data component of the OMG OM Components Guide.
Editor's note: the OMG OM Components Guide exists in draft form only.
11. Object Languages
12. Semantics of Base Classes (+type constructors)
13. Background and References
This text comes from chapter 4 of Richard Mark Soley, Ph.D. (ed.), ObjectManagement Architecture Guide, Revision 2.0, Second Edition, OMG TCDocument 92.11.1, Object Management Group, September 1, 1992.