ITU-T Z 130 AMD 1-2006 Extended Object Definition Language (eODL) Techniques for distributed software component development – Conceptual foundation notations and technology mappingpin.pdf

《ITU-T Z 130 AMD 1-2006 Extended Object Definition Language (eODL) Techniques for distributed software component development – Conceptual foundation notations and technology mappingpin.pdf》由会员分享，可在线阅读，更多相关《ITU-T Z 130 AMD 1-2006 Extended Object Definition Language (eODL) Techniques for distributed software component development – Conceptual foundation notations and technology mappingpin.pdf（18页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T Z.130TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 1(06/2006) SERIES Z: LANGUAGES AND GENERAL SOFTWARE ASPECTS FOR TELECOMMUNICATION SYSTEMS Formal description techniques (FDT) Extended Object Definition Language (eODL) Extended Object Definit

2、ion Language (eODL): Techniques for distributed software component development Conceptual foundation, notations and technology mappings Amendment 1: New Annex E eODL to CIDL mapping ITU-T Recommendation Z.130 (2003) Amendment 1 ITU-T Z-SERIES RECOMMENDATIONS LANGUAGES AND GENERAL SOFTWARE ASPECTS FO

3、R TELECOMMUNICATION SYSTEMS FORMAL DESCRIPTION TECHNIQUES (FDT) Specification and Description Language (SDL) Z.100Z.109 Application of formal description techniques Z.110Z.119 Message Sequence Chart (MSC) Z.120Z.129 Extended Object Definition Language (eODL) Z.130Z.139 Testing and Test Control Notat

4、ion (TTCN) Z.140Z.149 User Requirements Notation (URN) Z.150Z.159 PROGRAMMING LANGUAGES CHILL: The ITU-T high level language Z.200Z.209 MAN-MACHINE LANGUAGE General principles Z.300Z.309 Basic syntax and dialogue procedures Z.310Z.319 Extended MML for visual display terminals Z.320Z.329 Specificatio

5、n of the man-machine interface Z.330Z.349 Data-oriented human-machine interfaces Z.350Z.359 Human-machine interfaces for the management of telecommunications networks Z.360Z.379 QUALITY Quality of telecommunication software Z.400Z.409 Quality aspects of protocol-related Recommendations Z.450Z.459 ME

6、THODS Methods for validation and testing Z.500Z.519 MIDDLEWARE Distributed processing environment Z.600Z.609 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. Z.130 (2003)/Amd.1 (06/2006) i ITU-T Recommendation Z.130 Extended Object Definition Language (eODL): Techni

7、ques for distributed software component development Conceptual foundation, notations and technology mappings Amendment 1 New Annex E eODL to CIDL mapping Summary This amendment provides an example mapping of ITU eODL for technology independent component specifications into a technology dependent one

8、, which in this case is the CIDL (OMG Component Implementation Definition Language as part of CORBA 3.0). This amendment transforms (by means of different mappings) the concept of components from design and implementation (where modules are well known) to binary software. The composition of componen

9、ts takes place during execution time. Source Amendment 1 to ITU-T Recommendation Z.130 (2003) was approved on 13 June 2006 by ITU-T Study Group 17 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. Z.130 (2003)/Amd.1 (06/2006) FOREWORD The International Telecommunication Union (

10、ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to stand

11、ardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is co

12、vered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to ind

13、icate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieve

14、d when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PR

15、OPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asse

16、rted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned

17、that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. ITU 2006 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. Z.130 (2003)/Amd.1 (06

18、/2006) iii CONTENTS Page 1) Replace the following part in the items of Summary: 1 2) Update the Contents as follows: . 1 3) Insert before Appendix I: 1 ITU-T Rec. Z.130 (2003)/Amd.1 (06/2006) 1 ITU-T Recommendation Z.130 Extended Object Definition Language (eODL): Techniques for distributed software

19、 component development Conceptual foundation, notations and technology mappings Amendment 1 New Annex E eODL to CIDL mapping 1) Replace the following part in the items of Summary Annex D contains a software reference to the XML representation 12 of the eODL metamodel according to the XML meta interc

20、hange format (XMI) 6. It is provided in a separate file in order to allow import and processing of the eODL metamodel by UML tools. Clause 1 provides an overview of how eODL is used by designers, implementers and managers of a distributed system. A concrete example of the use is given in Appendix I.

21、 with: Annex D contains a software reference to the XML representation 12 of the eODL metamodel according to the XML meta interchange format (XMI) 6. It is provided in a separate file in order to allow import and processing of the eODL metamodel by UML tools. Annex E contains mapping rules from tech

22、nology independent eODL to technology specific CIDL 7. Appendix I provides an overview of how eODL is used by designers, implementers and managers of a distributed system. A concrete example of the use is given in Appendix I. 2) Update the Contents as follows Add the following entries to the Content

23、s paragraph before Appendix I. Modify the page number according to the new document. 3) Insert before Appendix I Annex E eODL to CIDL mapping E.1 Introduction The component based software development is an approach for modular and model-based software development. Supported by different mappings, it

24、 transforms component models (seen from different views like design and implementation) to the binary software components. The composition of software components takes place during execution time. 2 ITU-T Rec. Z.130 (2003)/Amd.1 (06/2006) eODL is a language which offers concepts for a technology ind

25、ependent model description of the components in their life cycle from different viewpoints. Concepts like computational object, component, interface, module, signal, and data type are essential for the computational and implementation viewpoint. In addition, there are further concepts for the descri

26、ption of runtime environments and deployment of software components. The CCM (CORBA Component Model 7) is an OMG standard for a platform dependent framework. It provides a metamodel for the description of technology dependent CORBA components and the technology and runtime environment for components

27、 developed using that metamodel. CCM is based on mature CORBA technologies like the GIOP protocol and language bindings for implementation languages. The component model of CCM defines two kinds of component interactions. There is a RPC-like interaction with request/response and a signal-like one wi

28、th events. For each of these interaction kinds components can declare the usage or the provision. For the notation of component implementation CCM uses the language CIDL. To bridge the gap between technology-independent software component models given as eODL specifications technology-dependent mode

29、ls given as CIDL models, mappings are needed as a base for automated model transformations. The OMG Component Implementation Definition Language (CIDL) is a language used to describe the structure and state of CORBA component implementations. Component-enable compilers generate implementation skelet

30、ons from CIDL definitions. Component builders extend these skeletons to create complete implementations. This annex defines the rules for an eODL to CIDL mapping. These rules are verified by a compiler implementation. E.2 Restricted mapping from eODL to CIDL The definition of eODL is widely based on

31、 concepts defined by CORBA IDL 2.x 5. Also the metamodel of eODL forms an extension of the CORBA metamodel. The adopted concepts are assigned to the computational viewpoint of eODL. Unfortunately the metamodel of CCM does not support the eODL concepts of the deployment viewpoint and the target envir

32、onment viewpoint. This field is not defined by the MOF metamodel of CCM yet. There are only XML document types defined that are necessary for the final realization of the deployment architecture. Conclusion: The eODL concepts concerning the deployment viewpoint and the target environment viewpoint a

33、re not mapped. The mapping rules should be extended as far as an according OMG standardization process will be finalized. E.3 Mapping of eODL concepts which are CORBA concepts on CCM Like the eODL metamodel, the CCM metamodel also extends the CORBA 2.x concepts. Therefore, for eODL concepts which de

34、rive from CORBA, the simplest mapping is chosen, the identical mapping. This allows the assignment of basic concepts from the eODL computational viewpoint like data types, interfaces, operations and attributes from the platform independent level to the platform specific level in a way which is the s

35、implest one for the developer. By using the CORBA metamodel as source as well as destination for the mapping, the occurrence of overlapping by defining the transformation rules is possible. Because of the identical mapping, this only happens when concepts of the CORBA metamodel are used in a context

36、 which is not derived from the CORBA metamodel. ITU-T Rec. Z.130 (2003)/Amd.1 (06/2006) 3 E.4 Mapping of the computational viewpoint concepts E.4.1 Signal Signals are information carrier in eODL. They are transported during a signal-based interaction from the sender to the receiver. Rule 1: For each

37、 SignalDef in eODL an EventDef in CCM with the same name is created. The associated names and data types in a CarryField in eODL are mapped onto ValueMemberDef elements in CCM, which are contained within the EventDef. All created ValueMemberDef have public visibility (isPublicMember=true). Example:

38、signal Sig long l; ; Is mapped to CIDL, eventtype Sig public long l; ; E.4.2 Consume and Produce The interaction elements consume and produce of eODL are supposed to define the signal-based interaction within an interface. Even though signal-based interaction exists in CCM (EventDef), it is not allo

39、wed to be part of an interface. CCM defines such an interaction only as a direct part of a component definition. Again this is not allowed in eODL: only attributes are permitted. A complete prohibition of consume and produce in the eODL model would prevent a signal-based interaction. Therefore a rep

40、lacement construction is defined, which does increase the complexity of the mapping but at least allows signal-based interaction. In CCM the definition of a signal (EventDef) forms a definition of an interface for signal exchange. When defining component ports, they are handled as own ports. So for

41、each signal-based interaction element of eODL, a separate port is defined at the component. Rule 2: Elements of type ConsumeDef and ProduceDef in eODL are not mapped themselves but are handled by the rules for ports. Example: signal Sig; interface A consumes Sig c; produces Sig p; ; Is mapped to CID

42、L, where the signal-based interaction elements from the EnhancedInterfaceDef are removed. Only signals are reflected in CCM as EventDef. eventtype Sig ; interface A ; 4 ITU-T Rec. Z.130 (2003)/Amd.1 (06/2006) E.4.3 Media, sink and source Operational and signal-based interactions are supported by CCM

43、. A Stream-based interaction is not reflected. There are efforts to extend CCM by those concepts but these are not part of the standard. Therefore, the mapping will not transform the model elements of these concepts from eODL to CCM. E.4.4 CO-type, supports and requires Both eODL and CCM are extensi

44、ons of CORBA concepts and introduce the concept of a component. In eODL this concept is called CO-type, whereas CCM calls it component. So a CO-type is mapped onto a component. Interactions of the CO-type are only allowed via ports because this interaction variant also exists in CCM. Rule 3: For eac

45、h COTypeDef in eODL a ComponentDef in CCM with the same name is created. If the COTypeDef B specializes COTypeDef A in eODL, then the corresponding ComponentDef B specializes ComponentDef A in CCM. The relations supports and requires are not mapped. Multiple inheritance of COTypeDef in eODL is not p

46、ermitted. Example: CO A ; CO B ; The CO-types of eODL are mapped onto components in CCM while the inheritance relation is preserved. component A ; component B : A ; E.4.5 Home (HomeDef) In CCM a further concept exists that is related closely to CCM component. The concept home is used for managing th

47、e components during runtime. A home provides a facility for creating instances of the components. That is why a component definition without a home is incomplete. So the mapping creates for each CO-type also a home in CCM. Rule 4: For each COTypeDef in eODL, a HomeDef in CCM is created constructing

48、its name by concatenating the name of the COTypeDef and “_Home“. The resulting ComponentDef and HomeDef take part in the Component_Home association. If a COTypeDef B specializes COTypeDef A in eODL then the corresponding HomeDef B specializes HomeDef A in CCM. Example: CO A ; CO B : A ; The mapping

49、creates for each CO-type a component type in CCM as well as a home. component A ; home A_Home manages A ; component B : A ; ITU-T Rec. Z.130 (2003)/Amd.1 (06/2006) 5 home B_Home : A_Home manages B ; E.4.6 Provide and used port The concepts ProvidePortDef and UsedPortDef in eODL are used to define the interface between the CO-type and the environment. In CCM the corresponding concept is port (ComponentFeature), which occurs in different specializations. There is a port for the realization and