delim @@
|
| 5i' |
||||
|
ANNEX C2 SDL PR syntax summary |
||||
|
1 |
system |
2 definition
3 diagram
Diagram is defined in GR syntax summary.
4 system definition | (Basic SDL 2.4.1)
5 block definition | (Basic SDL 2.4.2)
6 textual block reference | (Basic SDL 2.4.2)
7 process definition | (Basic SDL 2.4.3)
Figure T1003290-88, (N), p.
8 textual process reference | (Basic SDL 2.4.3)
9 valid input signal set
10 process body | (Basic SDL 2.4.3)
11 simple expression
12 procedure definition | (Basic SDL 2.3.4)
13 textual procedure reference | (Basic SDL 2.3.4)
14 channel definition | (Basic SDL 2.5.1)
15 signal route definition | (Basic SDL 2.5.2)
16 signal definition | (Basic SDL 2.5.4)
17 signal list definition | (Basic SDL 2.5.5)
18 variable definition | (Basic SDL 2.6.1.1)
19 view definition | (Basic SDL 2.6.1.2)
20 view expression | (Data 5.5.4.4)
21 start | (Basic SDL 2.6.2)
22 state | (Basic SDL 2.6.3)
23 input | (Basic SDL 2.6.4)
24 save | (Basic SDL 2.6.5)
25 transition | (Basic SDL 2.6.7)
26 nextstate | (Basic SDL 2.6.7.2.1)
27 join | (Basic SDL 2.6.7.2.2)
28 stop | (Basic SDL 2.6.7.2.3)
29 return | (Basic SDL 2.6.7.2.4)
30 task | (Basic SDL 2.7.1)
31 create request | (Basic SDL 2.7.2)
32 procedure call | (Basic SDL 2.7.3)
33 output | (Basic SDL 2.7.4)
34 decision | (Basic SDL 2.7.5)
35 answer | (Basic SDL 2.7.5)
36 timer definition | (Basic SDL 2.8)
37 reset | (Basic SDL 2.8)
38 set | (Basic SDL 2.8)
39 timer active expression | (Data 5.5.4.5)
40 end
41 signal list
42 sort list
43 data definition
44 informal text
45 actual parameters
46 block substructure definition | (Structural concepts 3.2.2)
47 block substructure reference | (Structural concepts 3.2.2)
48 channel connection | (Structural concepts 3.2.2)
49 channel to route connection | (Structural concepts 3.2.2)
50 channel substructure definition | (Structural concepts 3.2.3)
51 channel substructure body | (Structural concepts 3.2.3)
52 channel substructure reference | (Basic SDL 2.5.1)
53 channel endpoint connection | (Structural concepts 3.2.3)
54 signal refinement | (Structural concepts 3.3)
55 macro definition | (Additional concepts 4.2.2)
56 macro call | (Additional concepts 4.2.3)
57 external synonym definition | (Additional concepts 4.3.1)
58 select definition | (Additional concepts 4.3.3)
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)
62 service reference | (Additional concepts 4.10.1)
63 signal route connection | (Additional concepts 4.10.1)
64 service signal definition | (Additional concepts 4.10.1)
65 priority input | (Additional concepts 4.10.2)
66 priority output | (Additional concepts 4.10.2)
67 continuous signal | (Additional concepts 4.11)
68 enabling condition | (Additional concepts 4.12)
69 import definition | (Additional concepts 4.13)
70 import expression | (Additional concepts 4.13)
71 export | (Additional concepts 4.13)
72 sort | (Data 5.2.2)
73 partial type definition | (Data 5.2.1)
74 properties expression | (Data 5.2.1 and 5.5.3.3)
75 operators | (Data 5.2.2 and 5.4.1.8)
76 literal list | (Data 5.2.2)
77 literal signature | (Data 5.2.2 & 5.4.1.8)
78 character string literal identifier
79 operator signature | (Data 5.2.2)
80 axioms | (Data 5.2.3 and 5.2.4)
81 equation
Figure T1004030-88, (N), p. 82 term
|
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. |
84 extended operator identifier
85 infix operator
Figure T1004150-88, (N), p. 86 monadic operator
87 quoted operator
88 extended operator name | (Data 5.4.1)
89 extended sort | (Data 5.4.1.9)
90 extended properties | (Data 5.4.1)
91 syntype definition | (Data 5.4.1.9)
92 range conditions | (Data 5.4.1.9.1)
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)
97 generator definition | (Data 5.4.1.12.1)
98 generator formal name | (Data 5.4.1.12.1)
99 generator sort | (Data 5.4.1.12.1)
100 generator instantiations | (Data 5.4.1.12.2)
101 generator instantiation (Data 5.4.1.12.2)
102 operator name
103 synonym definition | (Data 5.4.1.13)
104 name class literal | (Data 5.4.1.14)
105 regular expression | (Data 5.4.1.14)
106 ground expression | (Data 5.4.2.1)
107 active expression | (Data 5.4.2.2)
108 ground primary | (Data 5.4.2.2)
109 field selection
110 operator identifier
111 expression | (Data 5.5.2.1)
112 operand0 | (Data 5.5.2.1)
113 operand1 | (Data 5.5.2.1)
114 operand2 | (Data 5.5.2.1)
115 operand3 | (Data 5.5.2.1)
116 operand4 | (Data 5.5.2.1)
117 operand5 | (Data 5.5.2.1)
118 primary
119 active primary
120 active expression list | (Data 5.5.2.1)
121 assignment statement
122 imperative operator | (Data 5.5.4)
Figure T1004570-88, (N), p.
123 now expression
124 PId expression
125 literal
126 label
127 comment
128 identifier
129 qualifier
130 decimal integer
Lexical rules syntax diagrams 131 lexical unit
|
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 |
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 |
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.
|
107 120 119 45 134 35 121 80 5 46 47 48 14 53 51 50 52 49 138 78 127 140 93 67 31 43 136 130 34 2 3 |
active expression active expression list active primary actual parameters alphanumeric answer assignment statement axioms block definition block substructure definition block substructure reference channel connection channel definition channel endpoint connection channel substructure body channel substructure definition channel substructure reference channel to route connection character string literal character string literal identifier comment composite special constant continuous signal create request data definition decimal digit decimal integer decision definition diagram |
INDEX |
|
68 40 133 81 71 111 84 88 90 89 57 109 143 97 98 101 100 99 106 108 83 128 122 69 70 |
enabling condition end end of name equation export expression extended operator identifier extended operator name extended properties extended sort external synonym definition field selection formal name generator definition generator formal name generator instantiation generator instantiations generator sort ground expression ground primary ground term identifier imperative operator import definition import expression |
|
85 44 95 23 27 144 126 135 131 125 76 96 77 56 55 86 132 104 137 26 142 123 112 113 114 115 116 117 110 102 79 75 33 73 |
infix operator informal text inheritance rule input join keyword label letter lexical unit literal literal list literal renaming literal signature macro call macro definition monadic operator name name class literal national nextstate note now expression operand0 operand1 operand2 operand3 operand4 operand5 operator identifier operator name operator signature operators output partial type definition |
|
124 118 65 66 32 12 10 7 74 129 87 92 105 37 29 24 58 60 61 62 64 38 |
PId expression primary priority input priority output procedure call procedure definition process body process definition properties expression qualifier quoted operator range conditions regular expression reset return save select definition service decomposition service definition service reference service signal route definition set |
|
16 41 17 54 63 15 11 72 42 139 21 22 28 94 91 103 1 4 30 82 141 6 13 8 39 36 25 59 9 18 19 20 |
signal definition signal list signal list definition signal refinement signal route connection signal route definition simple expression sort sort list special start state stop structure definition syntype definition synonym definition system system definition task term text textual block reference textual procedure reference textual process reference timer active expression timer definition transition transition option valid input signal set variable definition view definition view expression |
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 91 31 18 34 74, 91 |
CONSTANT CONSTANTS CREATE DCL DECISION DEFAULT |
34, 59, 83, 108, 120 ELSE
|
59 5 14 34 97 55 73, 91 12 7 54 58 61 22 46, 50 91 4 |
ENDALTERNATIVE ENDBLOCK ENDCHANNEL ENDDECISION ENDGENERATOR ENDMACRO ENDNEWTYPE ENDPROCEDURE ENDPROCESS ENDREFINEMENT ENDSELECT ENDSERVICE ENDSTATE ENDSUBSTRUCTURE ENDSYNTYPE 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 23, 65 27 97 |
INHERITS INPUT JOIN LITERAL |
74, 76, 96 LITERALS
|
56 55 143 74 85, 116 104 73, 91 26 86, 117 123 124 97 75, 95 |
MACRO MACRODEFINITION MACROID MAP MOD NAMECLASS NEWTYPE NEXTSTATE NOT NOW OFFSPRING OPERATOR 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 29 18 54 24 58 124 124 |
RESET RETURN REVEALED REVERSE SAVE SELECT SELF SENDER |
61, 62, 129 SERVICE
38 SET
16, 129 SIGNAL
|
17 15, 64 9 82 21 |
SIGNALLIST SIGNALROUTE SIGNALSET SPELLING 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 variables, 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 difference. 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 .
70 Fascicle X.1 -- Rec. Z.100 -- Annex E
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 pictorial elements (SDL/PE). State pictures can be used advantageously when applied to certain system definitions, resulting in more compact, declarative and less verbal process diagrams.
Fascicle X.1 -- Rec. Z.100 -- Annex E 71
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 |
72 Fascicle X.1 -- Rec. Z.100 -- Annex E
|
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. |
|||
|
Fascicle X.1 -- |
Rec. Z.100 -- Annex E |
73 |
Figure E-3, (N), p. 74 Fascicle X.1 -- Rec. Z.100 -- Annex E
Figure E-4, (N), p. Fascicle X.1 -- Rec. Z.100 -- Annex E 75
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 pictorial 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 elements 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 qualifying text.
|
76 |
2) Each -- resources, -- variables, -- internal -- the -- signals -- etc. 3) Each -- detailed -- the -- value -- signals Fascicle |
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. 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, X.1 -- Rec. Z.100 -- Annex E |
-- etc.
4) Function block boundary:
a) A function block boundary is used to express whether a pictorial element is ``internal'' or ``external'' to the process. 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 transition, e.g. outputs or tasks.
Fascicle X.1 -- Rec. Z.100 -- Annex E 77
Thus:
a) The absence from one state if a pictorial element 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 elements in those rules.
6) For a given process diagram, particular pictorial 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 identifies a signal which has been started to be sent during the following 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. 78 Fascicle X.1 -- Rec. Z.100 -- Annex E
A basic set of pictorial elements is recommended for use in SDL/GR with application to the system description of telecommunications call handling processes, including signalling protocols, network 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 elements 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 § 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 § E.2.1, rule 6).
-- The special interpretation required for the variables represented by external pictorial elements and external qualifying 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) a) b) |
Ease of comprehension Appropriateness -- The shape of each symbol should be appropriate to the concept that the symbol 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 pictorial method.
Fascicle X.1 -- Rec. Z.100 -- Annex E 79
Figure E-6, (MC), p. 80 Fascicle X.1 -- Rec. Z.100 -- Annex E
Figure E-7, (MC), p. Fascicle X.1 -- Rec. Z.100 -- Annex E 81
Figure E-8, (MC), p. 82 Fascicle X.1 -- Rec. Z.100 -- Annex E
Figure E-8 (suite), (MC), p. Fascicle X.1 -- Rec. Z.100 -- Annex E 83
Figure E-8 (suite), (MC), p. 84 Fascicle X.1 -- Rec. Z.100 -- Annex E
Figure E-8 (fin), (MC), p. Fascicle X.1 -- Rec. Z.100 -- Annex E 85
CRITERIA FOR THE USE AND APPLICABILITY
OF FORMAL DESCRIPTION TECHNIQUES
In view of the complexity and widespread use of 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 Recommendation proposes the procedures to accomplish this task.
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 development, specification, implementation and verification of Recommendations (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 correctness, efficiency, etc.; a basis for determining completeness of specifications; a basis for verification of specifications against the requirement of the Recommendation; a basis for determining conformance of implementations to Recommendations; a basis for determining consistency of specifications 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 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.
86 Fascicle X.1 -- Rec. Z.110
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.
Fascicle X.1 -- Rec. Z.110 87
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.
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.1 In future, only standard FDTs or FDTs in the process of being standardized should be used in formal descriptions of Recommendations.
4.2 It is considered that the development of a FD of any particular Recommendation is a decision of the Study Group (in consultation 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 Recommendations 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 lacking; 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 conventional natural language approaches, leading to Recommendations where the natural language description is the definitive Recommendation.
Study Groups are encouraged to develop FDs of their Recommendations since these efforts may contribute to the quality of the Recommendations by detecting defects, may provide additional understanding to readers, and will support the evolutionary introduction of FDTs.
88 Fascicle X.1 -- Rec. Z.110
A formal description produced by a Study Group that can be considered to represent faithfully a significant part of the Recommendation 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.
Fascicle X.1 -- Rec. Z.110 89
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 considered to represent faithfully a significant part of the Recommendation 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 sufficient resources both to produce and review formal descriptions, and assurance exists that the application of FDTs does not unnecessarily restrict freedom of the implementations.
Study Groups should use FDTs routinely to develop their Recommendations, 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 improving 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 process, 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.
90 Fascicle X.1 -- Rec. Z.110
Fascicle X.1 -- Rec. Z.110 91