The call processing path was initiated with a dedicated relationship (session
phase) from the root element, specifying if the call was incoming or outgoing.
. For most choices two alternative path relationships were added, called default
and otherwise. The otherwise path was de?¬?ned to be legal only for selected call
elements, namely, address, language, priority, string, and time. See Fig. 5.6 for a
detailed metamodel.
. As lookup had three alternative types, their value was added to the dedicated
relationship type (called next_element lookup). This relationship could only be
initiated by the lookup element.
. Similarly for the proxy: a relationship with a property type for proxy output was
added. This relationship could only be started from a proxy element and had
?¬?ve different output values. Use of the same values multiple times for the same
proxy instance gave a warning. Having just a warning was preferred, as it would
allow changing output values without ?¬?rst deleting existing values.
Rules for Model Hierarchy To support reuse of other call processing
speci?¬?cations, the language provided a subaction concept. Each subaction object
could include only one subaction speci?¬?cation. During code generation, subactions
were produced ?¬?rst, followed by the main call speci?¬?cation.
Model Checking Reports In addition to constraints and rules attached to the
metamodel, separate model checking reports were also made.
Pages:
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228