an open animation tool: application to telecommunication systems

An open animation tool: applicationto telecommunication systems

Pierre Combes *, Fabrice Dubois, B�eeatrice Renard

France Telecom––BD FTR&D DTL, 38, rue du G�een�eeral Leclerc, 92794, Issy-les-Moulineaux Cedex 9, France

Abstract

This paper presents an animation environment based on an open and flexible architecture. Its flexible architecture

allows animating different animation sources (formal and executable language like SDL or scenario languages like MSC

or UML sequence diagrams). The animation multimedia user interface allows integrating different multimedia objects

and different types of representations.

This animation environment has been intensively used for telecommunication applications at different levels of a

service and network architecture: service animation from the user�s point of view or from the service logic point of view

(service logic and service feature logics), protocols and application programming interface (such as OSA/PARLAY)

animation, service interaction analysis. Animation helps obtaining a comprehensive and user-friendly interface for

education, and investigation of system behaviour from different points of view, in particular from a client point of view.

Specifically applied to formal executable models (using SDL, for example), the tool helps checking properties of the

system behaviour, and showing whether it really fulfils user expectations.

� 2002 Published by Elsevier Science B.V.

Keywords: Animation; Prototyping; Service validation; Protocols; System design; SDL; UML; MSC

1. Introduction

Telecommunication systems aim at providing sophisticated services that influence our daily life. Suchservices are deployed on very complex distributed and open architectures, constituted with heterogeneous

platforms and protocols. These systems are also dynamic with continuous integration of new platforms or

protocols and continuous deployment of new services.

Such complexity involves the use of efficient system development processes, from requirement capture to

design, implementation and testing. The use of appropriate standard formalisms, from MSC or UML

sequence diagrams to more formal and complete models (using formal description techniques such as SDL

* Corresponding author.

E-mail addresses: [email protected], [email protected] (P. Combes), fabrice.dubois@france-

telecom.com (F. Dubois), [email protected] (B. Renard).

1389-1286/02/$ - see front matter � 2002 Published by Elsevier Science B.V.

PII: S1389-1286 (02 )00354-7

Computer Networks 40 (2002) 599–620

www.elsevier.com/locate/comnet

mail to: [email protected],

or LOTOS), is recommended in order to ensure the consistency of the specified system, particularly with

respect to the behaviour of its components. For a telecommunication system, a component usually is a

telecommunication service, a service component, a protocol (and the different layers of a protocol) or an

application programming interface (API such as PARLAY/OSA [17]). Each of these components should be

carefully validated to formally verify correctness but also to ensure that they really fulfil expectations. The

consistency of the interoperability/integration of these components should also be verified for the completesystem (telecommunication service) validation. According to us, a valuable help is provided by semi-formal

and formal techniques to describe system and components and to facilitate the coherency verification. Thus,

UML, MSC or more formal languages such as SDL, LOTOS, and Lustre can be used at different levels of

abstraction. However, one needs also to have a (deep) knowledge of these languages.

Multimedia animation of component and system behaviour is a complementary and unavoidable

technique for requirement validation [1,14,19]. More, telecommunication systems are so complex that,

without the use of animation techniques, the knowledge of a protocol, an application programming in-

terface or a service component will be reserved to specialists of one domain. But, the telecommunicationsystem development process implies that specialists of one domain should have a knowledge of at least

bordering domains: teams working on API should understand the specification of the underlying protocols,

teams working on service creation should understand quickly the behaviours of service components. Here,

animation is not only for validation but also for education, and will be more efficient that reading several

hundred pages of informal text or a SDL model (even a UML model). Animation is also very useful to

demonstrate the behaviour of complex telecommunication services to a client, especially if such an ani-

mation is based on the execution of a formal model.

This paper presents an animation environment, which is adequate to animate different components ofnetwork and service architecture, corresponding to the different layers of the system. This environment is

also open in the sense that it can be used with different source languages such as scenario languages (UML

sequence diagrams or MSC) or formal executable languages (such as SDL). Such flexibility offers the

possibility to use the same animation environment at different steps of a development process.

Section 2 presents the animation environment, the general structure of the tool, and its specific appli-

cation to SDL and MSC.

Section 3 presents different applications of telecommunication systems: protocol and API animation,

service component and complete telecommunication application. A specific application is presented for thehandling of the service interaction problem.

2. ANGOR: an animation environment

2.1. An open tool

2.1.1. A flexible architecture

The animation environment is designed in a modular fashion (see Fig. 1). Basically, it consists of the

three following modules: first, an animation source, which constitutes the specification of the system be-

haviour to be animated. This module can be anything actually (an SDL simulator, an MSC diagram, a

UML use case, etc.), provided an appropriate interface is developed so that events to be animated can be

retrieved by the animation tool. Secondly, the animation engine: this module receives events from the an-

imation source, and its role is to decide how the animation should react to those, i.e., what is to be seen on

the screen. To do so, the animation engine interprets a script––called the animation model––in which

animation events are associated to events related to the source system behaviour. Finally, there�s the ani-

mation graphical user interface, that (dis)plays the animated graphical or audio components, and allows the

600 P. Combes et al. / Computer Networks 40 (2002) 599–620

user to interact with the simulation tool (when such a tool is used as animation source) in order to drive itthrough particular scenarios.

The architecture shown in Fig. 1 can be configured in different ways. In the fully centralized mode, all

three modules run on the same computer. In the semi-distributed mode, the animation engine and source

run on one computer, while the animator GUI executes and appears on a different machine. Lastly, there�sa fully distributed mode, wherein every component executes on a separate machine.

The animation model (or configuration file), which is interpreted by the engine, is specified using an

extended version of the Tcl/Tk [18] scripting language. In that model, the user may specify how items from

his/her system model, such as system variables and system events (e.g., reception of a given message by agiven process of the system, procedure calls, dynamic process creation, etc.) should be animated. Some

predefined components are available for animating or visualizing such items.

2.1.2. Open to various animation sources

The current version of the animation tool is able to animate SDL specifications (being simulated), as well

as scenarios expressed in message sequence charts. In the former case, a connector was developed to make it

possible for the animator to communicate with the ObjectGeode SDL Simulator software bus [10]; in the

latter case, an MSC parser is used. Such connectors should also be developed for other SDL tools as TAU,or the next version of the Telelogic SDL tool.

New connector bundles could be developed the same way for others kinds of animation sources, like

UML diagrams, other formal description techniques or systems in operation.

2.1.3. Customizing animation components

Among the predefined animation components can be found graphical labels, bitmap pictures, arrows,

frames, counters, traffic lights, thermometers, etc., as well as audio files.

Additional components (graphics and sounds) may be defined, by ‘‘encapsulating’’ them in a Java classin order to ease their manipulation. For instance, a graphical object representing a light bulb can appear

switched on or off just by calling its switchOn() or switchOff() methods. This way, powerful

components libraries can be constructed, gathering objects that are controllable from the Tcl/Tk-based

script. This is realized using Jacl [13], which is a Java implementation of the Tcl language. Jacl allows for

extending and interpreting Tcl using the Java programming language.

2.2. The animation language: main concepts

The animation language is an extension of Tcl/Tk. Our goal in this article is obviously not to present the

animation language in detail; we prefer to stick to an overview. Basically, specifying an animation for a

Fig. 1. General architecture of the animation environment.

P. Combes et al. / Computer Networks 40 (2002) 599–620 601

source model consists in defining a set of animation objects called nodes. The purpose of a node is to express

how a given entity of the source model is to be animated: under what conditions, using what aspect, as-

suming what user actions, and so on. Nodes are organized according to a so-called cartography. A car-

tography can be seen as an abstract template used to impose a structure where nodes are integrated.

Currently only one kind of cartography is available: the network cartography, that allows organizing the

animation objects as nodes connected to each other through links. Typically, when animating an SDLmodel, nodes are associated to SDL processes, while links are associated to SDL channels.

From the visual point of view, all the components of an animation appear by default in a single window

called the main map. Submaps can, however, be defined and attached to the main map (or even to other

submaps), so a hierarchy of views/windows can be used to decompose the animation. Finally every node is

concretised in exactly one map of the hierarchy.

An animation model––or script––usually specifies:

• definitions that are global to the whole model, setting of general parameters;• the identification of the animation source;

• the type of cartography to be used;

• the identification of entities of the source to be animated;

• the desired aspect for each animated entity;

• the conditions and nature of animation for each entity;

• (and for interactive sources only) the user actions to interact with the source.

From the above list the three first categories are common to all kinds of animation sources. The rest ofthe list depends on the kind of source.

Animation nodes are defined as classes, from which multiple instances may be created.

A node class definition contains:

• The rules according to which instances of the node class are created. These rules depend on the kind of

source to animate: for instance, the rules for animating an SDL model could relate to the birth and death

of the SDL processes.

• The rules stating how the node should be presented, concretely: appearance of a set of icons, labels, orany other kind of animation component; setting of initial values for components properties; assignment

of a map (i.e., a window to appear in) to the node; positioning of the node components relatively to each

other in the assigned map.

• The rules stating what animation actions should be performed in reaction to the behaviour observed on

the source entity. For example, an SDL process reaching a given state could cause the traffic lights icon

to switch to the green position. Similarly, a label announcing ‘‘Warning, too HOT!’’ could blink every

time a variable in the SDL system reaches a critical value. Note that the animation rules depend on the

kind of the animation source.

Basically, the node class definition syntax looks like the following: 1

nodeClass class_name {

instantiation {

1 As for node classes and instances, link classes and instances can also be defined. We do not present how, but the method is very

similar to the way nodes are specified. Link classes are used to visualize communication events between parts of the system. A link has

one node associated with each of its two ends.


instantiation_rules}

presentation {

presentation_rules}

animation {

animation_rules}

}

The instantiation and animation clauses depend on the kind of animation source (SDL, MSC, etc.); we

present them later in the paper.

The presentation clause serves to specify the general aspect of the node, in terms of contained animation

components, as just illustrated by the example below, but other characteristics can be set, such as: back-

ground colour, presence of a surrounding frame, visibility status (a node can either be rendered or become

invisible), associated map, and so on.

Example: adding to the node a Label, an Image and an Audio clip under the respective names l5, i1, andc3, and configuring some of them.

presentation {

addComponent angor.med.Label l5

addComponent angor.med.Image i1 $ICON_DIR/computer.gif

addComponent angor.med.AudioClip c3 $SOUND_DIR/explode.au

l5.setText 00Hello I am the famous label00c3.play

. . ./. . .}

2.3. Animation of formal SDL Models

One strength of the SDL language is definitely its formal semantics, which makes it executable and thus

analysable by automatic means. Commercial SDL tools provide powerful analysis features such as model

debuggers (also known as interactive simulators) and exhaustive verifiers. Nevertheless, such tools are fairly

complex and require a certain learning period until users gain a good knowledge and master them. In

addition, most of them put particular effort on providing advanced functionalities for analysis, rather than

on offering nice-looking and intuitive user interfaces (which is justifiable, in a way). The result of this is thatonly specialists generally use such tools.

The motivation behind our animation tool for SDL is to fill this gap by providing an attractive way of

visualizing what happens during simulation of the SDL specification. The SDL animation facility was

developed around the ObjectGeode Tool [2,10], by connecting the animation tool to the ObjectGeode

software bus (Fig. 2). The bus allows writing and plugging client applications in the simulator environment,

so that events occurring in the simulation can be reported to the client, but also to let the clients drive the

simulation automatically (access to the simulator command language through a provided API). The ani-

mation engine makes use of that technology, mainly to subscribe to events to be animated, as expressed inthe animation script.


For application to SDL models, we can find some similarities with the work done around the INAP

wrapper [14,21]. Indeed, starting from the same assessment about the need of animation for system vali-

dation, they develop a framework for the animation of Intelligent Network services. However, our ani-

mation environment is independent of any SDL models, thus of any application domain. The openness of

our tool also allows a great flexibility for the animation representation. The consequence of this flexibility is

the need to develop an animation model associated with the SDL model.

Animating an SDL simulation mainly means, on one hand to identify which SDL behavioural objects

should be animated (processes, procedures, etc.) and to specify the associated node classes, and on the otherto identify which SDL communications should be animated (channels and routes) and to specify the as-

sociated link classes.

In general, a node class is defined to express the animation of an SDL process, block, or procedure. In

the case of the ObjectGeode SDL Simulator, there also exists the advanced notion of observer. An observer

is an automaton external to the SDL system, whose role is usually to control the validity of a property by

observing what happens during simulation. That powerful feature also can be animated, just like normal

SDL objects.

The presentation properties of a node are described in the previous section. We show below what theinstantiation and animation clauses can contain in the case of nodes for animating an SDL source. Note that

similar constructs are available for instantiation and animation of links.

2.3.1. Node instantiation

Rules for instantiation of a node encompass: an expression establishing the relation between the targeted

SDL object and an associated Tcl identifier, and the instantiation expression itself, to be evaluated by the

SDL simulator during simulation.

In the following example, the SDL object known as monitor must lead to the creation of a node instance,named mid in the animation script, and this creation only happens when the SDL object––probably a

process, in that case––is active and holds a category variable which is greater than 3:

nodeClass 00monitor00 {instantiation {

uniqueInstance mid 00monitor00instantiationExpression {

Fig. 2. Architecture for SDL animation.


00is_active($mid) and $mid!category > 300}

}

}

Other commands such as staticInstance (for blocks or observers) and anyInstance make it possible to

express more instantiation modes.

2.3.2. Node animation

For the SDL source kind, the valid animation commands refer to

• the creation of external signals so the SDL system can be fed from the animation tool (this is the purpose

of the feed command, to be used for nodes that correspond to SDL entities communicating with the en-vironment of the SDL model);

• the continuous supervision of SDL variables (watch command);

• the modification of the node rendering, according to the state reached by the animated SDL entity (state

command);

• the modification of the node rendering, according to the reception or emission of a signal by the ani-

mated SDL entity (input and output commands).

Breakpoints can be specified together with commands state, output and input, which make the animationswitch to a pause mode when the corresponding event occurs.

Below we give short examples of the usage of animation commands:

• When the SDL entity denoted by the uid variable reaches the idle state, then the animation node enters in

hangUp state, in which both the image1 and label1 components change their aspect:

state 00hangUp00 00$uid !state¼idle00 {image1.setImageFile $ICON_DIR/phoneUp.giflabel1.setText $state_name

}

• The price of the coffee (held by the mid entity) needs to be monitored:

watch 00Coffee Price00 00$mid !price_list (coffee)00

• On reception of the SDL signal tc_invokeind (known as Invoke in the animation), a label gets a new value,and displays some text as well as the value of the signal�s, first argument. Another label may change in case

the evaluation of the indicated SDL boolean expression succeeds.

input 00Invoke00 00tc_invokeind00 {lab3.setText n

00Service invocation, with arg 1 ¼ [sdlParamValue p1]00if {[sdlEval 00$uid !nbHits¼10000]} {

lab5.setText 00Too much!00} }


2.3.3. Link instantiation and animation

An association between two node classes defines link classes; they are used to visualize the communi-

cations between the associated nodes. Thus, a link is created for each pair of node instances.

linkClass cal_leg call leg {

presentation {

static { setVisible false

setColor red }}

In this example, a link will be created each time an object call and an object leg are created. The size and

the colour of the link can be modified during the animation, and become visible or invisible. This feature

prevents the animation from having too many visible links; indeed, we may make a link visible only during

an event occurrence or between two events.

animation {

input release releaseind from call {

static { setVisible true }

setLabel 00release:[sdlParamValue 00p1 !cause00]00setToNode $to } }

On reception of the signal releaseind from an instance node call, the link becomes visible associated to alabel release with the parameter cause, the colour red and with an arrow towards the leg node.

2.4. Animation of MSC

Standardized MSC notation [12] helps in representation of interactions between system components, as

traces of a system execution. It is often used in relation with SDL:

• During analysis, to exhibit use cases (e.g., typical behaviours) expected to be implemented in the formal

and complete SDL specification. MSC diagrams are readable and are valuable when capturing require-

ments.

• During validation, to show traces of the execution of the SDL specification (scenarios to be analysed or

to be played again).

MSC diagrams represent system components as vertical bars, signals as horizontal lines and have specific

figures to represent timers (arming, disarming, expiration), tasks, conditions, etc. Extremities of vertical

bars correspond respectively to the beginning and the end of the execution of the component. An example is

presented in Fig. 3.

MSC diagrams correspond to system behaviour examples (they can also be compared to UML sequence

diagrams). Thus, they are complementary to an SDL specification, which completely describes the system.

Some particularities of MSC diagrams consist in combining MSC diagrams using operators as OR(alternative between several diagrams), AND (sequential), LOOP, EXCEPTION, PARALLEL (for sce-

narios to be executed simultaneously), REPEAT. Such diagrams are called High Level MSC. Using this

notation, each MSC diagram is a leaf or a composed scenario.

So, HMSC is a possible source of animation for the ANG�OR tool. The MSC syntax as source file

format corresponds to the textual representation of MSC as produced by ObjectGeode [10] tool.


As for animation of SDL specification, animation objects and events are associated to MSC key-words/

instructions and data. The result of an MSC animation is visually the same as the animation of an SDL

specification.

However, in our animation environment, all MSC operators are not implemented. Only the following

operators are implemented. It was chosen not to implement the PARALLEL operator for technical reason

and mainly because visualization of that concept is tricky at execution time.

An example is depicted on Fig. 4. The HMSC illustrates different behaviours associated with a protocol

transaction. The scenario Transaction is either a Transaction_OK scenario or a Transaction_KO. In the caseof the Transaction_OK scenario, two scenarios are executed sequentially: first the scenario Card_Ok and

then, Withdrawal_OK.

In the textual representation, an MSC document is associated with the complete MSC. Each node is also

associated with a document. Thus an MSC document can be an AND MSC, OR MSC, REPEAT MSC

EXCEPT MSC or LEAF MSC.

The animation follows the HMSC structure, and, for example, upon meeting the OR operator, it is

interactively proposed to the user who performs the animation to choose between the possible documents.

As far as the content of a leaf is concerned, we can animate:

Fig. 3. A message sequence chart.


• Component instances which appear when created (CREATE MSC instruction) and disappear if they are

explicitly stopped (STOP instruction);

• Sending and reception of messages, between instances or with the environment;• Events on timers (arming, disarming, expiration);

• Actions, conditions, procedure calls;

• Sub-MSCs are taken into account but should be manipulated carefully. Indeed, the semantics associated

with them [12] (sub-MSCs correspond to independent systems) did not allow specification of a satisfying

animation (coherency cannot be guaranteed);

• Coregions. Within a coregion, the order of specified events is not significant, which means that the

MSC actually specifies more situations than the one that is explicitly shown on the diagram (in

terms of interleaving of events in the coregion). A random parameter allows proposing several anima-tions.

2.4.1. Elaboration of an animation model for MSC diagrams

1. The first step consists in positioning global parameters of the model (title to be displayed, sound on/off,

etc.). It is also possible to define aliases associated with MSC documents to animate.

setModelName 00Transaction Protocol Model00setStepDelay 1

globalDefs {

set ICON_DIR /proj1/angor_java/icones

}

useGrapher angor.geo.net.NetGrapher grapher

useSource angor.src.msc.MSCAnimator complete.msc

documentClass 00transaction OK00 00Transaction !Transaction_OK00documentClass 00transaction Not OK00 00Transaction !Transaction_KO00

Fig. 5. Animation options for OR operator.

Fig. 4. A high-level MSC.


These aliases will be used to propose to the user a choice between several MSC leaves associated by the

OR operator. The use of aliases is optional. If there is no alias in the animation model, the paths proposed

to users are automatically associated with the tree structure of the HMSC (Fig. 5).

2. Creation of node classes to be animated.

3. Identification of operations to perform on previous objects (which emissions and consumptions of sig-

nals to animate and which parameters to visualise, how, which operations to animate: actions, condi-tions, call procedures, timers, etc.).

4. Creation of link classes corresponding to links between nodes we want to animate and description of this

animation (which signals, their emission and/or their consumption, etc.).

2.5. Scenario recording and replay

While playing a scenario, it is possible to record it live, so that the animation can be later replayed

exactly the same way. The animation of the scenario is captured in a file, under an adequate format, andcan be played again just by loading the file into the animation tool. Such a feature provides a means to

playback a given scenario again and again in a very lightweight manner, without the need to have the actual

animation source available and running at the time of showing the animation. For instance, people in

charge of demonstrating a new telecommunication service or a new protocol (through animation) could

play the demonstration scenario standalone, i.e., disconnected from the SDL simulator that originally

elaborated the scenario.

Further, recorded scenarios do not have to be linear (fully deterministic): it is possible to build ‘‘N-in-

one’’ scenarios, that have the structure of a tree, as show in Fig. 6. Such a hierarchical scenario is a scenariothat, at given points, can evolve following different ways. At playing time, when reaching such a divergence

point, the user of the animation tool just has to choose which ‘‘future’’ of the scenario he wants to show.

Points of divergence are called bookmarks.

Fig. 6 presents such a tree structure for the replay animation of a WAP protocol [23], where, after

connection of a client and the connection of the Server (or a move answer from the server), the animator

user can choose between a suspend operation (from the client side), a push or a confirmPush operation

(from the server side) or the call of a Get method (from the client side).

Fig. 6. Visualisation of a hierarchical animation scenario.


3. Applications to telecommunication systems

3.1. Network architectural models

3.1.1. A layered architecture

Telecommunication applications are built on very complex, distributed and heterogeneous architectures.

In next generation network, concepts such as open application programming interface (API as PARLAY/

OSA [API 02]), and virtual home environment (VHE [22]) are introduced in order to provide integrated

services over fixed, mobile and Internet networks. Such concepts lead to a very complex and layered service

and network architecture.

Application programming interfaces such as PARLAY/OSA [17] have the ambition of providing a stan-

dardised interface to service creation, an interface that should be the same for all underlying protocols. We

obtain a layered architecture where, following Fig. 7, services are built on top of service components (servicefeatures (SFs)), SFs on top of API, API on top of protocols. Then, animation could be used, either to animate

one of these layers (the protocol layer, the API or service component layer), or a complete telecommunication

service. We can animate all the layers using different windows for different views of the system.

In this section, we present the animation of the API and the protocol layers. The following sections focus

on the animation of service and service component layers.

3.1.2. Animation of PARLAY API

Fig. 8 represents the behaviour of a PARLAY API for one service invocation. This animation is ob-tained from the execution of a SDL model of the PARLAY API and the underlying IN CS1 protocol [8].

Such a model is huge (20 000 lines of SDL code for the complete model and 6000 lines for the PARLAY

API), and was done by several persons; thus it cannot be really understood without animation.

The PARLAY API is described in UML with the help of the class concept, for example classes are

defined for Call, CallLeg, UserInterfaceCall (UICall), CallManager or UserInterfaceManager. These UML

classes are translated into SDL Process types, and animated by class nodes and instances. During the

execution of an application on PARLAY, several objects corresponding to class instances are created and

destroyed. The animation shows the creation and destruction of each object and the communicationsbetween these objects (sending of Monitor from one CallLeg, or reception of Event by another CallLeg). In

Fig. 7. A layered network and service architecture.


the picture, the icons UserInteraction correspond to service components associated to different vocal

platforms (different UICall).

3.1.3. Animation of WAP protocol stack

Fig. 9 represents the animation of some layers of the WAP protocol [23], more specifically the wireless

session protocol (WSP) and wireless transaction protocol (WTP) layers, and the communication with the

wireless application environment (WAE) layer. The animation corresponds to a connection-mode session,

where after a connection request from the client side and the connection confirmation from the server side,

the client makes a request for a get method. The animation step below shows a system state where the client

method is in the requesting state, the server method in the processing state and a message is sent from the

server WSP towards the WTP layer. The complete animation may be done using the player tree of Fig. 6 inSection 2.5.

3.2. Service modelling and validation

The success of fast service creation will be enforced by the use of innovative and efficient object-oriented

methods and tools for analysis, design and early validation of services and SFs. UML [3,16] and SDL [11]

Fig. 8. Animation of a PARLAY API.


are good candidates, and we propose [8] to create new services from existing features (or new feature if no

existing feature meets the expected requirements). A SF is to be seen as a high-level component that has ameaning from the point of view of at least one actor of the service domain.

• UML is used for domain analysis (which captures all reusable elements such as SFs, common data, pro-

tocol, API and parameters description) and system analysis (which models one service by using the ser-

vice domain repository) [9].

• SDL is used for service and feature design. The service and feature logics are specified in SDL from skel-

etons issued from UML models, and plugged into the network SDL model.

• Validation should be done at different levels. Service and features should be validated from the userpoint of view, but the architectural constraints (protocols or API version, distributed nature of the logic)

taken into account. Test generation also could be done from the SDL model on different interfaces (pro-

tocols or user interfaces).

Such methodology significantly gains efficiency by the use of our animation environment. Indeed, using

our animator, we can:

Fig. 9. Animation of the WAP protocol stack.


• Validate the feature specification and propose animation scenarios corresponding to the UML use cases.

These use cases can be associated with different architectural constraints.

• Validate the service behaviour, from the user point of view, but also in the interworking between the

service logic and the SF logic.

• Generate test cases corresponding to scenarios directly played from the animation.

The facility of replaying animation scenarios without the underlying source language (and the SDL

simulator) allows demonstration of the service behaviour to clients in order to analyse best opportunities

for marketing.

Such methodology and the animator environment were used for several IN complex services such as

Virtual Private Network, Pre-paid and Post-paid Cards, Unique Number.

3.2.1. Animation of unique number service (UN service)

Figs. 10 and 11 represent the animation of a Unique Number service (UN service). This service allows an

enterprise employee to be reached from a unique number, through a predefined set of media (for example, a

fixed phone, a mobile phone, a secondary fixed phone, his secretary, his vocal or e-mail box). This service is

associated with SFs: search-on-list (the search can be done sequentially or in parallel for different media),

access (with restriction and rights), welcome feature, vocal filtering, and forwarding features. The following

pictures represent the behaviour of the service where the vocal filtering feature is active: the calling party is

connected to a welcome message, and the called party receives a message proposing different choices (accept

the call, forward the call to the secretary or to a mail box). The subscriber data can be modified before the

Fig. 10. The user view of the UN service.


animation or during the system execution. The result of such animation is of great value for negotiation

with potential clients. Associated with formal SDL verification, it also helps the service designer to build the

new service and to understand unforeseen behaviour. In Fig. 10, vocal messages are animated with labels;

they can also be associated with sounds.

3.3. Validation of a service in operation

The use of the SDL formal language allows us to develop a complete environment for the validation of a

telecommunication service in operation. Indeed, the openness of a SDL model enables the coexecution of a

Fig. 11. Animation of service and feature logic.

Fig. 12. Validation of service in operation.


part of a system in SDL and another part in a different technology. Such techniques offer numerous

possibilities [8], one of them is to connect the SDL model of the network and IN/CS1 protocol to a real

platform (service control function). Thus, we can animate from the user view the behaviour of a service

deployed on the IN platform with our animation environment (Fig. 12).

3.4. Application to service interaction

The service interaction problem is one of the major obstacles to the rapid provisioning of new tele-

communication services, and growing competition requires both efficient and quick handling of service

interaction. A service interaction occurs when the behaviour of one service is affected by the behaviour of

another service (or another instance of the same service), when these different services are deployed in the

same system. It is a very complex problem, involving several actors: subscribers, users, network operators

or service providers.

In order to handle service interaction, different activities are introduced in a specific process [5]. Systemmodelling and formal verification techniques, using for example LOTOS [15,20], LUSTRE [24] or SDL and

property violation detection [6,7], are of great help in order to detect interaction problems.

Nevertheless, we know that we cannot detect all interactions with a formal approach; some interactions

lead to new behaviours, which will not correspond to a property violation. Moreover, once an interaction

has been detected, we have to understand and analyse the cause of this problem (which services and features

are involved, which actors and data, which architecture and protocol version). From such analysis, we have

also to provide different resolution choices, some of this involving the use of protocol parameters or res-

olution manager. The problem is so complex that the animation of the system behaviour is really needed:on the one hand to exhibit the cause of the interaction, on the other hand to demonstrate alternative

resolution proposals.

The following figures show, with the use of different windows, the animation of an IN system where

different SFs are introduced and where a resolution manager is proposed [4]:

• The goal model (Fig. 13) represents different service properties. They are specified as observers (auto-

mata which can represent properties as temporal logic formulae). The observer states are modified dur-

ing the SDL model execution, and will lead to an error state if a property is violated. Such observerscan be animated, for example as traffic lights, the red colour meaning that an interaction is detected.

Fig. 13. Animation of the goal model.


We represent here two properties that correspond to the OCS feature (originating call screening: no call

should reach a user which is on the black list of the subscriber) and the ACB feature (automatic call

back: invocation of this feature by the subscriber should make a communication with the last calling

party which reached the subscriber).

• The main window (Fig. 14) represents the user view of the system execution, and thus will show in a user-

friendly way the corresponding behaviour. For example, the animation step of the picture corresponds toa call from User1 to User2 that, after forwarding, reaches User3, which is on the Originating black list of

Fig. 14. Animation of the user view.

Fig. 15. Some breakpoints, and watched data.


User1. Also, animation will demonstrate that the invocation of automatic call back by User3 will lead to

an error message, even if a call arrived previously on the line (the phone was ringing but the calling party

was not recorded as last calling party of User3, but of User2).

• The subscriber data (feature activation and parameterisation), and network configuration can be easily

read and modified using the watch concept (see Fig. 15 for OCS parameterisation). This figure also

shows the notion of breakpoints (here put on the link between OCS feature and the feature_manager)

that can be introduced off-line in the configuration file or on-line with the animation interface (clicking

on the corresponding link).• The service window (Fig. 16) shows all the SFs introduced in the system, and interworkings with the

feature handler and the call execution.

• In this window, we can also represent an on-line resolution mechanism, as the notion of observer (model

of on line observers) and solver (several treatments can be deployed for interaction resolution) and show

Fig. 16. Animation of feature execution without resolution.

Fig. 17. Watch concept for activation of resolution.


different resolution choices introduced in such solver. Fig. 18 shows the behaviour of the features, thesolver and the observer execution when the resolution mechanism is introduced and activated.

The previous figures correspond to the case where an interaction is detected between OCS and CFU. Fig.

14 corresponds to an animation where a breakpoint is met, the animation is stopped and a little icon

appears close to the link. Now, if we want to analyse the possible implementation of a resolution, we have

to modify with the watch concept (clicking on the corresponding icon, see Fig. 17) the parameters of the

feature_manager process (resolution is active) and of the solver process (a resolution mechanism is in-

troduced for OCS and CFU). Then, animation (Fig. 18) will show the resulting behaviour, the solverwill invoke OCS after CFU and the call will be killed.

4. Conclusion

The integration of an animation environment such as ANG�OR in a development process based on

appropriate software techniques such as UML and SDL strengthen the mastery of a process life cycle, thus

will help the time-to-market objective. It facilitates communication between different entities and actorsworking on telecommunication system: between specialists on different area (protocols, API, service

component, service), and between actors for a service enterprise model.

The application presented in this paper covers the area of telecommunication systems, but such ani-

mation environment could also be applied in other software areas.

For such animation environment, we can identify several user profiles, associated with different levels of

knowledge of the animator and the underlying source languages. These profiles could correspond to dif-

ferent actors of the telecommunication domain:

Fig. 18. Animation of feature execution with resolution.


• The first profile is defined only for service demonstration. Here, the animator user needs only to know

the basic behaviour of the tool for the replaying scenario.

• The second level is required for users that will realise the animation scenario from a source model (SDL

or MSC) they are not the authors of. Such users need to know more deeply the tool behaviour, specially

the animation configuration language, and should have some knowledge of the underlying language, andof the TCL language.

• The third level corresponds to users that want to animate a model they develop themselves (for a better

conception of their protocol or service specification). They have obviously to know precisely the syntax

and the semantics of the modelling language.

Even if the animation configuration language is relatively simple, the elaboration of an animation model

needs some effort. Such effort depends on the complexity of the expected results (thus on the knowledge of

the TCL language). In any case, it takes only some days for a service model, a very much smaller task thanthe construction of a SDL or UML model. An improvement of the animation environment based on SDL

will consist of the development of a graphical interface offering the set of the potential SDL objects for

animation: processes, procedures, observers. Such a graphical interface will reduce the time to make an

animation and the number of possible syntactic errors.

References

[1] M. Alabau, P. Combes, B. Renard, IN service prototyping using SDL models and animation, SDL Forum, Montreal, 1999.

[2] B. Algayres, Y. Lejeune, F. Hogonnet, GOAL: Observing SDL behaviours with GEODE, 7th SDL forum, Oslo, September

1995.

[3] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modelling Language, Reference Guide, Addison-Wesley, Reading, MA, 1999.

[4] I. Aggoun, P. Combes, Observers in the SCE and the SEE to detect and resolve service interactions, 4th FIW, Montreal, 1997.

[5] C. Capellmann, P. Combes, J. Petterson, B. Renard, J.L. Ruiz, Consistent interaction detection––a comprehensive approach

integrated with service creation, 4th FIW, Montreal, 1997.

[6] P. Combes, S. Pickin, Formalisation of a user view of network and services for feature interaction detection, 2th FIW, 1994.

[7] P. Combes, B. Renard, Service validation, Computer Network and ISDN Systems 31 (1999) 1817–1834.

[8] P. Combes, L. Castaignet, F. Dubois, B. Nicolas, B. Renard, Feature-driven service analysis and design in an open architecture,

ICIN 2001, Bordeaux.

[9] P. Combes, F. Dubois, B. Nicolas, Une d�eemarche associant UML et SDL pour l�analyse, la conception et la validation de services

de t�eel�eecommunication, MSR 2001, Toulouse.

[10] ObjectGeode, GEODE Editor and Simulator V4.2––Reference Manual, Telelogic, 2001.

[11] ITU-T, Specification and description language, recommendation Z.100, November 1999.

[12] ITU-T, Message sequence chart, November 1999.

[13] Java Command Language. Available from http://tcl.activestate.com/software/java/.

[14] K. Kimbler, C.H. Hagenfelt, N. Widell, J. Ellsberger, G. Berman, SDL framework for prototyping and validation of IN services,

SDL Forum, Montreal, 1999.

[15] L. Logrippo et al., Feature interaction detection: a LOTOS-based approach, Computer Network and ISDN Systems (32) (2000)

433–448.

[16] OMG, Unified Modelling Language (V 1.3), formal/2000-03-01, 2000.

[17] Parlay API specification. Available from http://www.parlay.org.

[18] The Tcl scripting language. Available from http://tcl.activestate.com/.

[19] K.J. Turner, A. McClenaghan, C. Chan, Specification and animation of reactive systems, in: V. Atalay (Ed.), Proceedings of the

International Symposium on Computer and Information Systems XI, Antalya, Turkey, November 1996.

[20] K.J. Turner, Realising Architectural Feature Descriptions using LOTOS. Parallel Computers, Networks and Distributed Systems,

Editions Herm�ees, Paris, 2000.

[21] L. Verhaard, K. Kimbler, D. Sobirk, C. Hagenfeldt, T. Tallinger, M. Stolt, Simulated IN CS-2 infrastructure for service animation

and validation, in: Proceedings of IN2000 Workshop, Cape Town, South Africa, May 2000.

[22] Virtual Home Environment. 3GPP TS 23.127. Available from http://www.3gpp.org.

[23] Wireless Application Protocol, WAP_white_paper. Available from http://www.wapforum.org.


http://tcl.activestate.com/software/java/

http://www.parlay.org

http://tcl.activestate.com/

http://www.3gpp.org

http://www.wapforum.org

[24] N. Zuanon, Modular Feature Integration and Validation in a Synchronous Context, Language Constructs for Describing

Features, Springer, Berlin, 2001.

Pierre Combes has been responsible during several years for a team working on service creation environmentsfor Intelligent Network platforms. He is an expert in software techniques for service engineering and iscurrently responsible for an internal France Telecom R&D project on real-time telecommunication systems.He participated in several european projects (EURESCOM, RACE, ACTS) on service creation and serviceinteraction. He is currently involved in a European project IST OMEGA and a French project RNRTPLATONIS.

Fabrice Dubois joined France Telecom R&D in 1997, and works in a team dealing with software techniques forspecification and simulation of communicating systems. In particular, he is responsible for the expertise andpromotion of SDL at France Telecom. His main activities are system modelling, framework design for specificneeds, and SDL assistance and recommendation to projects. He was also involved in a EURESCOM project ondeployment of component-based applications, and is now contributing to research on performance engineeringtechniques.

B�eeatrice Renard obtained a DEA in information science at the University of Orl�eeans in 1989. She joinedFrance T�eel�eecom R&D in 1990, and has worked for two years on a project concerning validation of tele-communication systems. She has integrated a team specialized in the specification aspects of service creation,and has been involved in several projects (RACE, EURESCOM, internal project) related to service creationand service interaction aspects. She has been the leader of an internal project related to service creation andvalidation activities. In 2000, she joined a team working on security aspects for services and networks, and sheis involved in security policy and PKI activities.


an open animation tool: application to telecommunication systems

Documents