ANSI INCITS 273-1997 Information Technology - CASE Tool Integration Messages.pdf

《ANSI INCITS 273-1997 Information Technology - CASE Tool Integration Messages.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS 273-1997 Information Technology - CASE Tool Integration Messages.pdf（362页珍藏版）》请在麦多课文档分享上搜索。

1、ANSI INCITS 273-1997 (R2002)(formerly ANSI X3.273-1997)for Information Technology CASE Tool Integration MessagesANSIX3.273-1997American National Standardfor Information Technology CASE Tool Integration MessagesSecretariatInformation Technology Industry Council (ITI)Approved January 21, 1997American

2、National Standards Institute, Inc.AmericanNationalStandardApproval of an American National Standard requires review by ANSI that therequirements for due process, consensus, and other criteria for approval havebeen met by the standards developer.Consensus is established when, in the judgment of the A

3、NSI Board of StandardsReview, substantial agreement has been reached by directly and materiallyaffected interests. Substantial agreement means much more than a simplemajority, but not necessarily unanimity. Consensus requires that all views andobjections be considered, and that a concerted effort be

4、 made toward theirresolution.The use of American National Standards is completely voluntary; their existencedoes not in any respect preclude anyone, whether he has approved the standardsor not, from manufacturing, marketing, purchasing, or using products, processes,or procedures not conforming to th

5、e standards.The American National Standards Institute does not develop standards and will inno circumstances give an interpretation of any American National Standard.Moreover, no person shall have the right or authority to issue an interpretation ofan American National Standard in the name of the Am

6、erican National StandardsInstitute. Requests for interpretations should be addressed to the secretariat orsponsor whose name appears on the title page of this standard.CAUTION NOTICE: This American National Standard may be revised orwithdrawn at any time. The procedures of the American National Stan

7、dardsInstitute require that action be taken periodically to reaffirm, revise, or withdrawthis standard. Purchasers of American National Standards may receive currentinformation on all standards by calling or writing the American National StandardsInstitute.CAUTION: The developers of this standard ha

8、ve requested that holders of patents that may be required for theimplementation of the standard disclose such patents to the publisher. However, neither the developers nor the publisherhave undertaken a patent search in order to identify which, if any, patents may apply to this standard. As of the d

9、ate ofpublication of this standard and following calls for the identification of patents that may be required for the implementationof the standard, no such claims have been made. No further patent search is conducted by the developer or publisher inrespect to any standard it processes. No represent

10、ation is made or implied that licenses are not required to avoidinfringement in the use of this standard.Published byAmerican National Standards Institute11 West 42nd Street, New York, New York 10036Copyright 1997 by Information Technology Industry Council (ITI)All rights reserved.No part of this pu

11、blication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permission of ITI, 1250 Eye Street NW,Washington, DC 20005.Printed in the United States of AmericaiForewordii1 Scope and purpose 12 Introduction 23 Goals .24 Overview25 The abstract messaging

12、 environment56 The abstract messaging model .87 Extensibility148 Application conformance.14Table1 Contents of error parameter tuples11Figures1 The model for requests.42 The model for notifications4AnnexesA Servicegram index15B Build servicegrams .18C Common servicegrams .38D Debug servicegrams.51E E

13、dit servicegrams .164F Software analysis and design servicegrams 207G Static code analysis servicegrams 256H Version management servicegrams.272I Window servicegrams.325J Glossary.340ContentsPageiiForeword (This foreword is not part of American National Standard X3.273-1997.)This standard was prepar

14、ed by the subcommittee on CASE ToolIntegration Models, X3H6.This standard has ten annexes, including the glossary. Annexes B throughI are normative and are considered part of the standard; Annexes A and Jare informative and are not considered part of the standard.Requests for interpretation, suggest

15、ions for improvement or addenda, ordefect reports are welcome. They should be sent to the X3 Secretariat,Information Technology Industry Council, 1250 Eye Street, NW, Suite 200,Washington, DC 20005-3922.This standard was processed and approved for submittal to ANSI by theAccredited Standards Committ

16、ee on Information Technology, X3.Committee approval of the standard does not necessarily imply that allcommittee members voted for its approval. At the time it approved thisstandard, the X3 Committee had the following members:James D. Converse, ChairKaren Higginbottom, Vice-ChairKate McMillan, Secre

17、taryOrganization Represented Name of RepresentativeAMP, Inc. Ben BennettEdward Kelly (Alt.)Apple Computer, IncDavid K. MichaelJerry Kellenbenz (Alt.)AT Message semantics; Message sequencing (constraints on message ordering); Messages for Computer Aided Software Engineering domain.The standard does n

18、ot address: Definition of tool data (data integration); How the tool data are displayed (presentation integration); Language bindings of application program interface (interface syntax); How the message gets from one place to another (message communication protocoldefinition).It is recognized that t

19、he messages and their parameters reflect some notion of the tool data.1.2 PurposeBuilding an integrated engineering environment requires a standard set of messages for which theinterface and semantics are established and understood. Tool vendors want their product to beeasily integrated into a varie

20、ty of custom environments.The needs of tool integration are: The tool should be able to maintain the same structure when integrating with differentenvironments; Integration should be easy; a minimal level of effort should result in some meaningfulintegration within an environment.Services which meet

21、 these needs should be: High level: exporting only the concepts necessary for tool integration; Technology independent: hiding the underlying mechanisms; Environment independent: tools need not make algorithmic changes to integrate with differentenvironments.The messages described in this standard a

22、ccommodate both object-oriented and non-object-oriented tools. This may require a mapping from type class and method name for environmentsbased on OO messaging systems to message name and parameters for non-OO messagingsystems. This mapping should be simple and not require the tool to support any fo

23、rm ofpolymorphism. It would be desirable for tools sending OO style messages to operate within the sameenvironment with tools sending non-OO style messages, and to intermix their messages.ANSI X3.273-199722 IntroductionThe problem of cooperation among software applications has received a great deal

24、of attention overthe last several years. This standard proposes an architecture that can be used as a basis forinteraction among applications and is a unification of the CASE Communiqu and the CASEInteroperability Alliance architectures. Though we currently apply this architecture to the CASEdomain,

25、 it can potentially be applied to other domains as well. In this architecture considerable effortwas devoted to minimize the changes required to applications yet provide a useful level ofintegration. It is intended that this architecture (and the abstract messages based on it) beimplementable on man

26、y different messaging technologies. An attempt was made to accommodatea broad range of existing technologies, including broadcast, multicast, and OMG CORBA compliantarchitectures.There are several different forms of software integration. This standard focuses on controlintegration. Other forms of in

27、tegration are described in the subclause titled “4.1 A model forapplication integration“ (see 4.1).An abstract model for control integration is developed that is implementation independent. Thismodel has been kept as general as possible so that it can be supported by a wide variety ofmechanisms.The

28、architecture specified in this standard lays the foundation for specifying operations and theirsemantics for cooperating applications in an environment.3 GoalsThis architecture standard was written to facilitate the development of abstract messages for controlintegration. These abstract messages def

29、ine the semantics of application interaction. In order todefine the abstract messages, assumptions need to be made about the system in which thesemessages will be sent. This standard will articulate these assumptions.This standard places requirements on a messaging system which is capable of sending

30、 themessages that will be defined by the message developers. This architecture is defined to beindependent of any particular implementation of a messaging system. It should be possible to layerthis architecture on top of any broadcast or multicast message based system or any CORBAimplementation.This

31、 architecture and the associated messages can be used to support both single user systemsand large distributed multi-user systems.4 Overview4.1 A model for application integrationThere are at least four dimensions of integration: Presentation or user interface integration; Data integration; Control

32、integration; and Process integration.Each kind of integration has a number of properties that specify the degree of integration. Thus, thedegree of integration between application A and application B is always specified with respect to userinterface, or with respect to data, and so on.ANSI X3.273-19

33、973Presentation integration is concerned with the relationship between the appearance and behavior oftwo applications. Two applications are well integrated with respect to user presentation if theirappearance is similar and their behavior is consistent.Data integration is concerned with sharing data

34、 between two applications. Two applications are wellintegrated with respect to data if the data produced by one application may be easily used by theother.Control integration is concerned with the relationship of actions between two applications. Twoapplications are well integrated with respect to c

35、ontrol if one application provides some of itsfunctions as services to the other application.Process integration is concerned with the relationship of the functions between two applications. Twoapplications are well integrated with respect to process if the function of one application directlypreced

36、es or follows the function of the other in a defined (software development) process.An important aspect of this model is that these different kinds of integration are somewhatindependent of each other. For example, two applications may be well integrated with respect touser interface (they are both

37、Motif compliant) while still not integrated with respect to data (they donot share data). The Emacs and vi editors exchange data quite easily; they are well integrated withrespect to data. But their appearance and behavior are very different. They are not integrated withrespect to user interface.Thi

38、s partitioning of application integration has several practical advantages. Conceptually, it certainlyimproves the tractability of the problem of application integration. It allows (without requiring) differentmechanisms to support each type of integration. It allows progress to be made in each of t

39、he fourkinds of integration at its own rate.This standard is concerned only with control integration. The other three types of integration areinteresting, important, and difficult problems in their own right, but they require separate treatments.The X user interface and Motif standard have been a si

40、gnificant advance in user interfaceintegration. The ANSI X3H4 standard committee is actively working on the data models necessaryfor data integration. Process integration is currently an area of active research in the academiccommunity.4.2 A model for control integrationFigures 1 and 2 present an ab

41、stract model for control integration. In this model applications issuerequests for actions and notifications of events.Requests (figure 1) are issued by one application to cause some action by another application. Theapplication sending the request is the requester and the application that services

42、the request is theservicer. To send a request, the requester specifies an operation with some parameters and shallreceive a reply from the servicer after the operation completes. For example, a debugger mayrequest that an editor move its cursor to a line of source code that contains an error.Notific

43、ations (figure 2) are sent by an application to inform other applications in the system that anevent of importance has occurred. Applications listen for notifications in order to track the state of thesystem and may take further action based on a notification. An example of an action based on anotif

44、ication is a file viewer reloading its buffer based on a notification that the file it is displaying hasbeen modified.ANSI X3.273-19974ApplicationControl Integration MechanismRequest(requestor) (servicer)Application Application ApplicationReplyFigure 1 The model for requestsApplicationControl Integr

45、ation MechanismNotificationApplication Application ApplicationFigure 2 The model for notificationsRequest and notification messages shall be defined in a way that allows applications to easily usethem. Such a message definition may be separated into two parts: meaning (semantics) and form(syntax). T

46、his separation is useful because syntax is often implementation dependent, whilesemantics may be defined to span implementations. This abstract control integration model is thebasis for agreement on the semantics of application interfaces for control integration.Both requests and notifications refer

47、ence actions. These actions usually operate on some data. In asystem of cooperating applications there shall be some common way of identifying the dataassociated with an action. For an application to interpret a request or notification, it shall be able tointerpret to some level the data references.

48、Note that a common way of referring to data does not imply that applications share data or that theyall store data in a single “repository.“ Data integration is a separate task; it is not part of this work.The only requirement is that when applications communicate, they reference the common data at

49、alevel they both can interpret. This standard describes a collection of abstract mechanisms forreferencing the data passed in requests and notifications. Like the abstract message definitions, thedata definitions focus on meaning and not form.ANSI X3.273-199755 The abstract messaging environmentThe architecture defined in this standard assumes a suitable messaging environment or capability.This environment or capability shall accept and deliver messages between applications and shall beable to track the status of message delivery.This clause describes the fund