InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / ascii / 10_1_06.txt < prev next >

Wrap

Text File | 1991-12-22 | 51.4 KB | 2,641 lines

5i' ANNEX C2 (to Recommendation Z.100) SDL PR syntax summary 1 system Figure T1003240-88, (N), p. 2 definition Figure T1003250-88, (N), p. 3 diagram Diagram is defined in GR syntax summary. 4 system definition | (Basic SDL 2.4.1) Figure T1003260-88, (N), p. 5 block definition | (Basic SDL 2.4.2) Figure T1003270-88, (N), p. 6 textual block reference | (Basic SDL 2.4.2) Figure T1003280-88, (N), p. 7 process definition | (Basic SDL 2.4.3) Figure T1003290-88, (N), p. 8 textual process reference | (Basic SDL 2.4.3) Figure T1003300-88, (N), p. 9 valid input signal set Figure T1003310-88, (N), p. 10 process body | (Basic SDL 2.4.3) Figure T1003320-88, (N), p. 11 simple expression Figure T1003330-88, (N), p. 12 procedure definition | (Basic SDL 2.3.4) Figure T1003340-88, (N), p. 13 textual procedure reference | (Basic SDL 2.3.4) Figure T1003350-88, (N), p. 14 channel definition | (Basic SDL 2.5.1) Figure T1003360-88, (N), p. 15 signal route definition | (Basic SDL 2.5.2) Figure T1003370-88, (N), p. 16 signal definition | (Basic SDL 2.5.4) Figure T1003380-88, (N), p. 17 signal list definition | (Basic SDL 2.5.5) Figure T1003390-88, (N), p. 18 variable definition | (Basic SDL 2.6.1.1) Figure T1003400-88, (N), p. 19 view definition | (Basic SDL 2.6.1.2) Figure T1003410-88, (N), p. 20 view expression | (Data 5.5.4.4) Figure T1003420-88, (N), p. 21 start | (Basic SDL 2.6.2) Figure T1003430-88, (N), p. 22 state | (Basic SDL 2.6.3) Figure T1003440-88, (N), p. 23 input | (Basic SDL 2.6.4) Figure T1003450-88, (N), p. 24 save | (Basic SDL 2.6.5) FigureT1003460-88, (N), p. 25 transition | (Basic SDL 2.6.7) Figure T1003470-88, (N), p. 26 nextstate | (Basic SDL 2.6.7.2.1) Figure T1003480-88, (N), p. 27 join | (Basic SDL 2.6.7.2.2) Figure T1003490-88, (N), p. 28 stop | (Basic SDL 2.6.7.2.3) Figure T1003500-88, (N), p. 29 return | (Basic SDL 2.6.7.2.4) Figure T1003510-88, (N), p. 30 task | (Basic SDL 2.7.1) Figure T1003520-88, (N), p. 31 create request | (Basic SDL 2.7.2) Figure T1003530-88 , (N), p. 32 procedure call | (Basic SDL 2.7.3) Figure T1003540-88, (N), p. 33 output | (Basic SDL 2.7.4) Figure T1003550-88, (N), p. 34 decision | (Basic SDL 2.7.5) Figure T1003560-88, (N), p. 35 answer | (Basic SDL 2.7.5) Figure T1003570-88, (N), p. 36 timer definition | (Basic SDL 2.8) Figure T1003580-88, (N), p. 37 reset | (Basic SDL 2.8) Figure T1003590-88, (N), p. 38 set | (Basic SDL 2.8) Figure T1003600-88, (N), p. 39 timer active expression | (Data 5.5.4.5) Figure T1003610-88, (N), p. 40 end Figure T1003620-88, (N), p. 41 signal list Figure T1003630-88, (N), p. 42 sort list Figure T1003640-88, (N), p. 43 data definition Figure T1003650-88, (N), p. 44 informal text Figure T1003660-88, (N), p. 45 actual parameters Figure T1003670-88, (N), p. 46 block substructure definition | (Structural concepts 3.2.2) Figure T1003680-88, (N), p. 47 block substructure reference | (Structural concepts 3.2.2) Figure T1003690-88, (N), p. 48 channel connection | (Structural concepts 3.2.2) Figure T1003700-88, (N), p. 49 channel to route connection | (Structural concepts 3.2.2) Figure T1003710-88, (N), p. 50 channel substructure definition | (Structural concepts 3.2.3) Figure T1003720-88, (N), p. 51 channel substructure body | (Structural concepts 3.2.3) Figure T1003730-88, (N), p. 52 channel substructure reference | (Basic SDL 2.5.1) Figure T1003740-88, (N), p. 53 channel endpoint connection | (Structural concepts 3.2.3) Figure T1003750-88, (N), p. 54 signal refinement | (Structural concepts 3.3) Figure T1003760-88, (N), p. 55 macro definition | (Additional concepts 4.2.2) Figure T1003770-88, (N), p. 56 macro call | (Additional concepts 4.2.3) Figure T1003780-88, (N), p. 57 external synonym definition | (Additional concepts 4.3.1) Figure T1003790-88, (N), p. 58 select definition | (Additional concepts 4.3.3) Figure T1003800-88, (N), p. 59 transition option | (Additional concepts 4.3.4) Figure T1003810-88, (N), p. 60 service decomposition | (Additional concepts 4.10.1) Figure T1003820-88, (N), p. 61 service definition | (Additional concepts 4.10.2) Figure T1003830-88, (N), p. 62 service reference | (Additional concepts 4.10.1) Figure T1003840-88, (N), p. 63 signal route connection | (Additional concepts 4.10.1) Figure T1003850-88, (N), p. 64 service signal definition | (Additional concepts 4.10.1) Figure T1003860-88, (N), p. 65 priority input | (Additional concepts 4.10.2) Figure T1003870-88, (N), p. 66 priority output | (Additional concepts 4.10.2) Figure T1003880-88, (N), p. 67 continuous signal | (Additional concepts 4.11) Figure T1003890-88, (N), p. 68 enabling condition | (Additional concepts 4.12) Figure T1003900-88, (N), p. 69 import definition | (Additional concepts 4.13) Figure T1003910-88, (N), p. 70 import expression | (Additional concepts 4.13) Figure T1003920-88, (N), p. 71 export | (Additional concepts 4.13) Figure T1003930-88, (N), p. 72 sort | (Data 5.2.2) Figure T1003940-88, (N), p. 73 partial type definition | (Data 5.2.1) Figure T1003950-88, (N), p. 74 properties expression | (Data 5.2.1 and 5.5.3.3) Figure T1003960-88, (N), p. 75 operators | (Data 5.2.2 and 5.4.1.8) Figure T1003970-88, (N), p. 76 literal list | (Data 5.2.2) Figure T1003980-88, (N), p. 77 literal signature | (Data 5.2.2 & 5.4.1.8) Figure T1003990-88, (N), p. 78 character string literal identifier Figure T1004000-88, (N), p. 79 operator signature | (Data 5.2.2) Figure T1004010-88, (N), p. 80 axioms | (Data 5.2.3 and 5.2.4) Figure T1004020-88, (N), p. 81 equation Figure T1004030-88, (N), p. 82 term Figure T1004040-88, (N), p. 83 ground term Figure T1004050-88, (N), p. Figure T1004060-88, (N), p. Figure T1004070-88, (N), p. Figure T1004080-88, (N), p. Figure T1004090-88, (N), p. Figure T1004100-88, (N), p. Figure T1004110-88, (N), p. Figure T1004120-88, (N), p. Figure T1004130-88, (N), p. 84 extended operator identifier Figure T1004140-88, (N), p. 85 infix operator Figure T1004150-88, (N), p. 86 monadic operator Figure T1004160-88, (N), p. 87 quoted operator FigureT1004170-88, (N), p. 88 extended operator name | (Data 5.4.1) Figure T1004180-88, (N), p. 89 extended sort | (Data 5.4.1.9) Figure T1004190-88, (N), p. 90 extended properties | (Data 5.4.1) Figure T1004200-88, (N), p. 91 syntype definition | (Data 5.4.1.9) Figure T1004210-88, (N), p. 92 range conditions | (Data 5.4.1.9.1) Figure T1004220-88, (N), p. 93 constant | (Data 5.4.1.9) Figure T1004230-88, (N), p. 94 structure definition | (Data 5.4.1.10) Figure T1004240-88, (N), p. 95 inheritance rule | (Data 5.4.1.11) Figure T1004250-88, (N), p. 96 literal renaming | (Data 5.4.1.11) Figure T1004260-88, (N), p. 97 generator definition | (Data 5.4.1.12.1) Figure T1004270-88, (N), p. 98 generator formal name | (Data 5.4.1.12.1) Figure T1004280-88, (N), p. 99 generator sort | (Data 5.4.1.12.1) Figure T1004290-88, (N), p. 100 generator instantiations | (Data 5.4.1.12.2) Figure T1004300-88, (N), p. 101 generator instantiation (Data 5.4.1.12.2) Figure T1004310-88, (N), p. 102 operator name Figure T1004320-88, (N), p. 103 synonym definition | (Data 5.4.1.13) Figure T1004330-88, (N), p. 104 name class literal | (Data 5.4.1.14) Figure T1004340-88, (N), p. 105 regular expression | (Data 5.4.1.14) Figure T1004350-88, (N), p. 106 ground expression | (Data 5.4.2.1) Figure T1004360-88, (N), p. 107 active expression | (Data 5.4.2.2) Figure T1004370-88, (N), p. 108 ground primary | (Data 5.4.2.2) Figure T1004380-88, (N), p. 109 field selection Figure T1004390-88, (N), p. 110 operator identifier Figure T1004400-88, (N), p. 111 expression | (Data 5.5.2.1) Figure T1004410-88, (N), p. 112 operand0 | (Data 5.5.2.1) Figure T1004420-88, (N), p. 113 operand1 | (Data 5.5.2.1) Figure T1004430-88, (N), p. 114 operand2 | (Data 5.5.2.1) Figure T1004440-88, (N), p. 115 operand3 | (Data 5.5.2.1) Figure T1004450-88, (N), p. 116 operand4 | (Data 5.5.2.1) Figure T1004460-88, (N), p. 117 operand5 | (Data 5.5.2.1) Figure T1004470-88, (N), p. 118 primary Figure T1004480-88, (N), p. 119 active primary Figure T1004490-88, (N), p. 120 active expression list | (Data 5.5.2.1) Figure T1004500-88, (N), p. Figure T1004510-88, (N), p. Figure T1004520-88, (N), p. Figure T1004530-88, (N), p. Figure T1004540-88, (N), p. 121 assignment statement Figure T1004550-88, (N), p. 122 imperative operator | (Data 5.5.4) Figure T1004570-88, (N), p. 123 now expression Figure T1004580-88, (N), p. 124 PId expression Figure T1004590-88, (N), p. 125 literal Figure T1004600-88, (N), p. 126 label Figure T1004610-88, (N), p. 127 comment Figure T1004620-88, (N), p. 128 identifier Figure T1004630-88, (N), p. 129 qualifier Figure T1004640-88, (N), p. 130 decimal integer Figure T1004650-88, (N), p. Lexical rules syntax diagrams 131 lexical unit Figure T1004660-88, (N), p. 132 name Figure T1004670-88, (N), p. A name | must contain at least one alphabetic character. 133 end of name Figure T1004680-88, (N), p. 134 alphanumeric Figure T1004690-88, (N), p. 135 letter Figure T1004700-88, (N), p. 136 decimal digit Figure T1004710-88, (N), p. 137 national Figure T1004720-88, (N), p. 138 character string literal Figure T1004730-88, (N), p. 139 special Figure T100474600-88, (N), p. 140 composite special Figure T1004750-88, (N), p. 141 text Figure T1004760-88, (N), p. 142 note Figure T1004770-88, (N), p. 143 formal name Figure T1004780-88, (N), p. 144 keyword Figure T1004790-88, (N), p. Figure T1004800-88, (N), p. INDEX 107 active expression 120 active expression list 119 active primary 45 actual parameters 134 alphanumeric 35 answer 121 assignment statement 80 axioms 5 block definition 46 block substructure definition 47 block substructure reference 48 channel connection 14 channel definition 53 channel endpoint connection 51 channel substructure body 50 channel substructure definition 52 channel substructure reference 49 channel to route connection 138 character string literal 78 character string literal identifier 127 comment 140 composite special 93 constant 67 continuous signal 31 create request 43 data definition 136 decimal digit 130 decimal integer 34 decision 2 definition 3 diagram 68 enabling condition 40 end 133 end of name 81 equation 71 export 111 expression 84 extended operator identifier 88 extended operator name 90 extended properties 89 extended sort 57 external synonym definition 109 field selection 143 formal name 97 generator definition 98 generator formal name 101 generator instantiation 100 generator instantiations 99 generator sort 106 ground expression 108 ground primary 83 ground term 128 identifier 122 imperative operator 69 import definition 70 import expression 85 infix operator 44 informal text 95 inheritance rule 23 input 27 join 144 keyword 126 label 135 letter 131 lexical unit 125 literal 76 literal list 96 literal renaming 77 literal signature 56 macro call 55 macro definition 86 monadic operator 132 name 104 name class literal 137 national 26 nextstate 142 note 123 now expression 112 operand0 113 operand1 114 operand2 115 operand3 116 operand4 117 operand5 110 operator identifier 102 operator name 79 operator signature 75 operators 33 output 73 partial type definition 124 PId expression 118 primary 65 priority input 66 priority output 32 procedure call 12 procedure definition 10 process body 7 process definition 74 properties expression 129 qualifier 87 quoted operator 92 range conditions 105 regular expression 37 reset 29 return 24 save 58 select definition 60 service decomposition 61 service definition 62 service reference 64 service signal route definition 38 set 16 signal definition 41 signal list 17 signal list definition 54 signal refinement 63 signal route connection 15 signal route definition 11 simple expression 72 sort 42 sort list 139 special 21 start 22 state 28 stop 94 structure definition 91 syntype definition 103 synonym definition 1 system 4 system definition 30 task 82 term 141 text 6 textual block reference 13 textual procedure reference 8 textual process reference 39 timer active expression 36 timer definition 25 transition 59 transition option 9 valid input signal set 18 variable definition 19 view definition 20 view expression Fin premiere partie 39 ACTIVE 94, 95, 100 ADDING 74, 81, 95 ALL 59 ALTERNATIVE 48, 49, 53, 63, 85, 113 AND 74 AXIOMS 5, 6, 129 BLOCK 32 CALL 14 CHANNEL 127 COMMENT 48, 49, 53, 63 CONNECT 97 CONSTANT 91 CONSTANTS 31 CREATE 18 DCL 34 DECISION 74, 91 DEFAULT 34, 59, 83, 108, 120 ELSE 59 ENDALTERNATIVE 5 ENDBLOCK 14 ENDCHANNEL 34 ENDDECISION 97 ENDGENERATOR 55 ENDMACRO 73, 91 ENDNEWTYPE 12 ENDPROCEDURE 7 ENDPROCESS 54 ENDREFINEMENT 58 ENDSELECT 61 ENDSERVICE 22 ENDSTATE 46, 50 ENDSUBSTRUCTURE 91 ENDSYNTYPE 4 ENDSYSTEM 14, 15, 53, 64 ENV 82 ERROR 71 EXPORT 18 EXPORTED 57 EXTERNAL 83, 108, 120 FI 74, 81 FOR 7, 55 FPAR 14, 15, 64 FROM 97 GENERATOR 58, 83, 108, 120 IF 70 IMPORT 69 IMPORTED 12, 74, 81, 85, 114 IN 95 INHERITS 23, 65 INPUT 27 JOIN 97 LITERAL 74, 76, 96 LITERALS 56 MACRO 55 MACRODEFINITION 143 MACROID 74 MAP 85, 116 MOD 104 NAMECLASS 73, 91 NEWTYPE 26 NEXTSTATE 86, 117 NOT 123 NOW 124 OFFSPRING 97 OPERATOR 75, 95 OPERATORS 85, 105, 112 OR 75 ORDERING 12 OUT 33, 66 OUTPUT 124 PARENT 65, 66, 67 PRIORITY 12, 13, 129 PROCEDURE 7, 8, 129 PROCESS 67, 68 PROVIDED 6, 8, 13, 47, 52, 62 REFERENCED 54 REFINEMENT 85, 116 REM 37 RESET 29 RETURN 18 REVEALED 54 REVERSE 24 SAVE 58 SELECT 124 SELF 124 SENDER 61, 62, 129 SERVICE 38 SET 16, 129 SIGNAL 17 SIGNALLIST 15, 64 SIGNALROUTE 9 SIGNALSET 82 SPELLING 21 START 22 STATE 28 STOP 94 STRUCT 46, 47, 50, 52, 129 SUBSTRUCTURE 57, 103 SYNONYM 91 SYNTYPE 4, 129 SYSTEM 30 TASK 83, 108, 120 THEN 97, 129 TYPE 36 TIMER 14, 15, 33, 64 TO 33 VIA 20, 33 VIEW 19 VIEWED 14, 15, 64 WITH 85, 112 XOR ANNEX E (to Recommendation Z.100) State-oriented representation and pictorial elements E.1 Introduction SDL is based on an "extended" Finite State Machine (FSM) model. That is, an FSM is extended with objects, such as vari- ables, resources, etc. A machine stays in some state. On receiving a signal, a machine executes a transition, in which relevant actions (e.g. resource allocation and/or deallocation, resource control, signal sending, decision, etc.) are taken. Therefore, the dynamic behaviour of an extended FSM can be explained by describing action sequences on objects for each transition of the FSM in a procedural way. As a consequence of the state transition, the machine arrives in a new state. The state of an extended FSM can be characterized by objects associated with the state, additional object information (e.g. the value of variables, states of resources, relations between the resources), and signals which can be received in that state. For example, the "await-first-digit state" in telephone call processing is characterized as follows: Caller: handset-off Dial tone-sender: dialtone sending Digit receiver: ready for receiving Timer: supervising permanent-signal timing Path: Caller is connected to dial tone-sender and digit receiver, etc. As can be seen, each state can be defined statically by objects and additional information (qualifying text) associated with that state. The SDL/GR is extended with pictorial elements to define objects associated with each state. The state definitions in terms of pictorial elements are called state pictures . The SDL/GR state symbol may include a state picture. This is an optional part of SDL/GR. Figure E-1 shows a state definition example of the "await-first-digit state". Figure E-1, (N), p. In many cases, actions on each object, which are required in the transition, can be derived from the difference between state definitions before and after the transition. For example, if some resource appears only after transition, it means that resource allocation action is necessary in the transition. Therefore, if detailed state definitions are given, total actions in the extended FSM transition can usually be derived from the difference between pre-and post-state definitions. However, the sequence of actions in the transition may not be derived from the state definition differ- ence. Therefore, in SDL diagrams, when the sequence of actions is less important, those transition actions which can be derived from the state definition need not be described explicitly. Otherwise, it is desirable to describe action sequences explicitly. An SDL diagram, in which transitions are described exclusively by explicit action symbols, is called a transition-oriented version of SDL/GR . An SDL/GR diagram, in which states are described using state pictures and transition actions are minimized, is called the state-oriented version of SDL/GR or state-oriented SDL with pic- torial elements (SDL/PE). State pictures can be used advantageously when applied to certain system definitions, resulting in more com- pact, declarative and less verbal process diagrams. A combined version is also possible. Thus, these are 3 SDL/GR versions: a) Transition-oriented version - Transition sequences are described exclusively by explicit action symbols. - This is, as it were, a procedural explanation of the extended FSM. - This version is suitable when the sequence of actions is important and detailed state descriptions are not impor- tant. b) State-oriented version - The state is described uniquely using pictorial elements. This picture is called a state picture. - The transition action sequence is implied by the difference between pre-and post-state definitions. - This is, as it were, a declarative specification of the extended FSM. - This vesion is suitable when the sequence of actions within each transition is of low importance, when pictorial explanation is desirable, or when a compact representation is desirable. c) Combined version - The combined version is suitable when both the sequence of actions within each transition and the detailed state descriptions are under consideration. Examples of these three versions are given in Figure E-2, E-3 and E-4. Figure E-2, (N), p. Figure E-3, (N), p. Figure E-4, (N), p. E.2 Pictorial elements in SDL/GR The syntax and semantics defined in Recommendation Z.100 SDL applies to pictorial elements. However, these semantics and syntax are extended as follows: Pictorial elements represent various objects. The repertoire of pictorial elements is in principle unlimited because new pic- torial elements can be invented to suit any new application of the SDL. However, in applications to telecommunications switching and signalling functions, the following repertoire of pictorial ele- ments has been found to have considerable versatility: - functional block boundary (left or right), - terminal equipment (various), - signalling receiver, - signalling sender, - combined signalling sender and receiver, - supervising timer, - switching path (connected, reserved), - switching modules, - charging in progress, - control elements, - uncertainty symbol. Standard symbols for these pictorial elements are recommended in section E.2.2. E.2.1 Rules of interpretation 1) A state symbol may include a state picture . A state picture defines de state using pictorial elements and quali- fying text. 2) Each pictorial element in a state picture represents an object associated with the state, such as: - resources, - variables, - internal and external boundaries, - the relations between objects, - signals which can be received in that state, - etc. 3) Each pictorial element may have accompanying qualifying text . Qualifying text can be used to explain: - detailed resource name, - the resource state, - value for a variable, - signals relevant to the object, - etc. 4) Function block boundary: a) A function block boundary is used to express whether a pictorial element is "internal" or "external" to the pro- cess. An internal pictorial element represents objects which are owned by the process. An external pictorial element represents objects which are owned by another process under consideration. b) Rule a) also applies to the distinction between internal and external qualifying text, by substituting the term "qualifying text" for pictorial elements in the rule. 5) Transition interpretation rule: The total processing involved when a process goes from one state to the following state is the combination of: - The processing to effect changes to all relevant objects which are derived from the state definition difference. - The processing explicitly described in the tran- sition, e.g. outputs or tasks. Thus: a) The absence from one state if a pictorial ele- ment which represents a resource with its presence in the next state implies the allocation of the resource in all transitions joining the two states. This can be equivalently represented by a task(s) showing allocation of the resource in transition(s). b) If "presence" and "absence" are interchanged in rule a), then "allocation" is replaced by "deallocation". c) In rule a) if "pictorial element" is replaced by "external pictorial element" then the task should be replaced by an output signal requesting the process which owns the resource to allocate it or simply an input signal from that process saying that it has been allocated. d) If in rule a) "presence" and "absence" are interchanged and also "pictorial element" is replaced by "external pictorial element" then follow rule c) with "allocate" replaced with "deallocate". e) Rules a), b), c) and d) also apply to the appearance or disappearance in the state picture of qualifying text, by substituting the term "qualifying text" for pictorial ele- ments in those rules. 6) For a given process diagram, particular pic- torial elements (or a particular combination of pictorial elements and qualifying text) should always be placed in the same position within the state picture whenever they appear, so that the presence or absence of this pictorial element (or combination) in a state symbol can be quickly determined by comparing the state picture with other state pictures in the process diagram. 7) When a signal sender appears in a state picture, its qualifying text identifies a signal which is sent during the following transitions. 8) When a sender of a permanent signal (e.g. a ringtone) appears in a state picture, its qualifying text identi- fies a signal which has been started to be sent during the follow- ing transition and in this state. 9) Such transition actions that cannot be derived from the difference of pre- and post-state definitions should be explicitly described in the transition. For example, if a resource with an exported variable does not appear in the pre- and post-states, the necessary actions are better to be described in the transition. E.2.2 Recommended symbols for pictorial elements When using pictorial elements, each state is represented by a state symbol containing a state picture with the format shown in Figure E-5: Figure E-5, (MC), p. A basic set of pictorial elements is recommended for use in SDL/GR with application to the system description of telecommunica- tions call handling processes, including signalling protocols, net- work services and signalling interworking processes. Many of these pictorial elements are capable of being applied in applications of SDL/GR to other than call handling processes. The recommended symbols for the basic set of pictorial ele- ments is shown in Figure E-6, and the recommended proprotions for pictorial element symbols are shown in Figure E-7. Examples of the use of the basic set of pictorial elements are shown in Figure E-8. E.2.3 Special conventions and interpretations used in the state oriented extension of SDL/GR A number of special conventions and interpretations have been defined in this section with regard to the state-oriented version of SDL/GR. These includes: - The special interpretation required for process diagrams according to the so-called TRANSITION INTERPRETATION RULE (see S E.2.1, rule 5). - The unique position of pictorial elements (or pictorial elements and qualifying text) within a state picture that is required when using pictorial elements (see S E.2.1, rule 6). - The special interpretation required for the vari- ables represented by external pictorial elements and external qual- ifying text, as proxy variables associated with other processes. E.3 Selection criteria for pictorial elements The choice of symbols for pictorial elements has been based upon the following considerations and general selection criteria. These should be consulted before developing additional pictorial element symbols for wider applications of the SDL. 1) Ease of reproduction In order to permit convenient reproduction of SDL diagrams using the dye-line or blue-print methods of reproduction as well as photocopying and photo-printing, pictorial element symbols should consist of clear lines without shading or coloration. 2) Ease of comprehension a) Appropriateness - The shape of each symbol should be appropriate to the concept that the symbol represents. b) Distinctiveness - When choosing a basic set of symbols, care should be taken to permit each symbol to be readily distinguishable from others in the set. c) Affinity - The shapes of pictorial elements representing different but related functions, e.g. receivers and senders, should be related in some obvious way. d) Association of abbreviated qualifying text with symbols - In some cases it is expected that abbreviated text will be associated with a pictorial element in order to indicate the class of pictorial element; e.g. the letters MFC associated with a receiver symbol to indicate that multi-frequency coded signals are to be received. In these cases, the pictorial elements should incorporate enclosed space to permit the use of a very small number of alphanumerical characters. e) Limited set - The total number of symbols should be kept to a minimum in order to permit easy learning of the pic- torial method. Figure E-6, (MC), p. Figure E-7, (MC), p. Figure E-8, (MC), p. Figure E-8 (suite), (MC), p. Figure E-8 (suite), (MC), p. Figure E-8 (fin), (MC), p. Recommendation Z.110 CRITERIA FOR THE USE AND APPLICABILITY OF FORMAL DESCRIPTION TECHNIQUES 1 Support for formal description techniques (FDTs) In view of the complexity and widespread use of _________________________ The content of this Recommendation is also published as ISO Resolution ISO/IEC JTC 1/N 145. The statement on precedence in case of several descriptions contained in the JTC 1 document is omitted in this Recommendation. Recommendations it is imperative that advanced methods for the development and implementation of these Recommendations be used. Formal description techniques provide an important approach toward such advanced methods. In some areas, the use of FDTs is still relatively new and phased procedures are required to introduce their use. This Recom- mendation proposes the procedures to accomplish this task. 2 FDTs 2.1 Definitions A formal description technique (FDT) is a specification method based on a description language using rigorous and unambiguous rules both with respect to developing expressions in the language (formal syntax) and interpreting the meaning of these expressions (formal semantics). FDTs are intended to be used in the develop- ment, specification, implementation and verification of Recommenda- tions (or parts thereof). A natural language description is an example of an informal description technique using one of the languages used by CCITT to publish Recommendations. It may be supplemented with mathematical and other accepted notation, figures, etc. 2.2 Objectives of an FDT The goal of an FDT is to permit precise and unambiguous specifications. FDTs are also intended to satisfy objectives such as: - a basis for analyzing specifications for correct- ness, efficiency, etc.; - a basis for determining completeness of specifi- cations; - a basis for verification of specifications against the requirement of the Recommendation; - a basis for determining conformance of implemen- tations to Recommendations; - a basis for determining consistency of specifica- tions between Recommendations; - a basis for implementation support. In the current state of the art, in some areas more than one FDT may be needed to accomplish all objectives. 2.3 Benefits of an FDT The application of an FDT can provide benefits such as: - improving the quality of Recommendations, which in turn reduces maintenance costs to both CCITT and to users of Recommendations; - reducing dependency on the natural language to communicate technical concepts in a multilingual environment; - reducing development time of implementations by using tools that are based on the properties of the FDT; - making the implementation easier, resulting in better products. 2.4 Problem with FDTs FDTs are advanced techniques which have not yet been widely introduced. In addition, there is a lack of resources in the development of FDTs and formal descriptions (FDs), as well as a lack of expertise within the CCITT Study Groups both to assess the technical merits of the formally described Recommendations and to reach consensus on them. 2.5 Solutions The development of tutorial and educational materials will help to provide widespread understanding of the complexities of FDTs. Nevertheless, time must be permitted for their assimilation. 3 Development and standardization of FDTs It is important to avoid unnecessary proliferation of FDTs. The following criteria should be met before adopting a new FDTs: - the need for the FDT should be demonstrated; - evidence that it is based on a significantly different model from that of an existing FDT should be provided, and - the usefulness and capabilities of the FDT should be demonstrated. 4 Development and acceptance of formal descriptions 4.1 In future, only standard FDTs or FDTs in the process of being standardized should be used in formal descriptions of Recom- mendations. 4.2 It is considered that the development of a FD of any par- ticular Recommendation is a decision of the Study Group (in consul- tation with ISO for collaborative standards). If a FD is to be developed for a new Recommendation, the FD should be progressed, as far as possible, according to the same timetable as the rest of the Recommendation. 4.3 For the evolutionary introduction of FDs into Recommenda- tions three phases can be identified. It is the responsibility of the Study Group to decide which phase initially applies to each FD and the possible evolution of the FD toward another phase. It is not mandatory for a FD to go through the three phases described below and, more generally, it is not mandatory for a FD to evolve. Phase 1 This phase is characterized by the fact that widespread knowledge of FDTs, and experience in formal descriptions, are lack- ing; there may not be sufficient resources in the Study Groups to produce or review formal descriptions. The development of Recommendations has to be based on conven- tional natural language approaches, leading to Recommendations where the natural language description is the definitive Recommen- dation. Study Groups are encouraged to develop FDs of their Recommen- dations since these efforts may contribute to the quality of the Recommendations by detecting defects, may provide additional under- standing to readers, and will support the evolutionary introduction of FDTs. A formal description produced by a Study Group that can be considered to represent faithfully a significant part of the Recom- mendation or the complete Recommendation should be published as an appendix to the Recommendation. Meanwhile Study Groups should develop and provide educational material for the FDTs to support their widespread introduction in the CCITT and Liaison Organizations. Phase 2 This phase is characterized by the fact that knowledge of FDTs and experience in formal descriptions is more widely available; Study Groups can provide enough resources to support the production of formal descriptions. However, it cannot be assured that enough CCITT Members can review formal descriptions in order to enable them to approve a proposed formally described Recommendation. The development of Recommendations should still be based on conventional natural language approaches, leading to Recommendation where the natural language description is the definitive standard. However, these developments should be accompanied and supported by the development of formal descriptions of these standards with the objective of improving and supporting the structure, consistency, and correctness of the natural language description. A formal description, produced by Study Group, that is con- sidered to represent faithfully a significant part of the Recommen- dation or the complete Recommendation should be published as an annex to the Recommendation. Meanwhile educational work should continue. Phase 3 This phase is characterized by the fact that a widespread knowledge of FDTs may be assumed; CCITT Members can provide suffi- cient resources both to produce and review formal descriptions, and assurance exists that the application of FDTs does not unneces- sarily restrict freedom of the implementations. Study Groups should use FDTs routinely to develop their Recom- mendations, and the FD(s) become part of the Recommendation together with natural language descriptions. Whenever a dicrepancy between a natural language description and a formal description, or between two formal descriptions, is detected, the discrepancy should be resolved by changing or improv- ing the natural language description or the FDs without necessarily giving preference to one over the other(s). 4.4 The above procedures for phased development of FDs are intended to aid the progression of FDs within the standards pro- cess, not to hinder their progression. However, since there has been little or no actual experience with these procedures, any Study Group having to use them is urged to identify one or more pilot cases and carefully monitor the progress of each within the framework of the procedures. Should procedural problems arise, the Study Group responsible for Formal Description Techniques should be informed and, where possible, recommended procedural modifications should be proposed to alleviate the problems.