Formal Techniques for Networked and Distributed Systems - FORTE 2003: 23rd IFIP WG 6.1 International Conference, Berlin, Germany, September 29 -- October 2, 2003

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen

2767

3

Berlin Heidelberg New York Hong Kong London Milan Paris Tokyo

Hartmut K¨onig Monika Heiner Adam Wolisz (Eds.)

Formal Techniques for Networked and Distributed Systems – FORTE 2003 23rd IFIP WG 6.1 International Conference Berlin, Germany, September 29 – October 2, 2003 Proceedings

13

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors Hartmut K¨onig Monika Heiner Brandenburg University of Technology at Cottbus Faculty of Mathematics, Natural Sciences and Computer Science P. O. Box 10 13 44, 03013 Cottbus, Germany E-mail:{koenig/mh}@informatik.tu-cottbus.de Adam Wolisz Technical University Berlin TKN - Telecommunication Networks Group Einsteinufer 25, 10587 Berlin, Germany E-mail: [email protected]

Cataloging-in-Publication Data applied for A catalog record for this book is available from the Library of Congress Bibliographic information published by Die Deutsche Bibliothek Die Deutsche Bibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data is available in the Internet at .

CR Subject Classification (1998): C.2.4, D.2.2, C.2, D.2.4-5, D.2, F.3, D.4 ISSN 0302-9743 ISBN 3-540-20175-0 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are liable for prosecution under the German Copyright Law. Springer-Verlag Berlin Heidelberg New York a member of BertelsmannSpringer Science+Business Media GmbH http://www.springer.de ©2003 IFIP International Federation for Information Processing, Hofstrasse 3, 2361 Laxenburg,Austria Printed in Germany Typesetting: Camera-ready by author, data conversion by Steingr¨aber Satztechnik Printed on acid-free paper SPIN 10930977 06/3142 543210

Preface

This volume contains the proceedings of FORTE 2003, the 23rd IFIP TC 6/ WG 6.1 International Conference on Formal Techniques for Networked and Distributed Systems, held in Berlin, Germany, September 29 – October 2, 2003. FORTE denotes a series of international working conferences on formal description techniques (FDTs) applied to computer networks and distributed systems. The conference series started in 1981 under the name PSTV. In 1988 a second series under the name FORTE was set up. Both series were united to FORTE/PSTV in 1996. Two years ago the conference name was changed to its current form. The last five meetings of this long conference series were held in Paris, France (1998), Beijing, China (1999), Pisa, Italy (2000), Cheju Island, Korea (2001), and Houston, USA (2002). The 23rd FORTE conference was especially dedicated to the application of formal description techniques to practice, especially in the Internet and communication domain. The scope of the papers presented at FORTE 2003 covered the application of formal techniques, timed automata, FDT-based design, verification and testing of communication systems and distributed systems, and the verification of security protocols. In addition, work-in-progress papers were presented which have been published in a separate volume. The FORTE 2003 program consisted of 9 sessions, 2 work-in-progress sessions, and a working session on the practicability of formal description techniques. Three invited talks and a keynote speech gave an overview on actual results and experience in the application of formal description techniques in the Internet and communication domain. The conference was preceded by 3 half-day tutorials. The proceedings contain the 24 regular papers accepted and presented at the conference. They were selected from 55 submitted papers in a careful selection procedure based on the assessment of three referees for each paper. The proceedings also include the text of the invited talks of Manfred Broy, Jonathan Billington, and Jean-Pierre Courtiat. FORTE 2003 was organized under the auspices of IFIP TC 6 by BTU Cottbus, the Brandenburg University of Technology Cottbus, and by TU Berlin, the Technical University of Berlin. It was supported by a number of partners including Microsoft, Telelogic, Bosch AG, the Deutsche Forschungsgemeinschaft (DFG), and the Berlin Marketing und Tourismus GmbH. We would like to express our gratitude to the numerous people who contributed to the success of FORTE 2003. The reviewing process was one of the major efforts during the preparation of the conference. It was completed by experts from around the world. The reviewers are listed in these proceedings. Finally, we would like to thank the local organizers for the excellent running of the conference, especially Katrin Willh¨ oft, Christian Noack, Sarina Gwiszcz, Joachim Paschke, Irene Ostertag, and Ronny Richter.

VI

Preface

Our special thanks goes to Katrin Willh¨ oft, Christian Noack, and Mario Z¨ uhlke from the BTU Cottbus for their hard work in organizing and preparing these proceedings.

September 2003

Hartmut K¨ onig Monika Heiner Adam Wolisz

Organization

Conference Chairs Hartmut K¨ onig, Brandenburg University of Technology Cottbus, Germany Monika Heiner, Brandenburg University of Technology Cottbus, Germany Adam Wolisz, Technical University of Berlin, Germany

Steering Committee Gregor v. Bochmann, University of Ottawa, Canada Ed Brinksma, Univ. of Twente, The Netherlands Stan Budkowski, INT Evry, France Guy Leduc, University of Liege, Belgium Elie Najm, ENST, France Richard Tenney, University of Massachusetts, USA Kenneth Turner, University of Stirling, UK

Technical Program Committee T. Bolognesi, IEI Pisa, Italy E. Borcoci, University of Bucarest, Romania H. Bowman, University of Kent, UK A. Cavalli, INT Evry, France P. Dembinski, IPI Warsaw, Poland R. Gotzhein, Univ. of Kaiserslautern, Germany R. Groz, INPG Grenoble, France U. Herzog, Univ. of Erlangen, Germany T. Higashino, Osaka University, Japan D. Hogrefe, University of G¨ ottingen, Germany G. J. Holzmann, Bell Labs, USA C. Jard, IRISA, France F. Khendek, Concordia University Montreal, Canada M. Kim, ICU Taejon, Korea P. Kritzinger, University of Cape Town, South Africa H. Krumm, University of Dortmund, Germany D. Lee, Bell Labs, China M. Luukkainen, University of Helsinki, Finland B. M¨ uller-Clostermann, University of Essen, Germany M. Nunez, University of Madrid, Spain

VIII

Organization

D. A. Peled, University of Warwick, UK A. Petrenko, CRIM Montreal, Canada K. Suzuki, Advanced Comm. Coop., Japan ¨ Uyar, City University of New York, USA U. J. Wu, Tsinghua University, Beijing, China M. Y. Vardi, Rice University Houston, USA N. Yevtushenko, Tomsk State University, Russia

Additional Reviewers G. Bao, Bell Labs Research, China M. ter Beek, IEI Pisa, Italy S. Boroday, CRIM, Canada J. Brandt, University of Kaiserslautern, Germany J. Bredereke, University of Bremen, Germany C. Chi, Bell Labs Research, China A. Duale, IBM, USA M. Ebner, University of G¨ ottingen, Germany M. Fecko, Telcordia, USA D. de Frutos, Universidad Complutense de Madrid, Spain X. Fu, University of G¨ ottingen, Germany R. Gotzhein, University of Kaiserslautern, Germany R. Grammes, University of Kaiserslautern, Germany H. Hallal, CRIM, Canada R. Hao, Bell Labs Research, China T. Hasegawa, KDDI R&D Laboratories Inc., Japan J. Huo, CRIM, Canada A. Idoue, KDDI R&D Laboratories Inc., Japan Y. Ishihara, Osaka University, Japan S. Kang, Information and Communications University, Korea T. Karvi, University of Helsinki, Finland K. Li, Bell Labs Research, China L. Llana, Universidad Complutense de Madrid, Spain N. L´ opez, Universidad Complutense de Madrid, Spain S. Maag, INT, France S. Maharaj, University of Stirling, United Kingdom T. Massart, Free University of Brussels (ULB), Belgium A. Mederreg, INT, France A. Nakata, Osaka University, Japan T. Ogishi, KDDI R&D Laboratories Inc., Japan S. Prokopenko, Tomsk State University, Russia S. Reiff-Marganiec, University of Stirling, United Kingdom I. Rodr´ıguez, Universidad Complutense de Madrid, Spain F. Rubio, Universidad Complutense de Madrid, Spain

Organization

C. E. Shankland, University of Stirling, United Kingdom R. Soltwisch, University of G¨ ottingen, Germany J. Thees, University of Kaiserslautern, Germany M. Tienari, University of Helsinki, Finland V. Trenkaev, Tomsk State University, Russia H. Ural, University of Ottawa, Canada A. Ulrich, Siemens, Germany E. Vieira, INT, France G. Yang, Bell Labs Research, China K. Yasumoto, Nara Inst. Sci. Tech, Japan S. Yovine, IMAG, Grenoble, France

Organization Committee Sarina Gwiszcs, Brandenburg University of Technology Cottbus, Germany Christian Noack, Brandenburg University of Technology Cottbus, Germany Irene Ostertag, Technical University of Berlin, Germany Ronny Richter, Brandenburg University of Technology Cottbus, Germany Katrin Willh¨ oft, Brandenburg University of Technology Cottbus, Germany Mario Z¨ uhlke, Brandenburg University of Technology Cottbus, Germany

IX

X

Organization

Partners

Berlin Tourismus Marketing GmbH

Brandenburg University of Technology Cottbus

Technische Universit¨at Berlin

Table of Contents

UNIX STREAMS Generation from a Formal Specification . . . . . . . . . . . . . . Pawe´´l Rychwalski, Jacek Wytr bowicz

1

Specifying and Realising Interactive Voice Services . . . . . . . . . . . . . . . . . . . . . 15 Kenneth J. Turner Vertical Reuse in the Development of Distributed Systems with FDTs . . . . 31 Reinhard Gotzhein Service-Oriented Systems Engineering: Modeling Services and Layered Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Manfred Broy Validation of the Sessionless Mode of the HTTPR Protocol . . . . . . . . . . . . . . 62 Paolo Romano, Milton Romero, Bruno Ciciani, Francesco Quaglia Generation of All Counter-Examples for Push-Down Systems . . . . . . . . . . . . 79 Samik Basu, Diptikalyan Saha, Yow-Jian Lin, Scott A. Smolka Modeling and Model Checking Mobile Phone Payment Systems . . . . . . . . . . 95 Tim Kempster, Colin Stirling Behavioural Contracts for a Sound Assembly of Components . . . . . . . . . . . . 111 Cyril Carrez, Alessandro Fantechi, Elie Najm Automatic Verification of Annotated Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Doron Peled, Hongyang Qu Combating Infinite State Using Ergo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Peter Robinson, Carron Shankland Numerical Coverage Estimation for the Symbolic Simulation of Real-Time Systems . . . . . . . . . . . . . . . . . . . . . 160 Farn Wang, Geng-Dian Hwang, Fang Yu Discrete Timed Automata and MONA: Description, Specification and Verification of a Multimedia Stream . . . . . . . 177 Rodolfo G´ omez, Howard Bowman Can Decision Diagrams Overcome State Space Explosion in Real-Time Verification? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Dirk Beyer, Andreas Noack How Stop and Wait Protocols Can Fail over the Internet . . . . . . . . . . . . . . . . 209 Jonathan Billington, Guy Edward Gallasch

XII

Table of Contents

Introducing Commutative and Associative Operators in Cryptographic Protocol Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Ivan Cibario Bertolotti, Luca Durante, Riccardo Sisto, Adriano Valenzano A Lightweight Formal Analysis of a Multicast Key Management Scheme . . 240 Mana Taghdiri, Daniel Jackson Formal Security Policy Verification of Distributed Component-Structured Software . . . . . . . . . . . . . . . . . . . . . . . . 257 Peter Herrmann Towards Testing SDL Specifications: Models and Fault Coverage for Concurrent Timers . . . . . . . . . . . . . . . . . . . . . 273 ¨ Mariusz A. Fecko, M. Umit Uyar, Ali Y. Duale Concerning the Ordering of Adaptive Test Sequences . . . . . . . . . . . . . . . . . . . 289 Robert M. Hierons, Hasan Ural Correct Passive Testing Algorithms and Complete Fault Coverage . . . . . . . . 303 Arun N. Netravali, Krishan K. Sabnani, Ramesh Viswanathan QoS Functional Testing for Multi-media Systems . . . . . . . . . . . . . . . . . . . . . . . 319 Tao Sun, Keiichi Yasumoto, Masaaki Mori, Teruo Higashino Towards Testing Stochastic Timed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Manuel N´ un ˜ez, Ismael Rodr´ıguez Formal Design of Interactive Multimedia Documents . . . . . . . . . . . . . . . . . . . 351 Jean-Pierre Courtiat Progressive Solutions to a Parallel Automata Equation . . . . . . . . . . . . . . . . . 367 Sergey Buffalov, Khaled El-Fakih, Nina Yevtushenko, Gregor v. Bochmann Type Abstraction in Formal Protocol Specifications with Container Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Joachim Thees Decomposing Service Definition in Predicate/Transition-Nets for Designing Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Hirozumi Yamaguchi, Gregor von Bochmann, Teruo Higashino Towards an Efficient Performance Evaluation of Communication Systems Described by Message Sequence Charts . . . . . . . 415 Hesham Kamal Arafat Mohamed, Bruno M¨ uller-Clostermann Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

UNIX STREAMS Generation from a Formal Specification Pawe´´l Rychwalski and Jacek Wytr bowicz
Institute of Computer Science, Warsaw University of Technology, Nowowiejska 15/19, 00-665 Warsaw, Poland

Abstract. This paper describes a new idea of rapid protocol implementation starting from its formal specification, namely to generate Unix STREAMS modules. We have exercised this idea using Estelle formal specification technique. The generator was written for Linux system. The paper demonstrates how the semantic problems were resolved and gives some conclusions from generations we have performed. Keywords: automatic code generation, Unix STREAMS, formal description techniques, Estelle

1

Introduction

Using formal description techniques in engineering of telecommunication protocol is common. For example an IEEE document that standardize a protocol contains SDL documentation in an annex. The most popular specification languages for protocol design are SDL, Estelle and Promella. All of them give an extended finite state machine (EFSM) model of a protocol. This model suits engineer demands for protocol validation, verification and test generation very well. Rapid prototyping i.e., automatic code generation from a formal specification into a working program is required not only due to time to market competition but also to obtain as correct implementation as the specification is. A designer has the opportunity to automatically generate a code when he uses a development environment for SDL or Estelle, like Tau SDL Suit from Telelogic (www.telelogic.com) or Estelle Development Toolset from INT (http://wwwlor.int-evry.fr). These generators were not worked out to meet high efficiency or to follow a specialized interface of an operating system used for protocol implementations. On the other hand, D. Ritchie has proposed STREAMS - an efficient mechanism for protocol implementation for Unix at 1984, [1]. This mechanism is included in every commercially distributed Unix operating system, e.g., Sun Solaris [2]. Thus most protocol implementations for these systems are Unix STREAMS modules. Designers of new protocol implementations have to determine STREAMS mechanism for Unix systems.


The research was partially supported by KBN grant No 7 T 11 C 013 20.

H. K¨ onig, M. Heiner, and A. Wolisz (Eds.): FORTE 2003, LNCS 2767, pp. 1–14, 2003. c IFIP International Federation for Information Processing 2003


2

Pawe´´l Rychwalski and Jacek Wytr bowicz

Despite of the fact that both Unix STREAMS and formal description techniques exist about 20 years, there were no attempts to lead out a STREAMS implementation from a formal specification. Several existing works about protocol implementations starting from its specification show, that generated implementation can be efficient. O.Catrina and A.Nogai [3] have compared the efficiency of a generated XTP implementation versus a hand-written one. J.Thees [4] and J.Bredereke [5] have analysed different heuristics, which could be applied during generation. R.Gotzhein et al. [6] analyzed how specification style can influence the efficiency of generated code. P. Langend¨ orfer and H. K¨ onig [7] proposed an interesting extension to SDL called iSDL, which consists in providing some annotation to control the way of code generation. In [8] and [9] authors propose a new mechanism called “activity threads”, which passes messages by procedure calls. This mechanism is very interesting, however it is not applicable to Unix STREAMS e.g., the STREAMS technique is based on message passing via queues not by procedure calls. Because a STREAMS implementation is efficient due to its concept and integration with operating system, we have decided to check the feasibility of a STREAMS module generation from an EFSM specification. To carry out this work, we have selected the Estelle specification language and Linux operating system by the reason of easy access to related tools. There is not enough place in this paper to give a complete explanation of Estelle specification technique nor Unix STREAMS, hence we refer a reader who is unfamiliar with them to [10] and [2]. In this paper we compare the Estelle semantics versus STREAMS semantics, we describe the selected translation model and we give some insights into a generator we have developed for Linux. In conclusions we present some results collected from efficiency tests of generated modules.

2

Estelle Semantics versus Streams Semantics

We can use both Estelle and STREAMS to implement network protocols, so it is obvious that there are some similarities between them. The main ones are: Modules – In both models, a protocol instance is represented by a module. Datagrams – Both Estelle and STREAMS modules exchange data in datagrams. Queues – The datagrams are queued at the entrance of a module. While the idea of passing from an Estelle protocol specification to STREAMS implementation seems to be quite natural, there are many difficulties to approach it to reality. The problem arises due to differences between Estelle formal semantic and STREAMS operational semantics. The first difference is the range of specification: in Estelle you specify a whole communication system, while one STREAMS module handles just one protocol. However, the most important is the possibility of communication with other modules: in Estelle, one module can

UNIX STREAMS Generation from a Formal Specification

3

communicate with any number of other modules, while in STREAMS one module can exchange data with just two other entities: upper and lower layers of protocol. The other differences include, but are not limited to: Dynamism – Estelle modules can be dynamically created and removed by another module, while a STREAMS module can only be pushed into and popped from a stream by a user-level process, which is an external (from module’s point of view) entity. Message queues – Estelle allows interaction points to share a common queue, while in a STREAMS module, each “interaction point” has its own queue. Exported variables – This kind of communication between Estelle modules cannot be represented as communication between STREAMS modules. The only communication mechanism for STREAMS is message passing. Module synchronization – There can be a synchronization between Estelle modules defined in a specification by using module attributes (i.e., process, systemprocess). There is no synchronization between STREAMS modules, they work independently from one another. Non-complete specification – In an early project stage or for documentation purposes it is useful to employ any-type, any-value or other similar constructs. Of course it is impossible to derive any implementation from them. These aspects cannot be translated into STREAMS directly for all specifications. That is why there should be some requirements on the input Estelle code, that will allow it to be translated into semantically equivalent STREAMS module. Chapter 3 describes them shortly. Queues Both Estelle and STREAMS modules have queues, yet the queue models obviously differ from each other. Estelle queues are “logical” and unbounded, while STREAMS ones are “physical” C structures with limited capacity. The limit of a STREAMS module queue can be quite high. Furthermore, the queue limit is not a size of a fixed array (in C-language sense), because queues are implemented as dynamic lists. It means that a module can put any number of messages into its own queue, even if it is over its high water mark. The only situation when the queue limit is checked is during passing the message further to another module (canputnext()), and it is the target module’s queue that is checked. The overflow of a STREAMS queue can be avoided by slowing down the sending module. It corresponds to the behavior of independent entities with no assumptions about their processing speed in a specification. Thus Estelle system modules and activity modules with unbounded queues have the same behavior as STREAMS modules using the canputnext() function to avoid message loss.

4

Pawe´´l Rychwalski and Jacek Wytr bowicz

EFSM Semantics The semantics of STREAMS tells nothing of internal module behavior, that is how it interprets and handles incoming messages, except for some standard guidelines. In particular, there are no restrictions on handling messages of userdefined structure. All of Estelle EFSM elements can be easily translated, or rather implemented in a STREAMS module. Internal variables of any type can be allocated in the module. Such variable can store a message parameter, the current automaton state, or any other internal data. Timers (for delay clauses) can be easily implemented using the library timeout() function1 . A transition can be implemented by a simple C function. A module can select and execute one or many transitions when it gets control, i.e., its put() or service() function is called or the timer completes. The module returns from its put(), service() or timer callback function when there is no ready transition to execute or when it must slow down to avoid overflowing of a destination queue. Specification languages allow to describe a non-deterministic behavior, because it is useful for documentation and for model analysis. An implementation should work in a deterministic manner, thus any non-deterministic statement is translated to a deterministic code, e.g., the Estelle delay(a,b) clause is implemented by a timeout function that is set to the a value.

3

Translation Model

To make generation of STREAMS implementation from an Estelle specification possible, we have to impose some restrictions on an input Estelle specification. They are the following: – The first and the most important one is the range of specification: STREAMS module will be generated from just one Estelle module body definition. – The second restriction is on the number of interaction points and their queue disciplines. To match the semantics of a STREAMS module, Estelle module definition must have exactly two external interaction points, with individual queues. – As the STREAMS module cannot “export” its variables to another module, the input Estelle module body cannot have any exported variables. – Input Estelle specification must be complete. Since STREAMS modules are independent and non synchronized entities, the best equivalent of them in Estelle specification are system modules. Moreover, system modules cannot have exported variables. That allows us to simplify the requirements for semantically correct translation: A STREAMS module can be generated from a single body definition from a complete Estelle specification, when the body’s header is labeled 1

The timeout() function is a request for STREAMS scheduler to call a (given in a parameter) callback function in the module after a specified amount of time. See [2].

UNIX STREAMS Generation from a Formal Specification

5

system and it has exactly two non-array interaction points with individual queues. When an Estelle module meets the above constraint, we can translate all elements from its body definition into STREAMS module code. The following subsections describe these elements and tell how they should be translated. Dynamic Module Creation Since there are no restrictions on the internals of a STREAMS module, it can implement a model of dynamic hierarchy of Estelle modules. This means that one STREAMS module can represent a whole subtree of Estelle modules. Usually, the more complex specification structure is, the less efficient implementation is. A dynamic structure causes some system overhead for memory allocation/deallocation. That is why a dynamic module hierarchy should be very carefully implemented in order to achieve desired efficiency. Messages The only module in the Estelle hierarchy that can communicate with “external world” is a system module. It has two external interaction points, which will be mapped into STREAMS queues. It means that a STREAMS message received by the generated STREAMS module (called e-module further in this paper) will be passed to EFSM engine of the system module. An interaction outputted via an external interaction point of this module will be translated into STREAMS message and sent into the stream. Such message will need to have a special, recognizable structure, so it can be understood by other e-modules. These messages are called e-messages further in this paper. Interactions that are exchanged between Estelle modules within the module hierarchy will not be translated into STREAMS messages at any point. They should be implemented as some C structures used only by the EFSM engine. Thus possible Estelle “attachments” that join external interaction points between a child and his parent module should be implemented as C structures without involving any STREAMS mechanisms. EFSM There should be some common EFSM engine code for all e-modules. Within one e-module, the engine must have two versions: one for the topmost system module, sending STREAMS messages, and one for the children modules that do not communicate with external entities. The engine should keep track of current states of all modules. A STREAMS module, and thus the EFSM engine, can run only when it receives a STREAMS message or a timeout() callback function has been called by the STREAMS scheduler. While it is not a problem for the engine of the system module, the engines of children modules can be triggered only when the

6

Pawe´´l Rychwalski and Jacek Wytr bowicz

system module gives them control. The following algorithm, which works the same way for e-messages received from lower as from upper layers, is the best way to solve this problem: 1. The topmost module receives an interaction in an e-message or a timeout() callback is run (for delayed transition). 2. The topmost module runs its transitions until there is no fireable one, which may include firing some spontaneous transitions. All messages are queued in appropriate places: the messages to external modules in a special buffer, the messages to children modules in their queues. 3. Other modules in the hierarchy run their transitions, until there is no fireable one left: all automatons wait for an interaction, or there are delayed transitions. 4. STREAMS messages buffered earlier in the topmost module are sent into the stream (via putnext(), or putq()) and so the control is passed to another STREAMS module. All Pascal code elements, like type definitions, constants, functions, etc. should be translated into appropriate C-language constructs. Module variables should be stored in the e-module’s private data structure. There is a special place for pointer to such a data in STREAMS module structures. Module Attributes An Estelle module that should be implemented as STREAMS module has to be asynchronous to the others. Hence it should be attributed as system. If that Estelle module has any children modules, they can be attributed without any restriction. The EFSM engine of the parent module is responsible for a correct synchronization of children’s EFSM engines. Nondeterminism Nondeterminism is used to define a class of acceptable behaviors, or to express nondeterministic behavior of an actor or an environment external to designed protocol. Thus we can remove nondeterminism during implementation. Any efficient deterministic behavior of an e-module satisfies the corresponding Estelle specification. Protocol Layers It is virtue that a specification language can express many different kinds of implementation or ideas. It is useful for documentation or analysis purposes. Although, no one expects nor needs, that a given implementation technique could be used to implement any abstract specification. Ritchie has conceived STREAMS for efficient protocol implementation on the base of the OSI ISO model. Thus a specification that respects this model can be easily translated into STREAMS implementation.

UNIX STREAMS Generation from a Formal Specification

7

We know many Estelle specifications, which were written by our colleagues by ourselves or by others. Frequently there are modules that do as an unreliable medium, a protocol user, an observer. A designer writes them for validation and verification purposes. For that reason we argue that the designer should explicitly point which module represents a protocol to be implemented. We can also notice that designers specify co-working protocols separately and analyze them independently. The reason is simple - their conceptualization does not have to go in the same time. A single generator run should translate one Estelle module body definition into one STREAMS module. The generated module has a well-defined STREAMS interface (e-messages), so it can exchange data with other modules and applications, which should understand these messages. Results of few subsequent generations (that can for example represent different layers of protocol) can be put in a single stream. The source body definitions may be defined in one Estelle file, but they don’t have to. A generator should analyze just the indicated body definition and its contents, and should pay no attention to the initializing code at higher level. Figure 1 demonstrates how modules from a single Estelle specification can be mapped into STREAMS modules. Note that there is no need to split the specification before generating source code for STREAMS.

Estelle specification

Stream Application

User space

Stream head

Kernel space

User substitute

Protocol layer N

E-module N

Protocol layer N-1

E-module N-1

Medium substitute

Driver

Fig. 1. Translation of multiple protocol layers

8

Pawe´´l Rychwalski and Jacek Wytr bowicz

4

Generator for Linux

The target platform for our generator is the Linux system. We have selected it due to the openness of its source code and the possibility to exercise on system level. Unfortunately there is no STREAMS subsystem in Linux kernel. We have selected a freeware Linux STREAMS library, which is not yet complete. [11] We have based the generator on EDT - Estelle Development ToolSet [12], as it is the only environment for Estelle that has support and maintenance. We have taken advantage from the EDT compiler - ec. Ec generates an intermediate form [13] from Estelle text, which we use as input for the generator. Thanks to it, we have neither to parse an Estelle text nor to check its syntactic correctness. This chapter gives some insights into implementation of our generator. 4.1

Additional Constraints

To get first results, and to analyze the feasibility of the Estelle -> STREAMS generation rather than focus on full implementation, we have added the following constraints for input Estelle specification (in addition to these mentioned in previous chapter): 1. The source module body definition cannot have any internal interaction points nor children modules. 2. There are two restricted statements: any and forone 3. exist factor in expression is not accepted. 4. Nested Pascal functions are not accepted. All of these constraints can be relaxed in the next version of the generator. Translation of the above constructors into C code is laborious and time consuming but feasible. For example the generator from EDT that uses BSD sockets processes all of them. A collaboration with EDT providers would allow to reuse the Estelle compiler code to rapidly relax the mentioned constraints. 4.2

STREAMS Interface

With the first condition met, there is no need to implement any internal engine handling interaction-passing between children modules. Thus all of the interactions sent and received by the Estelle module can be translated directly into e-messages. An e-message in our generator is a STREAMS message of M PROTO2 type. This message has normal priority. The first 4 bytes of its data block contain a unique magic number, so it can be identified by other e-modules. The rest of the data block contains e-message type and the interaction data: its name and its parameters, as presented on Fig. 2. There are two e-message types: E INTER for interaction data, and E ERROR for error notifications. 2

Messages carrying protocol control information.

UNIX STREAMS Generation from a Formal Specification

0x15efe92 E_INTER

e_sender

9

i_name_offset i_name_length i_param_offset i_param_length

NAME

PARAMETERS

Fig. 2. E-message structure

The e-messages are recognized by their name. The designer has to keep that in mind when joining e-modules generated from different Estelle specifications into a single stream. He should make sure that Estelle modules that will be connected with each other should have the same channel definitions. The application (user-level process that uses the stream) should understand e-messages of the topmost e-module in the stream, i.e., it should know interaction names of the highest level protocol specification. The driver (lowest module in a stream) should understand e-messages from the lowest layer of protocol. However, this is rather not the case, because drivers cannot be generated directly from Estelle specifications and usually have their own interfaces. Because of this, we need a special “translating” module, which will accept e-messages and output driver-interface messages on its write side, and do the opposite on its read side3 . In our generator, such a module translates e-messages into DLPI [14], which is used by the Linux STREAMS [11] driver, ldl. 4.3

Generated Module Structure

A STREAMS module generated from an Estelle specification consists of three parts: The module skeleton contains all standard STREAMS module code (put(), service() functions, M FLUSH message handling, etc.). The module entry points (put and service) call the functions from the other parts of the module. The skeleton is common for all e-modules. The only thing that changes in it is the module’s name. Automaton engine is common for all e-modules and is included in their code. This set of functions is responsible for detecting, processing and sending emessages. It also handles delay clauses from Estelle transitions and of course keeps track of current automaton state. 3

The “write” side of a STREAMS module sends messages downstream, from application to the driver, while the “read” side sends messages upstream, from the driver to the application. See [2].

10

Pawe´´l Rychwalski and Jacek Wytr bowicz

Automaton body is a set of C functions that contain translated Estelle code from input file: functions and procedures, type and constant definitions, transition bodies. It also includes some data structures describing the e-module. The following steps describe the way an e-module works. Algorithm is the same for messages going up and down the stream. 1. A STREAMS message is received. 2. The message’s magic number is checked. If it’s not an e-message, it’s processed by the module skeleton code as a standard STREAMS message (usually passed further). 3. The interaction name is checked. If it’s not known by the current module, an error notification message is generated upstream, to the application. 4. The interaction’s parameters are validated. If they are not valid, an error message is generated. 5. On a base of a transition select table it is chosen a transition to be fired. 6. The transition’s body is run. All generated interactions are translated into STREAMS messages and stored in a temporary buffer. 7. A check is made for spontaneous transitions going out from current state recursion to point 5. 8. A check is made for delayed transitions going out from current state. If there are any, STREAMS timeout() call is issued. 9. All messages in temporary buffer are sent into the stream. The automaton data contains a structure called transition select table. It is a two-dimensional C array, where the first dimension is the current automaton state, and the second dimension is the interaction number, determined by an interaction name. A special interaction number is defined for no interaction, i.e. for spontaneous transitions. Each element of the array is a list of transitions, sorted by priority (descending). Upon receiving an interaction, an appropriate list is searched, from highest to lowest priority. The first transition that has its provided clause met is being run. In this way we lose the non-determinism of the Estelle semantics, but still we assure that the transition with highest priority is fired. Delay clauses are implemented with the use of STREAMS timeout() function, as described in chapter 2. If the automaton’s state changes before the timeout callback is done, the timeout is canceled.

5

Efficiency Tests

We have performed some efficiency tests to see how generated STREAMS modules work. First test was made on Linux system, and its aim was to see how the number of modules in the stream (in other words, number of protocol layers) influences the overall performance of an application. Because its results were not as good as we have expected, we have carried on our tests on Solaris operating system, where STREAMS are an internal part of the kernel. These tests were aimed at comparing the efficiency of a generated module to the efficiency of a hand-written module with the same functionality.

UNIX STREAMS Generation from a Formal Specification

11

Table 1. Measured transfer rate in KB/s - Linux Stream structure loopback Ethernet ldl, simple application 875 852 ldl -e2ldlmod, simple application 760 844 ldl -e2ldlmod-namesrv, simple application 665 616 ldl -e2ldlmod-namesrv, complex application 525 383 ldl -e2ldlmod-namesrv-resp, simple application 576 186 ldl -e2ldlmod-namesrv-resp, complex application 490 158

5.1

Linux Tests

On Linux system, we have measured average transfer rate of datagrams, each of 100 bytes size, using loopback and 10Mbit Ethernet link between 2 computers. The first one with Pentium III 550 MHz, 128 MB RAM, works under Linux RedHat 8.0. The second with Pentium 166 MHz, 64 MB RAM, with Linux RedHat 7.1. The aim of the tests was to see how including a module into a stream influences the transfer rate, assuming that only the communication mechanism is considered, not any significant protocol processing. Thus we have written two simple Estelle specifications. The first (lower layer) was a “name service” protocol, translating LLC network addresses into logical addresses, and the upper layer was responsible for responding to received packets. To take measures we have built six configurations of a stream, and have run the test for loopback and Ethernet connection. Table 1 contains acquired results. In every configuration we have used the default LiS network driver, ldl. Between the driver and the lower e-module we have inserted a translation module, e2ldlmod. This separate STREAMS module translates e-messages into DLPI and vice-versa. It comes with the generator package, and cannot be integrated with generated modules in current version of the generator. To control the stream, we have used two kinds of applications. The first was a simple single-threaded program that sent and/or received e-messages in a loop. The second one was multi-threaded and provided a handy API for handling the e-messages. The transfer rates are low (compared to possible Ethernet transfer) because of the small packet size. The results show that the loss of efficiency from adding a new STREAMS module is about 10-20%. Lower efficiency of complex application was caused by the need of rewriting the data and storing it in temporary buffers to provide the required API. 5.2

Solaris Tests

For tests on Solaris, we have used two machines: 1. AMD Athlon 2,0 GHz, 392 MB of 333 MHz DDR RAM, 2,5 GB Samsung IDE Hard Drive, Realtek 8139 based 10/100Mbit Network Adapter

12

Pawe´´l Rychwalski and Jacek Wytr bowicz

2. AMD K5-2 350 MHz, 64 MB PC100 RAM, 2,1 GB Samsung IDE Hard Drive, Realtek 8139 based 10/100Mbit Network Adapter For networking we have used Fast Ethernet with 10/100Mb switch (Surecom EP-805X-R, 5 port). The tested specification was a simple echo protocol, serving as both echo client and echo server: packets incoming from upper layer were flagged as “echo request” and sent to lower layer, while packets coming from lower layer and flagged as “echo request” were sent back with the flag changed to “echo response”. Packets coming from lower layer and flagged as “echo response” were forwarded (with removal of the flag) to the upper layer. As we have already mentioned, tests were performed on an automatically generated e-module and on a hand-written module with the same functionality. The generated e-module had to have the translating module, e2ldlmod, inserted into the stream as well. The purpose of this module was explained earlier for Linux tests. The result of the test was an average file transfer rate between two machines. All results are presented in Table 2. Tests were made for two hardware configurations and with 3 different data packet sizes. Presented results show the difference between manual and automated implementation. It is dependant on the packet size: the bigger the packet, the smaller relative performance loss. For 100-byte packet the generated module was about 20% slower than the manually written one, while for 800-byte packet it was only 10% slower. The difference between both implementations is shown on Fig. 3. Further increasing of the packet size may reduce the loss of performance even more. The generated echo protocol consisted of two modules, one that performs the protocol (generated from Estelle specification) and one for translating messages from one STREAMS interface to another. Future versions of the generator may avoid this by integrating the translating functionality into the generated module, which should improve the performance of generated modules. Table 2. Measured transfer rate in KB/s - Solaris

Hardware configuration Machine 1 -> Machine 2 Machine 1 -> Machine 2 Machine 2 -> Machine 1 Machine 2 -> Machine 1 Average Average

Data transfer rate (kB/s) Echo module 100B packet 200B packet 800B packet Generated 1085 1771 3197 Manually written 1446 2210 3630 Generated 806 1377 2722 Manually written 1028 1725 3032 Generated 945 1574 2960 Manually written 1237 1968 3331

UNIX STREAMS Generation from a Formal Specification

13

Average data transfer rate [KBytes/s]

Average data transfer rate of generated and manually written modules as a function of the packet size 4000 3000 Serie1

2000

Serie2

1000 0

100

200

800

Serie1

945

1574

2960

Serie2

1237

1968

3331

Packet size [bytes]

Fig. 3. Difference in transfer rate between generated (Serie 1) and manually-written (Serie 2) modules

6

Conclusions

The usual problem with automatic generation is the effectiveness of the output code. Most of existing generators produce programs that are significantly less effective than hand-written code. Moreover STREAMS implementations, that are the most commonly used technique in commercial Unix systems, are not addressed by these generators. This fact greatly reduces the usage of existing generators, and formal specification is mostly used only for documentation and validation purposes. The main idea of our work was to check the feasibility of STREAMS module generation. The obvious advantage of the Estelle -> STREAMS generator is the simplification in design of rapid and correct implementation, taking advantage from formal specification and validation techniques. The created tool demonstrates that the automatic STREAMS module generation from an EFSM description is possible. However a designer has to keep in mind this kind of implementation during the development of the specification. We have defined constraints that he should preserve. The results of the performed tests demonstrate that further work should be done to obtain desired functionality and efficiency. First of all the assumed constraints (defined in chapter 4.1) should be relaxed. Secondly our tool should be optimized and enhanced. The enhancements could provide some guidance about cooperation with existing and STREAMS modules.

14

Pawe´´l Rychwalski and Jacek Wytr bowicz

Whenever automatic generation of a STREAMS module is performed or not we argue that modeling and verification of the module functionality has to be performed in order to build a correct communication system. Acknowledgment We would like to thank Mr Marek J´ o´zwik for his help in realization of efficiency tests, especially those performed on Solaris platform.

References 1. Ritchie, D.: A stream input-output system. AT&T Bell Laboratories Technical Journal (1984) 63, 8 Part 2, s.1897-1910. 2. Sun Microsystems, Inc.: Solaris AnswerBook: STREAMS Programming guide. (1998) 3. O. Catrina, A.: On the improvement of the estelle based automatic implementations. (1998) in: S. Budkowski, A, Cavalli, E. Najm (Edts.), Formal Description Techniques (XI) and Protocol Specification, Testing and Verification (XVIII) [FORTE / PSTV], Kluwer Academic Publishers, Paris - France, pp 371-386. 4. Thees, J.: Protocol implementation with estelle - from prototype to efficient implementations. (1998) in: S. Budkowski, S. Fischer, R. Gotzhein: Proc. of the 1st International Workshop of the Formal Description Technique Estelle (ESTELLE’98), Evry, France,. 5. Bredereke, J.: Specification style and efficiency in estelle. (1998) in: S. Budkowski, S. Fischer, R. Gotzhein: Proc. of the 1st International Workshop of the Formal Description Technique Estelle (ESTELLE’98), Evry, France,. 6. Gotzhein, R., et al.: Improving the efficiency of automated protocol implementation using estelle. Interner bericht nr 274/1995 (1995) Fachbereich Informatik, Univeristat Kaiserscautern. 7. Langend¨ orfer, P., K¨ onig, H.: Improving the efficiency of automatically generated code by using implementation-specific annotations. (1997) Participants proceedings of the 3rd International Workshop on High Performance Protocol Architectures. HIPPARCH’97, Sweden. 8. R. Henke, H. K¨ onig, A.M.T.: Derivation of efficient implementations from sdl specifications employing data referencing, integrated packet framing and activity threads. (1998) in: proceedings of Eighth SDL Forum, North-Holland. 9. Henke, R., Mitschele-Thiel, A., K¨ onig, H.: On the influence of semantic constraints on the code generation from estelle specifications. FORTE/PSTV Osaka (1997) 10. ISO/TC97/SC21: Estelle: A Formal Description Techinque Based on an Extended State Transition Model. (1997) ISO 9074. 11. Gcom, Inc.: Linux STREAMS home page. (2002) ¡http://www.gcom.com/LiS¿. 12. S.Budkowski, et al.: The Estelle Development Toolset. Institut National des Telecommunications, Evry, France. (1998) ¡http://www-lor.int-evry.fr/edt¿. 13. Moraly, R.: Intermediate form utilization principles. INT. (1998) Document is available to download on the EDT distribution page. 14. Unix International: Data Link Provider Interface version 2.0.0. (1991)

Specifying and Realising Interactive Voice Services Kenneth J. Turner Computing Science and Mathematics, University of Stirling, Scotland FK9 4LA, [email protected]

Abstract. VoiceXML (Voice Extended Markup Language) has become a major force in interactive voice services. However current approaches to creating VoiceXML services are rather low-level. Graphical representations of VoiceXML are close to the textual form of the language, and do not give a high-level description of a service. Cress (Chisel Representation Employing Systematic Specification) can be used to give a more abstract, language-independent view of interactive voice services. Cress is automatically compiled into VoiceXML for implementation, and into Lotos (Language Of Temporal Ordering Specification) or SDL (Specification and Description Language) for automated analysis. The paper explains how Cress is translated into VoiceXML and Lotos.

1 1.1

Introduction Motivation

This paper explains how to represent, specify and analyse IVR (Interactive Voice Response) services. VoiceXML (Voice Extended Markup Language [13]) is typically used to implement automated telephone enquiry systems. VoiceXML is much more acceptable to users than the early generation of touch-tone systems. Specifically, VoiceXML allows users to do what they expect in a telephone call: talk and listen. VoiceXML can be linked to databases, telephone networks and web servers. As a result, VoiceXML is very useful for those who cannot directly access such information. A user on the move, for example, is likely to have a mobile telephone but limited web access. A partially sighted or physically handicapped user could find web-based services difficult or impossible to use. Many households still do not have web access. Being an application of XML, VoiceXML is textual in form. However several commercial packages (e.g. Covigo Studio, Nuance V-Builder, Voxeo Designer) provide a graphical representation. Some of these reflect the hierarchical structure of VoiceXML, while others emphasise the relationship among VoiceXML elements. These packages are (not surprisingly) very close to VoiceXML and do not give a clear overview of interactive voice services. In the author’s opinion, existing graphical formats are ‘window dressing’ that do little to clarify the structure and flow of VoiceXML scripts. It is easy, even common, to write VoiceXML scripts whose flow of control is obscure and hard to follow. Indeed, VoiceXML can suffer from the ‘spaghetti code’ (tangled logic) that structured programming was devised to avoid. VoiceXML adopts a pragmatic and programmatic approach. There is no way to formally check or analyse a VoiceXML script. In telephony, services are often composed from self-contained features. A feature is an additional function that is triggered automatically (e.g. call forwarding or call H. K¨onig, M. Heiner, and A. Wolisz (Eds.): FORTE 2003, LNCS 2767, pp. 15–30, 2003. c IFIP International Federation for Information Processing 2003


16

Kenneth J. Turner

screening). Because a feature is triggered and not explicitly called, it readily adds supplementary capabilities. The value of features has been amply demonstrated in the IN (Intelligent Network). VoiceXML does not have features (though it has subdialogues). In fact, VoiceXML does not directly recognise the concept of a service. It is therefore be useful to enhance VoiceXML with mechanisms for services and features. The author’s approach to defining and analysing services is a graphical notation called Cress (Chisel Representation Employing Systematic Specification). Cress was initially based on the industrial Chisel notation developed by BellCore [1]. However, Cress has considerably advanced from its beginnings. The aim of using Cress with VoiceXML is to define key aspects of interactive voice services. The advantages of Cress over using VoiceXML directly are: – VoiceXML is very close to implementation. However Cress services are represented at a more abstract level, making it easier to grasp their essence. For the same reason Cress diagrams can be translated into a number of target languages, of which VoiceXML is just one. – There is no formal definition of VoiceXML. Some concepts in VoiceXML are only vaguely described (e.g. event handling) and some are defined loosely (e.g. the semantics of expressions and variables). As a result, it is impossible to say for certain what certain VoiceXML constructs mean. At times the author has had to resort a commercial VoiceXML implementation to discover what some constructs might mean. Even then, the commercial solution has been seen to behave implausibly. Through translation to a formal language, Cress contributes to a more precise understanding of VoiceXML. – A large VoiceXML application typically has many documents with many parts. It can be difficult to check whether the application is self-consistent, e.g. will not loop indefinitely or end prematurely. VoiceXML development in practice uses manual debugging. Cress gives the immediate benefit of translation to a formal language: Lotos (Language of Temporal Ordering Specification) and SDL (Specification and Description Language). The resulting specification can be rigorously analysed. 1.2

Relationship to Other Work

Several graphical representations have been used to describe communications services. SDL is the main formal language used in communications. Although it has a graphical form, SDL is a general-purpose language that was not designed particularly to represent communications services. MSCs (Message Sequence Charts) are higher-level and more straightforward in their representation of services. UCMs (Use Case Maps [2]) have been used to describe communications services graphically. However none of these approaches is domain-specific, and they cannot be translated into a range of languages. In comparison to Cress, SDL for example does not have specialised support for a domain like interactive voice services. As a result the equivalent SDL specification is larger and more complex. The only formal analysis possible is whatever SDL offers (mainly state space exploration). With Cress an SDL-based analysis remains possible, different kinds of analysis can be achieved through Lotos, and VoiceXML scripts can be obtained automatically from the same diagrams. See for example [4, 9] for a comparison of Cress and SDL descriptions of SIP (Session Initiation Protocol).

Specifying and Realising Interactive Voice Services

17

As noted earlier, there are a number of commercial tools for VoiceXML. These offer more complete VoiceXML coverage than Cress, and provide proprietary extensions for commercial deployment. However they are focused on VoiceXML only, and do not offer any kind of formal analysis. Their (graphical) representations are too close to VoiceXML for abstract service descriptions that are comprehensible to non-specialists. Although Cress has origins in communications services, it is not tied to these. Cress has plug-in domains that define the service vocabulary in a separate and modular fashion. Cress has already been proven with services for the IN (Intelligent Network) [8] and SIP (Session Initiation Protocol) [9, 11]. The work reported in the present paper shows how Cress can be used with VoiceXML. Cress is a front-end for defining and formalising services. Cress is neutral with respect to the target language. The translation of Cress into Lotos or SDL gives formal meaning to services defined in Cress. This formalisation provides access to any analytic technique using these languages. Among these, the author’s own approach [7] is one of several. For implementation, Cress can also be compiled as appropriate into SIP CGI (Common Gateway Interface, realised in Perl), partly into SIP CPL (Call Processing Language), and also into VoiceXML. A key issue in telephony is feature interaction [3] – independently designed features can interfere with each other. This issue is well known from traditional telephony and the IN, but also arises with SIP services. The feature interaction literature is too large to review here; see, for example, the proceedings of FIW (Feature Interaction Workshop). Although VoiceXML does not recognise the concept of service or feature, it has been shown that feature interactions can also arise with VoiceXML [11]. 1.3

Overview of the Paper

The new contribution made by this paper is the application of Cress to IVR services. The paper discusses how IVR services and features can be described in Cress, and explains how they are translated into VoiceXML and Lotos. Cress can also be translated into SDL, as outlined in [10]. As background, section 2 summarises the Cress graphical notation insofar as it applies to interactive voice services. Examples of Cress diagrams appear later, and Cress is further discussed in [8, 9, 11]. Section 3 introduces VoiceXML and its representation in Cress. It will be seen how Cress diagrams for interactive voice services are translated into VoiceXML. Section 4 discusses how the same diagrams are translated into Lotos. This allows a variety of formal analyses to be carried out of a service before it is developed and deployed using VoiceXML.

2

The Cress Notation

At first sight, it might seem that Cress is just another way of drawing state diagrams. However it differs in a number of important respects. State is intentionally implicit in Cress because this allows more abstract descriptions to be given. Arcs between states may be guarded by event conditions as well as value conditions. Perhaps most importantly, Cress has explicit support for defining and composing features. Cress also has plug-in vocabularies that adapt it for different application domains. These allow Cress diagrams to be thoroughly checked for syntactic and static semantic correctness.

18

2.1

Kenneth J. Turner

Diagram Elements

Ultimately, Cress deals with a single diagram. However it is convenient to construct diagrams from smaller pieces. A multi-page diagram, for example, is linked through connectors. More usefully, features are defined in separate diagrams that are automatically included by either cut-and-paste or by triggering. A Cress diagram is a directed, possibly cyclic graph. If the graph is cyclic, it may not be possible to determine the initial node uniquely. In such a case, an explicit Start node is given. Comments may take several forms: text between parallel lines, hyperlinks to files, and audio commentary. Nodes in a diagram (shown as ovals) contain events and their parameters (e.g. Submit order.jsp

weight product

). A node is identified by a number followed optionally by a symbol to indicate its kind. For example, the first node of a template feature is marked ‘+’ if it is appended to the triggering node, or ‘–’ if it is prefixed. Events may be signals (input or output messages) or actions (like programming language statements). A NoEvent (or empty) node can be used to connect other nodes. An event may be followed by assignments separated by ‘/’ (e.g. / timeout <− 2). The arcs between nodes may be labelled by guards. These may be either value conditions (imposing a restriction on the behaviour) or event conditions (that are activated by dynamic occurrence of an event). Event handlers are distinguished by their names (e.g. NoInput, triggered when the user does not respond to a VoiceXML prompt). A Cress diagram may contain a rule box (a rounded rectangle) that defines general rules and configuration information. A rule box typically declares the types of diagram variables (e.g. Uses Value product, weight). A rule box may define configuration information like parent diagrams, chosen features and translator options. Rule boxes have yet other uses [8, 9, 11] that are not so applicable to interactive voice services. The main Cress diagram defines the root behaviour. Although this may be the only diagram, Cress supports feature diagrams that modify the root diagram (or other features). A spliced (plug-in) feature is inserted into a root diagram by cut-and-paste. The feature indicates how it is linked into the original diagram by giving the insertion point and how it flows back into the root diagram. This style of feature is appropriate for a one-off change to the original diagram. It is often preferable to use a template (macro) feature that is triggered by some event in the root diagram. The triggering event is given in the first node of the feature. Feature execution stops on reaching a Finish (or empty) node. At this point, behaviour resumes from the triggering node in the original diagram. A template feature is statically instantiated using the parameters of the triggering event. The instantiated feature may be appended, prefixed or substituted for the triggering node. 2.2

Automated Support

Cress usually relies on a domain-specific infrastructure. For example, IVR services often require a speech synthesiser and a speech recogniser that cooperate with the main application. Such a framework is specified using the same target language as the one to which diagrams are compiled (e.g. Lotos, SDL, VoiceXML). Although the framework is specific to a domain and a target language, it is independent of the particular services or features deployed. The framework includes macro calls that activate the Cress pre-

Specifying and Realising Interactive Voice Services

19

processor. This automatically generates configuration-specific information such as the translated diagrams and feature-dependent data types. The Cress toolset has the form of a conventional compiler but is unusual in some respects. For portability it is written in Perl, comprising about 13,000 lines of code. The Cress toolset consists of five main tools. Including test scenarios, there are about 600 supporting files for all domains and target languages. Internally the Cress toolset consists of a preprocessor (that instantiates the specification framework), a lexical analyser (that deals with various diagram formats), a parser (that performs syntactic analysis), and several code generators (e.g. for Lotos, SDL and VoiceXML). Although it might have been desirable to use a parser generator (e.g. Antlr), parsing is only a small part of what Cress has to do. A traditional compiler deals with textual languages. Cress, however, deals with a graphical language. This creates interesting challenges, e.g. compiling cyclic rather than hierarchical constructs.

3 3.1

Interactive Voice Services in VoiceXML Introduction to VoiceXML

VoiceXML [13] derives from earlier work on scripting languages for interactive voice services. VoiceXML is a mixture of the declarative and the imperative, the event-driven and the sequential. VoiceXML is a large language embedded in an even larger framework. For example, VoiceXML includes EcmaScript (JavaScript). It also supports complex grammars for speech synthesis and speech recognition. VoiceXML is integrated with other technologies such as database access and web servers. VoiceXML lacks the telephony concept of a feature as behaviour that may be triggered by some condition. The nearest equivalent in VoiceXML is a subdialogue (resembling a subroutine). Subdialogues are executed in an independent interpreter context, making it difficult to share certain information. In VoiceXML, at best some code can be explicitly invoked as a ‘feature’; automatic feature invocation is not supported. Triggered features have proven their worth in telephony and are supported by Cress. The VoiceXML caller completes fields in forms (or menus) by speaking in response to prompts. Each field is associated with a variable that is set to the user’s input. VoiceXML applications are often written as a number of documents containing a number of forms, each containing a number of fields. This is the most natural form of modularity in VoiceXML. However this can easily hide the flow between the forms and fields. TTS (Text-To-Speech) may be used to speak messages. Text may be marked up to indicate how certain words are pronounced, and generally to define the speech pattern. However TTS is only approximation of natural speech, so VoiceXML allows prerecorded voice to be used in preference. Speech recognition is used to extract digital data from user input. This is guided by a speech grammar, for which there are several standards. Numeric inputs (including menu choices and yes/no) can also be provided using DTMF (Dual Tone Multi-Frequency), i.e. dialling digits on a touch-tone telephone. Cress supports the standard VoiceXML grammars: Boolean (optionally defining DTMF digits for yes/no), Currency, Date, Digits (optionally defining expected length, or minimum/maximum lengths), Number, Phone (with optional extension) and Time (12/24 hour clock).

20

Kenneth J. Turner

Some VoiceXML actions may be governed by a count or a condition on when the action is permitted. For example a different prompt may be given on the third input attempt, or a field may be selected only when some condition is true. Actions may have optional parameters (e.g. a sound file or fetch timeout) that are relevant to a VoiceXML platform but not directly useful for Cress. Although these may appear in a Cress diagram, they are used only when translating into VoiceXML. For other target languages these optional parameters are ignored. The types supported by Cress are domain-specific. For VoiceXML there is just a single type, Value, since the underlying EcmaScript has dynamic types. Actual values can be booleans, numbers or strings. In addition there are null and undefined values. VoiceXML supports a fairly complex hierarchical event model. Event handlers may be defined at four levels: platform, application, form, field. Platform handlers provide fall-back support, though they are rarely useful. Application handlers oversee all forms in an application. Form handlers allow their fields to share common event handling. Finally, fields usually define handlers for events of specific interest. A script may an event, transferring control a matching handler. Standard events include: Cancel, Exit, Help: the user asked to cancel processing, to exit, or to get guidance Catch: deals with a list of events Error: a run-time error occurred Filled, NoInput, NoMatch: the user spoke correct input, nothing, or invalid input. Although VoiceXML does not consider Filled to be an event, it behaves like one. Besides standard events, programmer-defined events may be constructed from several parts (e.g. login.failure.password). Normally this would be caught by a handler for the same name. But if there is nothing to match, a handler for login.failure (or failing that login) may deal with the event. If no handler matches, the application terminates. Events are also implicitly associated with a prompt count. Each time a field is entered, its prompt count is incremented. This may be used vary the response to an event. In fact this is more complex than it seems. Suppose event handlers are defined for counts 1 (the default), 2 and 4. The first is activated on count 1, the second on counts 2 or 3, and the last on count 4 or higher. A condition may also be imposed on an event handler being activated. This is relevant if several handlers could otherwise apply. VoiceXML does not define what happens if conditions overlap – in fact the behaviour is non-deterministic. 3.2

Cress for VoiceXML

In principle, VoiceXML has elements at platform, application, form and field levels. VoiceXML can also be split over a number of documents. However a VoiceXML application can be defined as a single document with a single form, and this is how it is regarded in Cress; in fact, application and form level are the same in Cress. Fields can be defined as separate sections or pages of a Cress diagram, using connectors to join them. For a large application this is convenient and more modular. However for a small application it is sufficient to represent the form as a single integrated whole. In addition, splitting fields makes the flow between them less obvious. For these reasons, fields are deliberately not prominent in Cress.

Specifying and Realising Interactive Voice Services

21

Cress is not a literal graphical rendering of VoiceXML structure. This would be pointless since most commercial tools for VoiceXML do this anyway. The flow of control in Cress can be more visible; in VoiceXML it can be hard to determine. The flow is sometimes implicit (e.g. transitioning to the next field on completion of the current one) and sometimes buried (e.g. an embedded ). Cress supports cyclic behaviour as loops in a diagram; these have to be coded indirectly in VoiceXML. Cress expects to have a definition of root behaviour as the core of a service. In VoiceXML, an application root document serves a similar purpose but is very restrictive. It may contain only variables, event handlers and elementary definitions that are common to the documents of a VoiceXML application. It is not feasible for Cress to support the entirety of VoiceXML, EcmaScript, speech synthesis markup, speech grammars, database access and web access. Instead, Cress concentrates on the essential aspects of VoiceXML control. Limited support is provided for EcmaScript – specifically for numerical, string and logical expressions. The following summarises the main elements of Cress for interactive voice services. Unless stated, the VoiceXML equivalent is very similar (e.g. Audio in Cress corresponds to