1、INCITS TR-22-1999Information Technology Object Information Management Object Model Technical ReportANSI NCITS TR-22-1999NCITS Technical ReportInformation Technology Object Information Management Object Model Technical ReportSecretariatInformation Technology Industry CouncilThis Technical Report is o
2、ne in a series produced by the National Committee forInformation Technology Standards (NCITS). The secretariat for NCITS is held bythe Information Technology Industry Council (ITI), 1250 Eye Street, NW, Suite 200,Washington, DC 20005.As a by-product of the standards development process and the resou
3、rces ofknowledge devoted to it, NCITS from time to time produces Technical Reports.Such Technical Reports are not standards, nor are they intended to be used assuch.NCITS Technical Reports are produced in some cases to disseminate thetechnical and logical concepts reflected in standards already publ
4、ished or underdevelopment. In other cases, they derive from studies in areas where it is foundpremature to develop a standard due to a still changing technology, orinappropriate to develop a rigorous standard due to the existence of a number ofviable options, the choice of which depends on the users
5、 particular requirements.These Technical Reports, thus, provide guidelines, the use of which can result ingreater consistency and coherence of information processing systems.When the draft Technical Report is completed, the Technical Committee approvalprocess is the same as for a draft standard. Pro
6、cessing by NCITS is also similar tothat for a draft standard.CAUTION: The developers of this Technical Report have requested that holdersof patents that may be required for the implementation of the Technical Report,disclose such patents to the publisher. However, neither the developers nor thepubli
7、sher have undertaken a patent search in order to identify which, if any, patentsmay apply to this Technical Report.As of the date of publication of this Technical Report and following calls for theidentification of patents that may be required for the implementation of theTechnical Report, no such c
8、laims have been made. No further patent search isconducted by the developer or the publisher in respect to any Technical Report itprocesses. No representation is made or implied that licenses are not required toavoid infringement in the use of this Technical Report.NCITSTechnicalReportSeriesPublishe
9、d byAmerican National Standards Institute11 West 42nd Street, New York, New York 10036Copyright 1999 by Information Technology Industry Council (ITI)All rights reservedNo part of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permi
10、ssion of the publisher.Printed in the United States of AmericaPATENTSTATEMENTiANSI NCITS TR/22:199xTable of ContentsPageExecutive Summary .iiiPreface. v1. Introduction . 11.1 Goals of NCITS H7 and Progress Against Those Goals. 11.2 Background . 21.3 Approach . 72. Object Model Features Matrix Overvi
11、ew . 93. Features Matrix Applications. 143.1 Object Query Language Harmonization and Analysis 143.2 OO COBOL Analysis and Input . 153.3 Other Related NCITS H7 Activities 153.4 Comments on Results 164. Recommendations and Future NCITS H7 Activities. 174.1 Future NCITS H7 Activities . 174.1.1 Object M
12、odel Harmonization 174.1.2 Common Vocabulary and Formal Semantics 184.1.3 Enterprise Modeling 194.1.4 International Activity 214.2 Creative Backlog . 215. References 23Glossary of Abbreviations. 25Appendix A: Object Model Features Matrix A1Appendix B: Object Query Service Analysis B1Appendix C: Exam
13、ple Features Matrix Internet Usage C1Appendix D: Object Interoperability Scenarios. D1iiExecutive SummaryNCITS Technical Committee H7 (then known as X3H7) was established in April 1992because of the proliferation of object technology concepts across standards committeesboundaries. Many technologists
14、 believe object technology now has the potential toprovide a significant beginning for interoperability across domain specific standardsbecause they are sharing many common attributes through object technology. Yet,numerous implementation divergence become barriers to the potential benefits of acomm
15、on interoperability object model. Some of these differences are arbitrary and couldbe easily remedied. Others are systemic to an application domain, but could be mappedto a common interoperability object model. H7s overall objective is to influenceharmonization in the usage of the object paradigm ac
16、ross standards regardless of whetherit ever creates standards itself.H7 Work Plan and AccomplishmentsH7s original program of work included a requirement to “. develop a technical report tofurther refine the definition of object information object management . and identifyseveral sub-areas where pote
17、ntial consensus for standards appear to be achievable andneeded. Recommendations . will be included in the technical report.“. This report isone of the results of that program of work. Additional benefits have been realized (someof which are discussed below) through H7s object technology standards h
18、armonizationefforts that resulted from interaction with other standards groups involved inimplementing object standards. This report, including its Appendices, had 14contributing authors representing 12 different organizations.From the time of its creation, H7 determined that its primary analysis to
19、ol would be astudy and a document comparing existing object models. The resulting documentbecame known as H7s Object Model Features Matrix and is included in the report asAppendix A. The Features Matrix is a 175 page study of 19 object models defined by 29parameters. One of the models represents gen
20、eric object-oriented analysis/designmethodology, but expands to differentiate 19 separate methods. Several hundred papercopies of the Features Matrix have been distributed to date, several hundred electroniccopies have been distributed through Internet FTP, and a hypertext version is accessiblethrou
21、gh the World Wide Web. The Features Matrix is becoming widely respected andhas already been cited in a number of papers and publications.The Object Model Features Matrix document has already been put to good use severaltimes in H7 object technology harmonization efforts. The following are highlights
22、 of keyuses.H7 was an operative third party in promoting object model harmonization betweenH2s SQL3 and the Object Database Management Group specification (ODMG-93).H7 representatives developed a paper that compared the object models of OMGsCORBA IDL language, the ODMG-93 specification, and the H2 e
23、merging SQL3standard. This work prompted continuing meetings between ODMG and H2 withgoals that benefit both.iiiIn January 1994, J4 requested H7 to comment on its draft Object-Oriented (OO)COBOL proposal. A H7 volunteer developed the Features Matrix entry for OOCOBOL from J4s proposal document, eval
24、uated the OO COBOL object model, andmade change recommendations. Subsequently, a revised OO COBOL proposal wassubmitted containing most of H7s recommended changes.H7 responded to a request from T3 for object-model-related input on the RM-ODPPart 2 (X.902:1) document prior to a vote in SC21/WG7. H7 a
25、nalyzed the documentand developed recommendations to T3 that included a comprehensive list identifying70 items of inconsistencies and problems. T3 considered this input valuable and ithas contributed to improvements in the RM-ODP Part 2 document.H7 developed a response to JTC1/SC21 on a Japan Data M
26、odel Facility proposal fora new conceptual schema object model. Based on its work, H7 recommendedconsidering the RM-ODP (WG7) and OSI Managed Objects and GeneralRelationship Model (WG4) rather than developing a new one.Future H7 ActivitiesThere are many more meritorious issues than resources to atta
27、ck them. Additionally,tasks undertaken must match individual members belief that the results of specific workwill have value for their sponsoring organization. H7 appears to have volunteer resourceswilling to perform meaningful work in the following areas.H7 will continue its object model harmonizat
28、ion activities, targeted at specific pairsor groups of object models. That may include adding more object models to theFeatures Matrix as people with the required expertise volunteer input.To understand object models and make in-depth comparisons, the concepts of thesemodels must be precisely define
29、d. Some work has been performed toward a commonvocabulary, but more is necessary. Additionally, H7 will cooperate with committeesinvestigating formal semantics of object-oriented concepts (e.g., J21) in order toleverage from their work.Interest is increasing in applying object technology to enterpri
30、se modeling. T3proposed a new work item, to develop an Enterprise Viewpoint Component Standardfor the Reference Model for Open Distributed Processing (RM-ODP), to ISO/IECJTC 1/SC 21 WG 7, with H7 serving as the major development group for thisstandard, working in cooperation with the Object Manageme
31、nt Groups BusinessObject Domain Task Force (BODTF). Joint meetings of H7 and BODTF havealready been held. In addition, H7 helped sponsor workshops on Enterprise Modelingat the ACM OOPSLA 95 and 96 Conferences. H7 members are also independentlyinvolved in developing and conducting additional workshop
32、s in conjunction withmajor OO conferences to identify, compare, and contrast theoretical and applied OOenterprise modeling approaches.ivH7 did not have a corresponding ISO project for its previous object modelharmonization activities, but proposes to become the TAG for the RM-ODPEnterprise Viewpoint
33、 Component Standard activity described above.vPrefaceThis is a technical report produced by the ANSI NCITS H7 Object InformationManagement Technical Committee. The H7 Technical Committee, operating under theprocedures of the American National Standards Institute (ANSI), was established in April1992.
34、The project proposal to the X3 Operational Management Committee (OMC) (nowNCITS) described a program of work for H7 as follows:Based upon the recommendations of the Object-Oriented Database TaskGroup (OODBTG), develop a technical report to further refine the objectinformation management reference mo
35、del.Work actively with other organizations to acquire consensus andharmonize in potential areas for object standardization.The overall goal of H7 is a coherent approach to information management standardsfostering consistent use of the object paradigm in various “business and technologydomains“ (pro
36、gramming languages, database, user interfaces, operating systems,distributed systems, object analysis and design, enterprise modeling and informationmodeling, .)This technical report represents the work of many individuals who attended quarterly H7meetings. The technical work represents the careful
37、distillation of direct contributions bythe members of H7. The opinions and ideas expressed here are not necessarily endorsedby all members nor by the members sponsoring organizations.William Kent, Hewlett Packard Laboratories, served as chair of H7 with GlennHollowell, Sematech, serving as vice-chai
38、r, from April 1992 until April 1994 whenWilliam Kent resigned. Glenn Hollowell served from April 1994 to January 1997.Joaquin Miller has served as chair since that time.Frank Manola, Object Services and Consulting, Inc., is the editor of this report. Thefollowing individuals have contributed written
39、 technical material or submitted entries tothe Object Model Features Matrix:Don Belisle IBMSteve Clark N.I.S.T.Richard Due Thomsen Due and Associates, Ltd.Elizabeth Fong N.I.S.T.Glenn Hollowell Texas InstrumentsWilliam Kent Hewlett Packard LaboratoriesHaim Kilov IBM T. J. Watson Research CenterFrank
40、 Manola Object Services and Consulting, Inc.Joaquin Miller SHL SystemhouseGail Mitchell GTE LaboratoriesLaura Redmann BellcoreviEdward Stull Summa International Inc.Jeff Sutherland IDX Systems CorporationCraig Thompson Object Services and Consulting, Inc.The following members of H7 have attended at
41、least one H7 meeting (affiliations listedare not necessarily current):Claude Baudoin Schlumberger ATEStig Berild Swedish Technical Attache OfficeGrady Booch RationalRoger Burkhart Deere thecode associated with the objects handles the details of dealing with the heterogeneousdata formats involved. OO
42、DBMSs illustrate interoperability in that they support sharedcollections of heterogeneous object types (albeit in the same object model) that provide ameans for different applications to interact and (possibly indirectly) communicate.In these types of systems, interoperability requires that it must
43、be possible for one object1to invoke operations provided by other objects, even when they are written in otherlanguages or exist on distributed network nodes. This has led to the development offrameworks or architectures governing the creation of such systems, such as theapplication integration arch
44、itectures mentioned above, the Reference Model for OpenDistributed Processing (RM-ODP) ODP2, and the ODMG-93 specifications for objectDBMSs Cat94. Moreover, a typical approach used in such architectures is to provide acommon object model to provide a shared set of precisely-defined abstractionsunder
45、stood and supported by all components2. General acceptance (or standardization) ofthe object model and interfaces of such an architecture would facilitate independentdevelopment of interoperable objects and supporting software in an applicationintegration architecture (which is, e.g., the goal of th
46、e OMG in specifying and promotingsuch an architecture). For example, use of a common object model means that thedeveloper of a new object in the architecture must only support interfaces defined interms of a single set of abstractions (those of the common model), no matter whatimplementation languag
47、e is used for that object. Use of a common object model alsomeans that an object may access other objects in the architecture via interfaces defined interms of that same set of abstractions, no matter what other languages may have beenused to define those objects.As a result of this situation, in ad
48、dition to the different object models that have beendeveloped for specific languages or to serve specific application areas, object modelshave been developed explicitly to serve as the common object model in applicationintegration architectures. An example is the OMG Core Object Model described in1T
49、he object may be a complete application, which is implemented as an object to allow its reuse.2The term object model, as used throughout this report, refers to the collection of concepts used to describeobjects in a particular object-oriented language, specification, or analysis and design methodology, andcorresponds closely to the use of the term data model in the phrase “the relational data model“. Thus, wespeak of “the Smalltalk object model“ or “the OMG object model“. This is in contrast to use of objectmodel to describe the collection of objects created to m
