1parameters with names xi and types si, and m0results with names yi and types ri.OODBTG Reference Model
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.
OMG Core Object Model
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 'operations beingapplied to objects.' This same concept can be described as 'sending requeststo objects.' For the purposes of the Core Object Model the two phrasesmean 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 refer to a lexicalscope or context where the operation is syntactically specified.]
8 Requiring operations to be defined on a singletype is sometimes referred to as the 'classical' object model. Relaxingthis constraint to allow operations to be defined on zero or more typesis called the 'generalized' object model. The Core Object Model is a 'classical'model.
OMG CORBA IDL
An operation is an identifiable entity that denotes a service that canbe requested. An operation is identified by an operation identifier. Anoperation has a signature that describes the legitimate values of requestparameters and returned results. The signature consists of a specificationof parameters, the result of the operation, a specification of the exceptionsthat may be raised by a request and the types of parameters accompanyingthem, a specification of any contextual information and an indication ofthe execution semantics the client should expect [CORBA Specification 2.2.6Operations].
ODMG
Operations are defined on types. The interface of a type includes operationsignatures: argument names and types, possible exceptions, result types.The first argument of an operation is distinguished.
Operation names may be overloaded; dispatching is based on the mostspecific type of the first argument of the operation call. Operations mayhave side-effects; an operation with only side-effects can return a nilvalue. The model assumes operations will be executed sequentially.
Implications for optimization are that optimizers must be conservativesince an operation in a query might have side-effects. They suggest a "pragma"distinguishing operations that can safely occur in query expressions.
EXPRESS
Because it does not model dynamics, EXPRESS does not support much inthe way of operations. The specification of constraints requires some supportfor operations, but these operations cannot change the state of the populationbeing modeled. The operations include the builtin arithmetic, relational,logical, string, and aggregate operations. In addition, EXPRESS supportsbuiltin and user-defined functions and procedures. It is likely that futureversions of EXPRESS will provide significantly more support for operations.
Open Distributed Processing
ODP has specified construction models for each of its languages, theseare specified at length in RM-ODP Part 3 - Prescriptive Model.
Management Information Model
Operations may be directed to managed objects and notifications maybe emitted from managed objects. Operations and notifications apply acrossa managed object boundary and map onto underlying communications services,which for the purposes of systems management are the CMIS services definedin [ISO/IEC 9595].
All operations performed on a managed object are visible at the managedobject boundary and can succeed only if consistency constraints of themanaged object are not violated. An operation definition includes the directeffect of the operation on the managed object. In addition to the directeffects of an operation on a managed object, which are defined by the operation,indirect effects may also occur as a result of the relationships in theunderlying resource.
There are two types of operations that may be directed to a managedobject: attribute-oriented operations and object-oriented operations (describedbelow). Notifications are information emitted from managed objects uponan occurrence of an event.
Attribute-oriented operations are applied to the attributes of an object,and their impact is generally confined to the modification of attributevalues. The possible attribute-oriented operations are retrieve (get) anattribute value, set an attribute value, replace an attribute value withthe default value and, for set-valued attributes, add and remove attributevalues.
The operations that are valid for a particular attribute in a managedobject are part of the package definition that references that attribute.Operations to retrieve attribute values map onto the CMIS M-GET service,while operations to set, replace with default, add and remove attributevalues use the CMIS M-SET service.
Object-oriented operations are applied to the object as a whole. Thepossible object-oriented operations are create, delete, and action. Thecreate and delete operations are used to create and delete specific instancesof a managed object class; however, managed objects also may be createdor deleted as side-effects of other normal resource operations. The createand delete operations use the CMIS M-CREATE and M-DELETE services, respectively.
An action is defined to elicit a specific response that is not obtainablethrough the use of the other operations. Action operations use the CMISM-ACTION service. An action defines an operation that may be directedto a managed object to perform a specific operation. An action definitionincludes its behavior (optional), whether it is always confirmed or not,the syntax of any information (if any) in the action request or response,and any specific errors.
A notification defines information that may be sent when a managedobject emits a notification as a result of an event. A notification definitionincludes its behavior (optional), the syntax of any information (if any)in the report or response, and any specific errors. Whether a notificationis confirmed or unconfirmed is implementation dependent but also may beconfigurable by a manager (i.e., Event Forwarding Discriminator objectclass provides a mechanism [ISO/IEC 10164-5]). Notifications use the CMISM-EVENT-REPORT service.
The syntax of the information in the request or response of actionsand notifications is defined using ASN.1 notation [CCITT X.208, ASN.1].It is possible to leave the syntax of these data fields as an open type,such that the syntax is specified using parameters when defining a managedobject class containing the action or notification.
...An operation performed on a managed object can succeed only if theinvoking managing system has the access rights necessary to perform thisoperation, and consistency constraints are not violated. ...Consistencyconstraints are specified as a part of the behavior definition of the attributeor managed object class definition. When performance of an operation, e.g.,replacing an attribute value, would violate a defined constraint, the operationis not performed and a "failure in processing" indication isreturned. [Part 1]
SQL3
Operations that may be invoked in SQL include defined operations ontables (SELECT, INSERT, UPDATE, DELETE), the implicitly defined functionsdefined for ADT attributes, and routines either explicitly associated withADTs or defined separately.
Routines associated with ADTs are FUNCTION definitions for type-specificuser-defined behavior. The FUNCTION definitions specify the operationson the ADT and return a single value of a defined data type. Functionsmay either be SQL functions, completely defined in an SQL schema definition,or external functions, defined in standard programming languages.
See also 2.4 specification of behavioral semantics, and 2.5methods.
Matisse
The Matisse metamodel (the class CLASS) has methods and messages asattributes. The interface to a class consists of methods (or functions)attached to the class and messages which are used to invoke the methods.
C++
Operations are defined by functions. In the context of the C++ objectmodel, functions may be globally defined (independently of object classes),or as part of class definitions (member functions). C++ essentially supportsa classical object model, in that member functions are associated withthe definition of a single object class. However, friend functionsmay be defined that, though not part of a class' definition, have accessto the internals of instances of that class. See entry under 5. Encapsulation.
Smalltalk
An operation is the action(s) taken by an object instance as resultof a message being received through the object's interface. Messages requestingoperations are addressed to specific recipient object instances, thus Smalltalkuses the "classical" object model and the method to execute inresponse to a message is determined by searching the object's class hierarchy.
Eiffel
Eiffel operations are based on the classical object model. Each operationhas a recipient, an operation (applicable to the recipient) and optionalarguments.
Cecil
Cecil supports a generalized object model, in which objects can be madeto behave like those in a classical object model if desired. See entryunder 2.5 methods.
SELF
Operations are defined for objects by including slots containing methodobjects, as described under 2. Objects. To invoke operations, messagesare sent to designated receiver objects; hence SELF supports a "classical"object model.
System Object Model (SOM)
The interface to a SOM object is defined by permitting the specificationof operation signatures which consist of an operation name and the argumentand result types. Operations are performed on methods which implement anobjects behavior.
OLE Component Object Model
Operations resemble standard C++ functions, and are defined as partof interface definitions. Operations are always invoked indirectly, throughinterfaces, as described in the entry under 2. Objects.
Analysis and Design Methods
SD: "An instance-based operationis one in which the caller of the operation supplies an instance of theunderlying data structure... The operation then manipulates that data structure.""Operations for which the caller does not supply a particular instanceof the underlying data structure are known as class-based. Class-basedoperations include queries, iterators, and create operations.
CA:
RA: "A function or transformationthat may be applied to or by objects in a class."
JA: "An instance of an actor doesa number of different operations to the system."
WD: The term is used and taken as understood.
MD: "Routines are the implementationsof the operations of the instances of a class."
EA: "An action may be composed ofone or more individual operations." "An action may cause events,create or destroy objects and relationships, observe objects and relationships,and send or receive messages."
FA: "An input event and the effectit can have are called a system operation. At any point in time, only onesystem operation can be active." System operations are invoked byagents in the environment of the system. "Note that all the operationsin an operation model operate on the same global state."
OA: "An operation is a process thatcan be requested as a unit." Operations carry out state changes. See9.6 Other: Control Condition.
BD: "An operation is some actionthat one object performs upon another in order to elicit a reaction."
HA: "Operations are services ofa class that lead to changes in the state of an object of that class. Operationsmay be viewed as commands on the object; that is, requests for the objectto do something. Operations should not return information about the outcomeof the operation; this should only be visible via the services termed properties."
NA: "The only visible part of anabstract data type is its operations ..." "... [T]he term ...feature ... cover[s] both the operational aspects and the state aspectsof class operations."
