Doc. No.: X3H7-93-007v12b
Doc. Date: May 25, 1997
Disclaimers:
This Features Matrix is primarily intended for H7 use in analyzing objectmodel interoperability issues. The Features Matrix is not intended to bean exhaustive description of all important object models. Rather, it isintended to be a representative sample of the design space of object modelsillustrating key (but not necessarily all) variations in important objectmodel characteristics. Thus, inclusion of an object model in the matrixis not necessarily an indication of the object model's "importance";it may simply incorporate a specific design choice of interest to H7. Similarly,exclusion of an object model is not necessarily an indication of an objectmodel's "lack of importance". Although the committee has attemptedto be accurate in its descriptions of the various models, these descriptionshave not necessarily been verified or endorsed by those responsible forthe development of those models.
In addition, the descriptions of individual models have not necessarilybeen updated to track changes which may have been made in those modelssince the entries were compiled (although in some cases they have). Thedescriptions are intended to be consistent with the references cited forthem.
Changes since last version:
The following are the changes made since version 10 was approved.
version 11:
deletion of information on projected entries
miscellaneous editorial corrections
versions 12, 12a, and 12b:
revised version of Analysis and Design Methods entry
revised version of SQL3 entry
added definition of "object model"
miscellaneous editorial corrections
I. Introduction
The H7 Object Model Features Matrix is organized by rows denoting variousobject models (or object-oriented languages/systems), and columns denotingspecified object model features. The intent is to describe each objectmodel (language/system) with respect to the specified features (an entryis intended to be text describing the model's support for the feature,not "yes" or "no"). In the text version, the presentationof the matrix is in column order; that is, each column is defined, andthe entries for each row for that column follow. This is to facilitatecomparing models according to a given feature. In this Web version, eachrow and column has a separate page.
I.1 What is an Object Model?
The term object model, as used throughout this document, refersto the collection of concepts used to describe objects in a particularobject-oriented language, specification, or analysis and design methodology,and corresponds closely to the use of the term data model in "therelational data model". Thus, we speak of "the Smalltalk objectmodel" or "the OMG object model". This is in contrast tothe use of object model to describe the collection of objects createdto model a particular system or application, as in "the AutomaticTeller Machine object model" or "the object model of a windowingsystem" [RBPE+91]. From our point of view, [RBPE+91] defines a particularobject model (our sense), which includes concepts like object, inheritance,attribute, and so on, and uses it to define the object models (secondsense) of various applications. This dual usage is unfortunate, but iscommon in the literature.
I.2 Rows (Object Models)
The "rows" of the matrix are given below. For each row, thename of the submitter is given.
(Note: an object model description does not necessarily contain an entryfor every feature.)
| Object Model | Submitter |
| OODBTG Reference Model | Craig Thompson |
| OMG Core Object Model | Bill Kent, updated by Frank Manola |
| OMG CORBA IDL | Don Belisle |
| ODMG | Gail Mitchell |
| EXPRESS | Steve Clark and Elizabeth Fong |
| Open Distributed Processing (ISO/IEC JTC1/SC21/WG7) | Ed Stull, updated by Haim Kilov |
| Management Information Model (ISO/IEC JTC1/SC21/WG4) | Laura Redmann |
| SQL3 (H2) | Frank Manola and Jeff Sutherland |
| Matisse | Jeff Sutherland |
| C++ (J16) | Frank Manola |
| OO COBOL (J4) | Frank Manola |
| Smalltalk (J20) | Glenn Hollowell |
| Eiffel | NICE (Eiffel Consortium) |
| Emerald | Frank Manola |
| Cecil | Frank Manola |
| SELF | Frank Manola |
| System Object Model (SOM) | Don Belisle |
| OLE Component Object Model | Frank Manola |
| Analysis and Design Methods | Joaquin Miller |
The final row includes information on the object models used in variousobject analysis and design methods (hence this row itself contains entriesfor multiple models). The descriptions of these models are based on thedescriptions of the methods as published in books. It is important to realizethat the object model described here is not necessarily the object modelof the author(s); it is the result of an attempt to capture the objectmodel described in the book. The book may have been misinterpreted; thebook may have used only a part of the author(s) complete object model;that model may have changed since the publication of the book.
Some authors have published more than one book. Sometimes these booksseparately cover analysis and design. Sometimes different sections of onebook are devoted to analysis and to design. In any case, it is informativeto note the elements of the object model used in analysis, and new or differentelements used in design. Accordingly, the matrix entries sometimes distinguishthe analysis model from the design model. In the cases of some authors,subsequent books in some sense replace an earlier book or books. In thesecases, the model described is that of the book or books mentioned in 14.Background and References. When an author elaborates a concept of themodel under the heading of construction, this is sometimes also indicated.
Where possible, the definitions of terms used by the author(s) havebeen quoted. The matter in "double quotes" is quoted directlyfrom the books. Terms under discussion are enclosed in 'single quotes'when the term is mentioned, as opposed to a referent of the term. Matterin [square brackets] was inserted by the row submitter.
The analysis and design models included, and their identifications,are:
D: Booch Design
CA: Coad et al. Analysis
CD: Coad et al. Design
EA: Embly et al. Analysis
FA: Coleman et al Analysis
FD: Coleman et al Design
FC: Coleman et al Construction
HA: Henderson-Sellers et al. Analysis and Design
JA: Jacobson et al. Analysis
JD: Jacobson et al. Design
MD: Meyer Design
MC: Meyer Construction
NA: Waldén et al. Analysis and Design
OA: Odell et al. Analysis
RA: Rumbaugh et al. Analysis
RD: Rumbaugh et al. Design
SA: Shlaer et al. Analysis
SD: Shlaer et al. Design
WD: Wirfs-Brock et al. Design
I.3 Columns (Features)
The "columns" (features) currently used in the features matrixare given below.
(Note: a feature description does not necessarily contain an entry forevery object model.)
2.4 specification of behavioral semantics
2.5 methods (including multimethods andmethod combinations)
5. Encapsulation
e.g., how are object boundaries defined?; how many object boundaries orinterfaces are there (do subclasses or "friends" get specialaccess to objects)? what are their characteristics?
6. Identity, Equality, Copy
e.g., what things have identity: objects, or interfaces?
10.1 Dynamic
ability to add new methods, classes, change attributes, change types; canyou freeze (prevent extensions)?
10.2 Metaclasses/Metaobject Protocol
how extensible is the class system? can new semantics be added?
10.3 Introspection
definitional aspects of instances; access to definitions (e.g., type/classobjects) at run time)
12. Semantics of Base Classes (+ type constructors)
13. Background and References
Sources of matrix entries, and other relevant material.
The initial features list was developed at the July 1992 X3H7 meeting,and the features list has been amended several times since then. For mostfeatures, the OODBTG Reference Model matrix entry serves to define (orat least describe) the feature, and in some cases related features. Thisis because the features themselves were largely taken from the OODBTG finalreport.
I.4 Layout
As noted above, the presentation of the matrix is in column (feature)order; that is, each column (feature) is defined, and the entries for eachrow (object model) corresponding to that column follow. In the matrix itself,features (column headings) are written in boldface. Object models (or theirsources) are underlined. Numbers appearing in plain text are paragraphor other numbers from source documents. Editor's Notes are written in italics.Citations refer to sources associated with the particular object modelunder discussion (see the entry for that object model under 13. Backgroundand References), and are not necessarily unique within the entire FeaturesMatrix.
Comments to:
Frank Manola (Editor)
Object Services and Consulting, Inc.
151 Tremont Street #22R
Boston, MA 02111 USA
(617) 426-9287
fmanola@objs.com
