1、 ETSI EG 202 106 V2.1.1 (2003-11)ETSI Guide Methods for Testing and Specification (MTS);Guidelines for the use of formal SDL as a descriptive toolETSI ETSI EG 202 106 V2.1.1 (2003-11) 2 Reference REG/MTS-00072 Keywords ASN.1, methodology, MSC, SDL, testing, UML ETSI 650 Route des Lucioles F-06921 So
2、phia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: http:/www.etsi.org
3、The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI
4、printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http:/portal.etsi.o
5、rg/tb/status/status.asp If you find errors in the present document, send your comment to: editoretsi.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunic
6、ations Standards Institute 2003. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI regist
7、ered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI EG 202 106 V2.1.1 (2003-11) 3 Contents Intellectual Property Rights6 Foreword.6 1 Scope 7 2 References 7 3 Definitions and abbreviations.8 3.1 Definitions8 3.2 Abbreviations .8 4 Introduction 9 5 Using specificati
8、on languages in protocol standards10 5.1 Introduction 10 5.2 Layered protocols.10 5.3 Developing a protocol specification.10 5.3.1 Specifying requirements .11 5.3.2 Developing a logical model 11 5.3.3 Developing a physical model11 6 Naming conventions.13 6.1 General .13 6.1.1 Case sensitivity .15 6.
9、1.2 Length of names .15 6.1.3 Reserved words.15 6.2 SDL and MSC 16 6.2.1 Use of non-significant characters16 6.2.2 Multiple use of names.16 6.2.3 Making names meaningful17 6.2.3.1 Block, process and instance names .17 6.2.3.2 Procedure, operator and method names 17 6.2.3.3 Signal names .18 6.2.3.4 S
10、ignal list and interface names18 6.2.3.5 SDL state names18 6.2.3.6 Names of variables and constants .19 6.2.3.7 Timers .19 6.3 Data types.19 7 Presentation and layout of diagrams 19 7.1 The general flow of behaviour across a page .20 7.2 Behaviour covering more than one page 21 7.2.1 SDL behaviour d
11、iagrams 21 7.2.2 Definitions in behaviour diagrams25 7.2.3 UML activity diagrams.26 7.3 Text extension symbols 27 7.4 Alignment and orientation of symbols .27 7.4.1 Alignment .27 7.4.2 Orientation 29 7.5 Structuring behaviour descriptions.29 7.5.1 Basic structuring principles 29 7.5.2 Structuring us
12、ing procedures and operations 30 7.5.3 Emphasizing the difference between normal and exceptional behaviour flows .30 8 Using procedures, operations and macros31 8.1 Procedures 31 8.1.1 Using procedures to replace informal tasks 33 8.1.2 Procedure signature (parameters and returned values) .34 8.1.3
13、Procedure body .36 ETSI ETSI EG 202 106 V2.1.1 (2003-11) 4 8.1.4 Avoiding side-effects39 8.1.5 Naming of procedures.40 8.2 Operations 41 8.3 Using macros45 9 Using decisions 46 9.1 Decisions 47 9.1.1 Naming of identifiers used with decisions47 9.1.2 Using decisions to structure a specification47 9.1
14、.3 Use of text strings in decisions .47 9.1.4 Use of enumerated types in decisions.48 9.1.4.1 Use of ELSE49 9.1.5 Using SYNTYPES to limit the range of values in decisions 49 9.1.6 Use of symbolic names in decision outcomes.49 9.1.7 Use of range expressions in decisions 50 9.1.8 Use of Procedures in
15、Decisions 51 9.1.9 Use of ANY in decisions 53 9.2 Use of options rather than decisions.53 9.3 Flow control statements54 10 System structure, communication and addressing56 10.1 System structure .56 10.2 Minimising the SDL model57 10.3 Avoiding repetition by using SDL types 58 10.3.1 Defining the sam
16、e behaviour at both ends of a protocol.59 10.3.2 Static instances to represent repeated functionality 59 10.4 Interfaces 60 10.5 Diagrams showing relationships.61 10.5.1 Use of associations between class symbols 62 10.5.1.1 Use of a class symbol for an INTERFACE definition 63 10.6 Structure diagrams
17、 using interfaces between agents 63 10.7 Communication and Addressing 64 10.7.1 Use of interface and SIGNALLIST definitions 64 10.7.2 Indicating the use of signals in inputs and outputs .65 10.7.3 Directing messages to the right process65 10.7.4 Differentiating messages.66 10.7.5 Multiple outputs66
18、10.7.6 Transitions triggered by a set of signals67 10.8 Gates and implicit channels67 10.9 Other structuring mechanisms68 10.9.1 Processes within a process68 10.9.2 Shared data68 10.9.3 Hiding and re-using parts of a state 68 10.9.4 Using packages .70 10.9.5 Exception handling .70 11 Specification a
19、nd use of data71 11.1 Specifying messages.71 11.1.1 Structuring messages 72 11.1.2 Ordering message parameters .73 11.1.3 Transposing other message formats74 11.2 Specifying data that is internal to the SDL model74 11.2.1 Use of symbolic names .74 11.2.1.1 Using data TYPE and SYNTYPE.75 11.2.1.1.1 U
20、sing OBJECT TYPE.76 12 Using Message Sequence Charts (MSC)76 12.1 Introduction 76 12.2 Relationship between MSC and SDL.76 12.3 Presentation and layout 77 12.3.1 Annotations.77 12.4 Naming and scope 78 12.5 MSC document.78 ETSI ETSI EG 202 106 V2.1.1 (2003-11) 5 12.6 Structuring79 12.6.1 Architectur
21、e 79 12.6.1.1 Instance .79 12.6.1.2 Instance decomposition.80 12.6.1.3 Dynamic instances 80 12.6.1.4 Environment80 12.6.2 Behaviour81 12.6.2.1 High-level MSC (HMSC) .82 12.6.2.2 MSC reference in basic MSC84 12.6.2.3 Inline expression .85 12.7 Data 86 12.8 Message87 12.8.1 Incomplete messages 89 12.9
22、 Condition89 12.10 Action.90 12.11 Timer 91 12.12 Control Flow 92 12.13 Time .93 12.14 General ordering and coregion .94 12.15 Relationship between MSC and UML Sequence Diagrams.95 Annex A (informative): Reserved words 96 A.1 SDL 96 A.1.1 Keywords .96 A.1.2 Predefined words97 A.2 MSC .97 A.3 ASN.1.9
23、8 A.4 UML.98 Annex B (informative): Summary of guidelines 99 Annex C (informative): Bibliography.103 History 104 ETSI ETSI EG 202 106 V2.1.1 (2003-11) 6 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertai
24、ning to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretar
25、iat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or th
26、e updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This ETSI Guide (EG) has been produced by ETSI Technical Committee Methods for Testing and Specification (MTS). ETSI ETSI EG 202 106 V2.1.1 (2003-11) 7 1 Scope The present document esta
27、blishes a set of guidelines for the formal use of Specification and Description Language (SDL) for descriptive, rather than detailed design, purposes. It also provides some guidance on the use of Message Sequence Charts (MSC), Abstract Syntax Notation 1 (ASN.1) and the Unified Modeling Language (UML
28、) when used in conjunction with SDL. The objective of the guidelines is to provide assistance to rapporteurs of protocol standards so that the SDL that appears in ETSI deliverables is formally expressed, easy to read and understand and at a level of detail consistent with other standards. The presen
29、t document applies to all standards that make use of SDL to specify protocols, services or any other type of behaviour. Users of the present document are assumed to have a working knowledge of SDL and, where necessary, MSC, ASN.1 and UML. It should not be considered to be a tutorial in any of these
30、notations and should be read in conjunction with EG 201 383 1, EG 201 015 2 and EG 201 872 3. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publicatio
31、n and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox
32、.etsi.org/Reference. 1 ETSI EG 201 383 (V1.1.1): “Methods for Testing and Specification (MTS); Use of SDL in ETSI deliverables; Guidelines for facilitating validation and the development of conformance tests“. 2 ETSI EG 201 015 (V1.2.1): “Methods for Testing and Specification (MTS); Specification of
33、 protocols and services; Validation methodology for standards using Specification and Description Language (SDL); Handbook“. 3 ETSI EG 201 872 (V1.2.1): “Methods for Testing and Specification (MTS); Methodological approach to the use of object-orientation in the standards making process“. 4 ITU-T Re
34、commendation Z.100: “Specification and Description Language (SDL)“. 5 ITU-T Recommendation Z.105: “SDL combined with ASN.1 modules (SDL/ASN.1)“. 6 Void. 7 ITU-T Recommendation Z.120 Corrigendum 1: “Messages sequence chart (MSC)“. 8 ITU-T Recommendation X.680: “Information technology - Abstract Synta
35、x Notation One (ASN.1): Specification of basic notation“. 9 ITU-T Recommendation X.681: “Information technology - Abstract Syntax Notation One (ASN.1): Information object specification“. 10 ITU-T Recommendation X.682: “Information technology - Abstract Syntax Notation One (ASN.1): Constraint specifi
36、cation“. 11 ITU-T Recommendation X.683: “Information technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications“. ETSI ETSI EG 202 106 V2.1.1 (2003-11) 8 12 ITU-T Recommendation X.690: “Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Ru
37、les (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)“. 13 ITU-T Recommendation X.691: “Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)“. 14 ITU-T Recommendation X.692: “Information technology - ASN.1 encoding rules - Specificat
38、ion of Encoding Control Notation (ECN)“. 15 ITU-T Recommendation I.130: “Method for the characterization of telecommunication services supported by an ISDN and network capabilities of an ISDN“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following te
39、rms and definitions apply: data type: set of data values with common characteristics NOTE: Equivalent to the ITU-T Recommendation Z.100 4 term sort. implementation option: statement in a standard that may or may not be supported in an implementation normative interface: physical or software interfac
40、e of a product on which requirements are imposed by a standard polymorphic: the ability of an operation (SDL method or operator) to have its behaviour specified by a descendant object type validation: process, with associated methods, procedures and tools, by which an evaluation is made that a stand
41、ard can be fully implemented, conforms to rules for standards, satisfies the purpose expressed in the record of requirements on which the standard is based and that an implementation that conforms to the standard has the functionality expressed in the record of requirements on which the standard is
42、based validation model: detailed version of a specification, possibly including parts of its environment, that is used to perform formal validation 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ASN.1 Abstract Syntax Notation No. 1 BER Basic Encoding R
43、ules ECN Encoding Control Notation HMSC High-level Message Sequence Chart MSC Message Sequence Chart PER Packed Encoding Rules Pid Process identity SAP Service Access Point SDL Specification and Description Language UML Unified Modeling Language ETSI ETSI EG 202 106 V2.1.1 (2003-11) 9 4 Introduction
44、 The ITU-T Specification and Description Language (SDL) defined in ITU-T Recommendation Z.100 4 is a powerful tool for specifying the essential requirements of standardized protocols or services. The level of formality with which the SDL in a standard is expressed can depend on a large number of fac
45、tors such as the size and complexity of the system to be standardized and the skills and experience of the standards writers. The specification of a protocol or service as a complete formal model enables the validation of the standard before approval and publication. However, well-constructed, forma
46、l SDL has a valuable role to play in providing a simple illustration of the process-related aspects of a standardized system. SDL is most often found in protocol standards with some associated ASN.1 and MSC. Additionally, as the language specifications converge, SDL is also likely to be used in conj
47、unction with UML in standards. It is, therefore, sensible to consider the relationships between all of these languages and notations when offering guidelines on SDL. The present document is concerned primarily with the development of easy-to-read SDL but also provides some guidance on the use of ASN
48、.1, MSC and UML where this overlaps with the use of SDL. NOTE: Although in the strictest sense SDL, MSC and UML are considered to be languages while ASN.1 is a notation, the terms “language“ and “notation“ are used interchangeably throughout the present document. In order to gain the maximum benefit
49、 from the use of descriptive SDL, it is necessary for a consistent approach to be taken in its specification by all rapporteurs. In the context of the present document, the term “descriptive SDL“ can be taken to mean SDL which is: formally expressed: - uses only constructs and symbols that are defined in ITU-T Recommendations Z.100 4 and Z.105 5; complete: - is specified as a full model with system, block, process and procedure diagrams as necessary; - has a comprehensive data specification using SDL data or, preferably, ASN
copyright@ 2008-2019 麦多课文库（www.mydoc123.com）网站版权所有
备案/许可证编号：苏ICP备17064731号-1