Object Model Features Matrix

Doc. No.: X3H7-93-007v12b Doc. Date: May 25, 1997 Reply to: Frank Manola (Editor) Object Services and Consulting, Inc. 151 Tremont Street #22R Boston, MA 02111 USA (617) 426-9287 [email protected] National Committee for Information Technology Standards Technical Committee H7 Object Model Features Matrix Disclaimers: This Features Matrix is primarily intended for H7 use in analyzing object model interoperability issues. The Features Matrix is not intended to be an exhaustive description of all important object models. Rather, it is intended to be a representative sample of the design space of object models illustrating key (but not necessarily all) variations in important object model characteristics. Thus, inclusion of an object model in the matrix is 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 object model's "lack of importance". Although the committee has attempted to be accurate in its descriptions of the various models, these descriptions have not necessarily been verified or endorsed by those responsible for the development of those models. In addition, the descriptions of individual models have not necessarily been updated to track changes which may have been made in those models since the entries were compiled (although in some cases they have). The descriptions are intended to be consistent with the references cited for them. 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” 1 miscellaneous editorial corrections I. Introduction The H7 Object Model Features Matrix is organized by rows denoting various object models (or object-oriented languages/systems), and columns denoting specified object model features. The intent is to describe each object model (language/system) with respect to the specified features (an entry is intended to be text describing the model's support for the feature, not "yes" or "no"). The presentation of the matrix is in column order; that is, each column is defined, and the entries for each row for that column follow. This is to facilitate comparing models according to a given feature. 1.1 What is an Object Model? The term object model, as used throughout this document, refers to the collection of concepts used to describe objects in a particular object-oriented language, specification, or analysis and design methodology, and corresponds closely to the use of the term data model in “the relational data model”. Thus, we speak of “the Smalltalk object model” or “the OMG object model”. This is in contrast to the use of object model to describe the collection of objects created to model a particular system or application, as in “the Automated Teller Machine object model” or “the object model of a windowing system” [RBPE+91]. From our point of view, [RBPE+91] defines a particular object model (our sense), which includes concepts like object, inheritance, attribute, and so on, and uses it to define the object models (second sense) of various applications. This dual usage is unfortunate, but is common in the literature. I.1 Rows (Object Models) The "rows" of the matrix are given below. For each row, the name of the submitter is given. 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 Ed Stull, updated by Haim Kilov (ISO/IEC JTC1/SC21/WG7) Management Information Model Laura Redmann (ISO/IEC JTC1/SC21/WG4) SQL3 (X3H2) Frank Manola and Jeff Sutherland 2 Matisse Jeff Sutherland C++ (X3J16) Frank Manola OO COBOL (X3J4) Frank Manola Smalltalk (X3J20) 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 various object analysis and design methods (hence this row itself contains entries for multiple models). The descriptions of these models are based on the descriptions of the methods as published in books. It is important to realize that the object model described here is not necessarily the object model of the author(s); it is the result of an attempt to capture the object model described in the book. The book may have been misinterpreted; the book 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 books separately cover analysis and design. Sometimes different sections of one book are devoted to analysis and to design. In any case, it is informative to note the elements of the object model used in analysis, and new or different elements used in design. Accordingly, the matrix entries sometimes distinguish the analysis model from the design model. In the cases of some authors, subsequent books in some sense replace an earlier book or books. In these cases, the model described is that of the book or books mentioned in 14. Background and References. When an author elaborates a concept of the model under the heading of construction, this is sometimes also indicated. Where possible, the definitions of terms used by the author(s) have been quoted. The matter in “double quotes” is quoted directly from the books. Terms under discussion are enclosed in ‘single quotes’ when the term is mentioned, as opposed to a referent of the term. Matter in [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 3 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.2 Columns (Features) The "columns" (features) currently used in the features matrix are given below. 0. Intended Use 1. Basic Concepts 2. Objects 2.1 operations 2.2 requests 2.3 messages 2.4 specification of behavioral semantics 2.5 methods (including multimethods and method combinations) 2.6 state 2.7 object lifetime 2.8 behavior/state grouping 2.9 communication model 2.10 events 2.11 transition rules 3. Binding 4. Polymorphism 5. Encapsulation e.g., how are object boundaries defined?; how many object boundaries or interfaces are there (do subclasses or "friends" get special access to objects)? what are their characteristics? 6. Identity, Equality, Copy e.g., what things have identity: objects, or interfaces? 7. Types and Classes 8. Inheritance and Delegation 4 9. Noteworthy Objects 9.1 relationships 9.2 attributes 9.3 literals 9.4 containment 9.5 aggregates 9.6 other 10. Extensibility 10.1 Dynamic ability to add new methods, classes, change attributes, change types; can you 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/class objects) at run time) 11. Object Languages 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 most features, the OODBTG Reference Model matrix entry serves to define (or at least describe) the feature, and in some cases related features. This is because the features themselves were largely taken from the OODBTG final report. I.3 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 each row (object model) corresponding to that column follow. In the matrix itself, features (column headings) are written in boldface. Object models (or their sources) are underlined. Numbers appearing in plain text are paragraph or other numbers from source documents. Editor's Notes are written in italics. Citations refer to sources associated with the particular object model under discussion (see the entry for that object model under 13. Background and References), and are not necessarily unique within the entire Features Matrix. 5 0. Intended Use II. Features Matrix Entries 0. Intended Use The intended use of an object model describes such things as the application(s) of the object model, the context(s) or part(s) of the development lifecycle in which the object model is intended to be used, the level of abstraction of the objects defined using the model, and the purpose of object-orientation in the intended application. One reason for describing intended use is to explain the presence or absence of specific object model features in terms of application requirements. ODMG The ODMG Object Model is intended to allow portability of applications among object database products. It provides a common model for these products by defining extensions to the OMG object model that support object database requirements. In particular, the ODMG model extends the OMG core to provide for persistent objects, object properties, more specific object types, queries and transactions.

Load more