1、INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Series Q Supplement 29 (1 2/1999) SERIES Q: SWITCHING AND SIGNALLING Service modelling: Evolution to the use of object oriented techniques ITU-T Q-series Recommendations - Supplement 29 (Formerly CCITT Recomm
2、endations) ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF SIGNALLING SYSTE
3、M R1 SPECIFICATIONS OF SIGNALLING SYSTEM R2 DIGITAL EXCHANGES INTERWORIUNG OF SIGNALLING SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 PUBLIC LAND MOBILE NETWORK INTERWORIUNG WITH SATELLITE MOBILE SYSTEMS INTELLIGENT NETWORK BROADBAND ISDN INTERNATIONAL
4、 AUTOMATIC AND SEMI-AUTOMATIC WORKING CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.lLQ.3 Q.4-Q.59 Q.60.99 Q. 100.119 Q. 120.249 Q.250.309 Q.310.399 Q.400.499 Q.500.599 Q.600.699 Q.700.849 Q.850.999 Q. 1000. 1099 Q. 1 100.1199 Q. 1200.1699 Q.1700.1
5、799 Q.2000.2999 For further details, please re$er to the list of ITD-T Recommendations. Supplement 29 to ITU-T Q-series Recommendations Service modelling: Evolution to the use of object oriented techniques Summary This Supplement compares different types of methodologies for service modelling to det
6、ermine their suitability in relation to protocol development for IN in the IN CS-4 time-frame. It also investigates the evolution from SIB based techniques and considers different technologies such as APIS. This Supplement supplements the information contained within Recommendation 4.65. Rational Th
7、e purpose of this Supplement is to provide a discussion of service modelling aspects related to IN cs-4. Source Supplement 29 to ITU-T Q-series Recommendations was prepared by ITU-T Study Group 11 (1997-2000) and approved under the WTSC Resolution 5 procedure on 3 December 1999. Q series - Supplemen
8、t 29 (12/1999) 1 FOREWORD The International Telecommunication Union (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 tari
9、ff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recom
10、mendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSC Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with IS0 and IEC. NOTE In this publica
11、tion, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this publication may involve the use of a cl
12、aimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the publication development process. As of the date of approval of this publication, ITU had not r
13、eceived notice of intellectual property, protected by patents, which may be required to implement this publication. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. o ITU 2001 All rights reserv
14、ed. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing fi-om the ITU. 11 Q series - Supplement 29 (12/1999) CONTENTS 1 1.1 2 2.1 2.2 3 3.1 3.2 4 4.1 4.2 4.3 5 5.1 5.2 6 6
15、.1 6.2 6.3 Scope of service modelling for IN CS-4 . References . Definitions and abbreviations . Abbreviations Definitions Requirements for IN CS-4 service modelling . Service modelling . Service Logic spanning a single class . 3.2.1 Service Logic spanning several classes . Methodologies and modelli
16、ng techniques Open Distributed Processing (ODP) . 4.1.2 Information Viewpoint 4.1.3 Computational Viewpoint 4.1.5 Technology Viewpoint Unified Modelling Language 4.3.1 Evaluation of UML Advantages of using Object Orientation for service modelling 4.1.1 Enterprise Viewpoint . 4.1.4 Engineering Viewpo
17、int Evaluation of ODP Exploring the Use of APIS in IN CS4 . 5.1.1 Background 5.1.2 A Framework for the use of APIS 5.1.3 API Overview 5.1.4 Example API for call processing . The SIB approach A possible Evolution from SIBs to Object Oriented Service Capabilities . Service Class model Service Executio
18、n View Migration of CS-2 SIBs to Object Classes and Methods Appendix I . Bibliography . Q series . Supplement 29 (12/1999) Page 1 1 2 2 2 2 3 4 6 7 7 8 8 8 9 9 9 10 11 11 12 13 13 14 14 15 16 16 17 18 20 . 111 Supplement 29 to ITU-T Q-series Recommendations Service modelling: Evolution to the use of
19、 object oriented techniques 1 The purpose of this Supplement is: Scope of service modelling for IN CS-4 o to identify and compare different methodologies for service modelling; to determine the suitability of the identified methodologies for service modelling, in o particular, with respect to: - ser
20、vice management: data modelling; - service logic purposes: dynamic service model (behaviour of service logic); - description of the relationship between the data model and the dynamic service model. to determine the suitability of the identified methodologies for protocol development, in particular,
21、 with respect to: - the support of stepwise refinement rom service and network capabilities to protocol level both for the data model and the dynamic service model; - the ability to incorporate the existing protocol into the model defined with the used methodology. - the evolution rom the SIB-based
22、service modelling methodology to the methodologies used for IN CS-4. o to investigate the migration aspects of service modelling, in particular, with respect to: o to decide on the scope of service modelling for IN CS-4; to decide on the methodology to be applied for service modelling in IN CS-4. o
23、1.1 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Supplement. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision;
24、 all users of this Supplement are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations and supplements is regularly published. - - ITU-T Recommendations Q.
25、 122x series, IN CS-2 Recommendations. ITU-T Recommendation Q. 1223 (1997), Global functional plane for intelligent network capability set 2. ITU-T Recommendation Z. 1 O0 (1 999), Specijkation and description language (SDL). - Q series - Supplement 29 (12/1999) 1 2 Definitions and abbreviations 2.1
26、Abbreviations This Supplement uses the following abbreviations: API Application Programming Interface GFP Global Functional Plane INCM IN Conceptual Model ODP Open Distributed Processing OMT Object Modelling Technique SDL Specification Description Language SQL Structured Query Language STD State Tra
27、nsition Diagrams TINA Telecommunication Information Networking Architecture 2.2 Definitions This Supplement defines the following terms: 2.2.1 API: an API is essentially a set of operations (or methods) that can be invoked on a component, each of which causes the component to exhibit behaviowal func
28、tionality. Each operation is specified syntactically as an identifier which identifies the operation being invoked, and parameters which affect the behaviow of the component in some way. 2.2.2 API Call: an API call is equivalent with the term “operation“ and is sometimes interchangeably used in the
29、description of an API (above). Effectively an API is made up of a number of individual API calls. 3 Requirements for IN CS-4 service modelling This clause looks at the requirements that are seen to be important for modelling techniques and methodologies used for IN service modelling, they are: o Ste
30、pwise refinement fi-om service (features) to protocol level should be supported. Support for various mechanisms of transparency. These include: o - Technolou transparency: the modelling of IN services should not be dependent on the technology used, e.g. the type of network, operation system or progr
31、amming language. An important type of transparency in the context of IN CS-4 service modelling is network technology transparency. The objective of IN CS-4 is the integration of a number of network technologies, including connection oriented type of networks (e.g. PSTN, IMT-2000) and connectionless
32、types of networks (e.g. IP-based networks, data networks). Some of the services targeted in IN CS-4 will probably be specific to one network technology, others will require intenvorking between different network technologies, or their behaviow will depend on the technology the service is invoked fi-
33、om. One could think of a service with user interaction, which can be invoked by B- ISDN as well as mobile network users, or of a multimedia conference service over different network technologies. IN could be an integrated architecture for the services on multiple network technologies. It should be i
34、nvestigated to what extent network technology transparency can be achieved. 2 Q series - Supplement 29 (12/1999) Access transparency: masking differences in data representation and invocation mechanisms (i.e. providing multiple mappings of the information contents of IN protocol exchanges to program
35、ming APIS). Failure transparency: masking, rom an object, the failure and possible recovery of objects (including itself). Migration transparency: masking, rom an object, the ability of a system to change the location of interfaces to that object. Relocation transparency: masking relocation of an ob
36、ject interface rom other interfaces bound to it. Replication transparency: masking use of a group of mutually behaviowally compatible objects to support an interface. Service extensibility: it should be possible to support additions to the IN service functionality by extending the existing service m
37、odels and existing service components. Service scalability: it should be possible to accommodate and allow to scale the service capabilities in terms of the number of users, the number of nodes, the number of administrative domains, etc. Service version handling: service-modelling techniques should
38、facilitate the concurrent use of multiple versions of service models and service components. Service reusability: it should be possible to reuse the models of an IN service (capability) during the specification of another IN service, rather than starting the modelling rom scratch even in case of ove
39、rlapping functionality. The same applies to the software components that implement the specification. Operation, administration and maintenance: the methodologies and modelling techniques should support flexibility when it comes to functionality and data model changes during operation, administratio
40、n and maintenance. For example, functionality changes that occur during maintenance should be easily reflected in the model of the IN service. Reduction of service conflict: the methodologies and modelling techniques should reduce the risks of service interactions. Flexible service modification/cust
41、omiation: the network providers and service providers should to be able to differentiate and customize services to meet specific market needs. The Users should be able to customize the services to some extent to meet their personal needs. In the short term it will be limited to data customization an
42、d selection rom a list of predefined featwes. In the longer term service packaging might be provided as well. Support for a multi-stakeholder environment: the IN CS-4 service capability modelling should be able to take into account the respective roles of the different stakeholders involved in the s
43、ervice provisioning (retailer, operator, content provider, etc.). 3.1 Service modelling One of the goals of O0 modelling is to allow the service developer and designers to share the same model of Service Logic. In order to achieve this goal the modelling technique should hide all platform details ro
44、m the user but at the same time allow the service developer to translate the behaviow model into the suitable execution form. In order to meet those requirements it is proposed that the behaviow modelling technique be represented in the notation which is programming language, operating system and da
45、tabase independent. The use of data-less SDLs and State Transition Diagrams is thus proposed to represent pure behaviow of an abstract class. Q series - Supplement 29 (12/1999) 3 3.2 The OMT and other modelling techniques introduce the concept of an Active Class. An Active Class is defined as a Clas
46、s whose behaviow is modelled best using the Finite State Machine Model (FSM). In order to achieve the language independence at the service logic level it is proposed that the model of Finite State Machine used contains no data. Thus an Abstract Class representing a simple service would contain an Ab
47、stract Data and an Abstract Behaviow Model strictly separated. It is important to stress here the fact that the separation of an Abstract Data and an Abstract Behaviow Model is suggested only at the Modelling Level. No recommendation is being made here nor is it suggested that the separation of an A
48、bstract Data and an Abstract Behaviow Model shall be extended to the automatically or manually generated code. An example of a separation of an Abstract Data and an Abstract Behaviow could be a VPN service with a complex service model. For instance the VPN service parameter Participant-ID may be an
49、example of abstract data at the modelling level. The Abstract Class Model in its Abstract Data Section should not reflect where in the behaviow model this data is used. On the other hand, the Abstract Behaviow Model of an Abstract Class may require an event New-Participant-Arrived without the need to mention where data for a given participant is stored in the Abstract Data Section of the Abstract Class. This separation within a top-level class should allow for inter-changeability of Service Model Objects and a creation of standard service needs. See Figure 1. The arrows in this model
