features matrixintro pageAs 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.
OMG CORBA IDL
CORBA uses the classical object model in that a target object must bespecified for each operation.
ODMG
ODMG specifies a classical object model: each operation has a distinguishedargument. See also 9.1 Relationships.
Open Distributed Processing
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."
Management Information Model
The management model in MIM [Part 1] is classical due to constraintsof the underlying CMIS services. However, the GRM model [GRM 93] is generalized.
SQL3
SQL3 routines may be defined within ADT definitions, or independentlyof them. SQL3 supports a generalized object model in terms of dispatching(see also 4. Polymorphism). However, there is no concept of a genericfunction which groups routines with a common signature. A routine definedwithin an ADT has access to that ADT's PRIVATE members.
See also 2. Objects.
C++
C++ implements a classical object model. In C++, members, includingmember functions, of objects are regarded as belonging to individual objectsand their classes, and are accessed via the objects they belong to.
OOCOBOL
OO COBOL implements a classical object model.
Smalltalk
Smalltalk uses the "classical" object model.
Eiffel
Eiffel supports the classical model of objects.
Cecil
Cecil implements a generalized object model. In Cecil, objects and methodsconceptually form a graph structure, with the object/method relationshipsbeing established by method specializers. See entry under 2.5 methods.
SELF
SELF supports a "classical" object model.
System Object Model (SOM)
SOM uses the classical object model in that a target object must bespecified for each operation.
OLE Component Object Model
The Component Object Model implements a classical object model.
Analysis and Design Methods
SA: An event is always directed to aspecific instance. Behavior depends on the instance and its state: in eachstate, an instance will respond to only to specified events; other eventsdirected to the instance are ignored and lost to the system. The behaviorin response to an event is determined by the state to which the instancemoves as a result of the event. Uses the 'classical' object model.
CA: Behavior is specific to a class."An Object State is the identification of Attribute value(s) whichreflects a change in Object behavior. The current state may be tested ina service chart and behavior modified as a result of the test." Usesthe 'classical' object model.
RA: [The contributor does not understandRumbaugh et al. here.] Uses the 'classical' object model.
JA: See 2.6 state. Uses the 'classical'object model.
WD: Responsibilities are assigned toa particular class; uses the 'classical' object model.
MD: "...[B]y introducing a stateand operations on this state, we make the abstract data type specificationricher as it has more functions and more properties. ... In the end theview of objects as state machines reflects abstract data types which aremore operational, but this in no way makes them any less abstract."Uses the 'classical' object model.
EA: Actions may be associated with bothstates and transitions. Uses the 'classical' object model.
FA: "A life-cycle expression definesthe allowable sequences of operations that a system may participate inover its lifetime. In at any point the system receives an event that isnot allowed according to the life cycle, then the system ignores it andleaves the state of the system unchanged." Uses the 'classical' objectmodel.
OA: 'Classical' and 'generalized' objectmodels are considered to be an implementation issue. "During analysis,however, we do not make such implementation-related choices. As such, weshould index those operations having multiple input variables with multipleobject types." "This is sometimes referred to as multiple polymorphism."
BD: "... [W]e may say that all methodsare operations, but not all operations are methods: some operations maybe expressed as free subprograms. In practice, we are inclined to declaremost operations as methods, although ... there are sometimes compellingreasons to do otherwise, such as when a particular operation affects twoor more objects of different classes, and there is no particular benefitin declaring that operation in one class over another." Uses both'classical' and 'generalized' object models.
HA: Uses the 'classical' object model.
NA: Does not use state machines in analysis.Uses the 'classical' object model.features matrixintro page