Jean-Marc Jézéquel

Model Driven Design and Aspect Weaving

A model is a simplified representation of an aspect of the world for a specific purpose. In complex systems, many aspects are to be handled, from architectural aspects to dynamic behavior, functionalities, userinterface, and extra-functional concerns (such as security, reliability, timeliness, etc.) For software systems, the design process can then be characterized as the weaving of all these aspects into a detailed design model. Model Driven Design aims at automating this weaving process, that is automatically deriving software systems from theirs models. This paper explores the relationship between modeling and aspect weaving. It points out some of the challenges related to such automatic model weaving, illustrating them with the example of a weaving process for behavioral models represented as scenarios 1 .

Introduction

It is seldom the case nowadays that we can deliver software systems with the assumption that one-size-fitsall [START_REF] Bosch | Software product families in Nokia[END_REF]. We have to handle many variants accounting not only for differences in product functionalities (range of products to be marketed at different prices), but also for differences in hardware (e.g.; graphic cards, display capacities, input devices), operating systems, localization, user preferences for GUI ("skins"). Obviously, we do not want to develop from scratch and independently all of the variants the marketing department wants. Furthermore, all of these variant may have many successive versions, leading to a two-dimensional vision of productlines [START_REF] Ziadi | Software Product Lines, chapter Product Line Engineering with the UML: Deriving Products[END_REF].

The traditional way scientists use to master complexity is to resort to modeling. Models can be used for instance to describe and analyze the commonalities and variation points within a software product-line. In the software community however, a lot of misunderstanding on Model Driven Engineering stems from a biased understanding of the nature of modeling.

In this paper, we explore the relationship between modeling and aspect weaving. In Section 2 we recall that a model is indeed a simplified representation of an aspect of the world for a specific purpose. Complex systems typically give rise to more than one model because many aspects are to be handled. For software systems, the design process can be characterized as a (partially automated) weaving of these aspects into a detailed design model. Section 3 then discusses some of the challenges related to such automatic model weaving, concentrating on the need for weaving processes that exhibit good composition properties to allow multiple aspect weavings. As an illustration, it present an example of such a weaving process for behavioral models represented as scenarios. Section 4 presents an implementation environment for building such model weavers, based on the kernel metamodeling tool Kermeta. Some concluding remarks close the paper.

Modeling and Weaving

Models and Aspects

Modeling is not just about expressing a solution at a higher abstraction level than code. This limited view on modeling has been useful in the past (assembly languages abstracting away from machine code, 3GL abstracting over assembly languages, etc.) and it is still useful today to get e.g.; a holistic view on a large C++ program. But modeling goes well beyond that.

Modeling is indeed one of the touchstone of any scientific activity (along with validating models with respect to experiments carried out in the real world). Note by the way that the specificity of engineering is that engineers build models of artefacts that usually do not exist yet (with the ultimate goal of building them, see Figure 1). In engineering, one wants to break down a complex system into as many models as needed in order to address all the relevant concerns in such a way that they become understandable enough [START_REF] Baniassad | Theme: An approach for aspect-oriented analysis and design[END_REF]. These models may be expressed with a general purpose modeling language such as the UML [START_REF] Ziadi | Towards a UML profile for software product lines[END_REF], or with Domain Specific Languages when it is more appropriate (see Figure 2). Each of these models can be seen as the abstraction of an aspect of reality for handling a given concern. The provision of effective means for handling such concerns makes it possible to establish critical trade-offs early on in the software life cycle, and to effectively manage variation points in the case of product-lines. Note that in the Aspect Oriented Programming community, the notion of aspect is defined in a slightly more restricted way as the modularization of a cross-cutting concern [START_REF] Filman | Aspect-oriented programming is quantification and obliviousness[END_REF]. If we indeed have an already existing "main" decomposition paradigm (such as object orientation), there are many classes of concerns for which clear allocation into modules is not possible (hence the name "cross-cutting"). Examples include both allocating responsibility for providing certain kinds of functionality (such as logging) in a cohesive, loosely coupled fashion, as well as handling many non-functional requirements that are inherently cross-cutting e.g.; security, mobility, availability, distribution, resource management and realtime constraints.

Use Case Model

However now that aspects become also popular outside of the programming world [START_REF] Rashid | Modularisation and composition of aspectual requirements[END_REF], there is a growing acceptance for a wider definition where an aspect is a concern that can be modularized. The motivation of these efforts is the systematic identification, modularization, representation, and composition of these concerns, with the ultimate goal of improving our ability to reason about the problem domain and the corresponding solution, reducing the size of software model and application code, development costs and maintenance time.

Design and Aspect Weaving

So really modeling is the activity of separating concerns in the problem domain, an activity that we can call analysis. If solutions to these concerns can be described as aspects, the design process can then be characterized as a weaving of these aspects into a detailed design model [START_REF] Jézéquel | From contracts to aspects in uml designs[END_REF] (also called the solution space, see Figure 3). This is not new: this is actually what designers have been actually doing forever. Most often however, the various aspects are not explicit, or when there are, it is in the form of informal descriptions. So the task of the designer is to do the weaving in her head more or less at once, and then produce the resulting detailed design as a big tangled program (even if one decomposition paradigm, such as functional or object-oriented, is used). While it works pretty well for small problems, it can become a major headache for bigger ones.

Note that the real challenge here is not on how to design the system to take a particular aspect into account: there is a huge design know-how in industry for that, often captured in the form of design patterns. Taking into account more than one aspect as the same time is a little bit more tricky, but many large scale successful projects in industry are there to show us that engineers do ultimately manage to sort it out (most of the time).

The real challenge in a product-line context is that the engineer wants to be able to change her mind on which version of which variant of any particular aspect she wants in the system. And she wants to do it cheaply, quickly and safely. For that, redoing by hand the tedious weaving of every aspect is not an option.

We do not propose to solve this problem up-front, but just to mechanize and reproduce the process experienced designers follow by hand [START_REF] Wai | A toolkit for weaving aspect oriented UML designs[END_REF]. The idea is that when a new product has to be derived from the product-line, we can automatically replay most this design process, just changing a few things here and there [START_REF] Lahire | Introducing variability into aspect-oriented modeling approaches[END_REF].

Usually in science, a model has a different nature that the thing it models (think of a bridge drawing vs. a concrete bridge). Only in software and in linguistics a model has the same nature as the thing it models. In software at least, this opens the possibility to automatically derive software from its model, that is to automate this weaving process. This requires that models are no longer informal, and that the weaving process is itself described as a program (which is as a matter of facts an executable meta-model [START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF]) manipulating these models to produce a detailed design that can ultimately be transformed to code or at least test suites [START_REF] Pickin | Test synthesis from UML models of distributed software[END_REF].

This is really what Model Driven Design is all about.

Design Model

Use Case Model

Weaving Aspects

Ideally, all aspects are equally important, and should play a symmetrical role. In practice however, a base model is useful to provide a backbone on which other aspects are woven (see Figure 4). An aspect is then made of:

-A pointcut which is a predicate over a model that is used to select relevant model elements called join points.

-An advice which is a new behavior meant to replace (or complement) the matched ones.

Weaving an aspect consist in (1) identifying the join points matching the aspect pointcut and (2) replacing them (or composing them) with the aspect advice. Both activities of join point identification and model composition can be more complex than it seems though.

Pointcut

First, many complex aspects involve dynamic behavior. This is usually a problem for AspectJ kinds of languages [START_REF] Kiczales | The fun has just begun[END_REF] which are limited by their join point models and pointcut expression mechanisms based on concrete syntax [START_REF] Cazzola | Semantic join point models: Motivations, notions and requirements[END_REF][START_REF] Klein | Problems of the semantic-based weaving of scenarios[END_REF]. With models however, interrelations among model elements (not just classes and objects, but also methods call and other events) can be readily available and identifiable through e.g.; dynamic diagrams. While Class and Object diagrams describe clientship and inheritance among the program elements, Use Cases, Statecharts, Activity and Sequence Diagrams describe how and when the clientship takes place. Therefore, through a simple analysis of the models we can get a much more direct outline of the system execution. In [START_REF] Ramos | Matching model-snippets[END_REF] we proposed a framework for expressing aspect pointcuts as model-snippets. The idea is that model-snippets are specified upon concepts in a given domain (metamodel), but that the pattern-matching needed to find join points can be performed generically with respect to meta-models, using a Prolog-like unification. Still, as discussed in [START_REF] Cazzola | Semantic join point models: Motivations, notions and requirements[END_REF], it is in general difficult (or even statically undecidable) to identify join points when the patterns we are looking for are based on the properties of the computational flow. For instance consider the following code snippet:

void f() { while(c()) { b(); a(); } }
Detecting a join point where a call to a() is followed by a call to b() might or might not be statically possible, depending on the analysis of c(). In that particular case, we can see that it would at least require some sort of loop unrolling.

The second dimension of complexity is related to model composition. While weaving a single aspect is pretty straightforward, weaving a second one at the same join point is another story. When a second aspect indeed has to be woven, the join point might not any longer exist because it could have been modified by the first aspect advice. If we want to allow aspect weaving on a pairwise basis, we must then define the join point matching mechanism in a way that takes into account these composability issues. However, with this new way of specifying join points, the composition of the advice with the detected part cannot any longer be just a replacement of the detected part by the advice: we also have to define more sophisticated compositions operators.

The rest of this section investigates these issues taking the example of the simple modeling language of scenarios available in UML2.0 under the form of Sequence Diagrams. Note that even with such a modellevel formalisms that directly models possible execution flows, restrictive hypothesis are needed on the input language to make it possible to statically identify the join points [START_REF] Klein | Semantic-based weaving of scenarios[END_REF].

Weaving Aspects in Sequence Diagrams

Sequence Diagrams are either basic Sequence Diagrams (bSDs), describing a finite number of interactions between objects of the system, or combined sequence diagrams (cSD), that are higher level of specifications that allow the composition of bSDs with operators such as sequence, alternative and loop. Formally, Sequence Diagrams in UML2 are partially ordered sets of event instances. Figure 5 (left) shows several bSDs which describe some interactions between the two objects customer and server. The vertical lines represent life-lines for the given objects. Interactions between objects are shown as arrows called messages like log in and try again. Each message is defined by two events: message emission and message reception which induces an ordering between emission and reception.

These bSDs can be composed with operators such as sequence, alternative and loop to produce a more complex Sequence Diagram (also called UML 2.0 Interaction Overview Diagram). In Figure 5 (center), the cSD log in represents a customer log in on a server. The customer tries to log in and either succeeds, or fails. In this last case, the customer can try again to log in, and either succeeds, or the server answers "no". Figure 5 (right) shows a more compact view of the same cSD, allowing an alternative between the bSDs Accept and Retry, and between the bSDs Accept and Rejected.

In this context, we define a behavioral aspect as a pair A = (P, Ad) of bSDs. P is a pointcut, i.e. a bSD interpreted as a predicate over the semantics of a base model satisfied by all join points. Ad is an advice, i.e. the new behavior that should replace the base behavior when it is matched by P .

When we define aspects with sequence diagrams, we keep some advantages related to sequence diagrams. In particular, it is easy to express a pointcut as a sequence of messages. Figure 6 shows three behavioral aspects. The first one allows the persistence of exchanges between the customer and the server. In the definition of the pointcut, we use regular expressions to easily express three kinds of exchanges that we want to save (the message log in followed by either the message ok, the message try again, or the message no). The second aspect allows the identification of a login that fails. The third aspect allows the addition of a display and its update. The expected weaving of the three aspects depicted in Figure 6 into the cSD log in is represented by the cSD in Figure 7.

Weaving More Than One Aspect: the Detection Problem

Weaving several aspects at the same join point can be difficult if a join point is simply defined as a strict sequence of messages, because aspects previously woven might have inserted messages in between. In this case, the only way to support multiple static weaving is to define each aspect in function of the other aspects, which is clearly not acceptable.

The weaving of the three aspects depicted in Figure 6 allows us to better explain the problem. If the join points are defined as the strict sequence of messages corresponding to those specified in the pointcut, the weaving of these three aspects is impossible. Indeed, when the aspect security is woven, a message save bad attempt is added between the two messages log in and try again. Since the pointcut only detects a strict sequence of messages, after the weaving of the aspect security, the aspect display cannot be woven anymore. We obtain the same problem if we weave the aspect display first and the aspect security afterwards.

To solve this problem of multiple weaving, we need definitions of join points which allow the detection of join points where some events can occur between the events specified in the pointcut. In this way, when the aspect security is woven, the pointcut of the aspect display will allow the detection of the join point formed by the messages log in and try again, even if the message save bad attempt has been added.

In our approach, the definition of join point will rely on a notion of part of a bSD, which is a subset of a bSD where any kind of messages can occur between the messages of the pointcut. A join point will then be defined as a part of the base bSD such that this part corresponds to the pointcut.

The notion of correspondence between a part and a pointcut is defined as an isomorphism between bSD, made of a set of 3 isomorphisms between the base SD and the pointcut SD: f 0 is an isomorphism for matching objects; f 1 is an isomorphism for matching events; f 2 is an isomorphism for matching message names (taking into account wild-cards).

As an example, figure 8 shows a bSD morphism f =< f 0 , f 1 , f 2 >: pointcut → M 2 where only the morphism f 1 associating the events is represented (for instance, the event ep 1 which represents the sending of the message m1 is associated with the event em 2 ).

Weaving More Than One Aspect: the Composition Problem

Detecting a join point in a bSD then boils down to construct such an isomorphism between a pointcut and a base bSD. Once such a join point has been detected, it remains to compose the bSD Advice with the join points. Since some messages can be present between the messages forming the join point, it is not possible to simply replace a join point by an advice because we would lose the "in-between" messages. Therefore, we have to define a new operator of composition which takes into account the common parts between a join point and an advice to produce a new bSD which does not contain copies of similar elements of the two operands [START_REF] Klein | Weaving multiple aspects in sequence diagrams[END_REF]. We use an operator of composition for bSDs called left amalgamated sum, inspired by the amalgamated sum proposed in [START_REF] Klein | Merging scenarios[END_REF]. We add the term lef t because our operator is not commutative, as it imposes a different role on each operand. Figure 9 shows an example of left amalgamated sum where the two bSDs base and advice are amalgamated. For that, we use a third bSD which is the pointcut and two bSD morphisms f : pointcut → base and g : pointcut → advice which allow the specification of the common parts of the two bSDs base and advice.

f is the isomorphism from the pointcut to M that has automatically been obtained with the process of detection described into the previous section.

The morphism g, which indicates the elements shared by the advice and the pointcut, has to be specified when the aspect is defined. In this way, g allows the specification of abstract or generic advices which are "instantiated" by the morphism. For instance, it is not mandatory that the advice contains objects having the same names as those present in the pointcut. In the three aspects in Figure 6, the morphism g is not specified but it is trivial: for each aspect, we associate the objects and the actions having the same names, and the events corresponding to the actions having the same name. The advice of the aspect Display in Figure 6 could be replaced by the "generic" Advice in Figure 9. It is the morphism g which indicates that the object customer plays the of the object subject and that the object server plays the role of the object A.

In Figure 9, the elements of the bSDs base and advice having the same antecedent by f and g will be considered as identical in the bSD result, but they will keep the names specified in the bSD base. For instance, the objects subject and A in the bSD advice are replaced by the objects customer and server. All the elements of the bSD base having an antecedent γ by f such that γ has not an image by g in the bSD advice are deleted. This case does not appear in the example proposed, but in this way we can delete messages of the bSD base. For instance, in an amalgamated sum, if the right operand (the bSD advice in the example) is an empty bSD then the part of the left operand which is isomorphic to the pointcut (that is to say the join point), is deleted. Finally, all the elements of the bSDs base and advice having no antecedent by f and g are kept in the bSD result, but the events of the bSD advice will always form a "block" around which the events of the bSD base will be added. For instance, in Figure 9, in the bSD base, if there were an event e on the object customer just after the message try again, then this event e would be localized just after the sending of the message update (event ea 7 ) in the woven SD.

Note that if we are interested in carrying on an implementation based on these woven SD, we could easily synthesize statecharts from them [START_REF] Ziadi | Revisiting statechart synthesis with an algebraic approach[END_REF], and then either derive test cases [START_REF] Pickin | Test synthesis from UML models of distributed software[END_REF] or an implementation [START_REF] Chauvel | Code generation from UML models with semantic variation points[END_REF].

Discussion

This example with Sequence Diagrams illustrates several hard issues of weaving aspects at model level, involving both semantic based pattern matching and semantic based composition. While our solutions are very specific to the semantics of Sequence Diagrams, we can find related problems and solutions in other modeling languages, for instance Statecharts or Activity Diagrams.

It probably means that there is no hope for a fully general purpose, meta-model independent, modellevel aspect weaver. Still, it should be possible to develop aspect weaving software components handling several aspects of aspect weaving, from general purpose model-level pattern matching [START_REF] Ramos | Matching model-snippets[END_REF] to automated support for composing models written in a particular language (through a definition of model composition behavior in the metamodel defining the language [START_REF] France | Providing support for model composition in metamodels[END_REF]), to specializ- able model composers [START_REF] Jackson | Toward a generic and extensible merge operator[END_REF]. These aspect weaving components could then be customized and combined to build domain specific or even project specific aspect weavers.

From an higher viewpoint, what we are trying to achieve is to reify the design process into a weaver program that makes it possible to re-build as often as it is need the target software from its models. The goal is to have only small modifications to make when requirements do change. Actually we need a family of weavers, that for a given product-line are just variants of one's another [START_REF] Lahire | Introducing variability into aspect-oriented modeling approaches[END_REF].

There is thus a need for tools to build these weavers efficiently. These tools are often called meta-tools, or more properly meta-modeling tools, that is tools to build tools to build software from models. Several of these meta-modeling tools have matured over the last decade, the most well known being Metacase [START_REF] Pohjonen | Automated Production of Family Members: Lessons Learned[END_REF], Xactium [START_REF] Clark | Applied Metamodelling: A Foundation for Language Driven Development[END_REF], GME [START_REF] Ledeczi | The Generic Modeling Environment[END_REF], and Kermeta [START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF]. All these meta-modeling tools have in common that they are based on an executable meta-modeling language specifically designed to support the design of tools dedicated to user defined meta-models. In the next section, we outline one of these tools, Kermeta, and describe how it can be used to build a model weaver for our Sequence Diagrams example.

Building Project Specific Aspect Weavers with Kermeta

Kermeta is a meta-modeling language which allows describing both the structure and the behavior of metamodels. It has been designed to be compliant with the OMG meta-modeling language EMOF (part of the MOF 2.0 specification) and Ecore (from Eclipse). It provides an action language for specifying the behavior of models. Kermeta is intended to be used as the core language of a model oriented platform. It can be seen as a common basis to implement Metadata languages, action languages, constraint languages or transformation language. Kermeta is statically typed, with generics as well as function types to allow OCL style forall/exist/iterate style of closures. It also directly supports model-oriented concepts like associations, multiplicities or object containment management, as well as aspect-oriented style of static introduction2 .

A MOF meta-model is a valid Kermeta program that just declares packages and classes and does nothing (see Figure 10). Several aspects can then be introduced incrementally to breath life into this meta-model, either for handling concerns of static semantics, dynamic semantics, or model transformations [START_REF] Muller | On executable metalanguages applied to model transformations[END_REF] . Here, we are interested in the later, i.e. adding Kermeta code that weave several behavioral aspects into a base scenario.

As illustrated in Figure 11, the weaving implemented with Kermeta consists of two steps. First, the detection step uses the pointcut model and the base model to compute a set of join points. Each join point is characterized by a morphism from the pointcut to a corresponding elements in the base model. Secondly, using these morphisms, the advice is composed with each join point in the base model.

The first step processes models to extract join points and the second is a model transformation. Figure 12 gives an other view of the overall process, concentrating on the input and output models of these two steps (each ellipse is a model and the black rectangle on the top left-hand corner indicates its meta-model). Except for morphisms (which are defined with their own metamodels), all models are SDs.

Conclusion

From an engineering point of view, modeling and weaving aspects are symmetric activities: weaving aspects is the process by which analysis models are transformed into a design model. Model Driven Engineering makes it possible to automate this process: i.e. to have software build software instead of building it by hand. In this paper we have described the overall vision of a design process based on these ideas.

We have highlighted however that both activities of join point identification and model composition can be more complex than it looks at first. Beyond the well known fact that it is in general difficult (or even statically undecidable) to identify join points when the patterns we are looking for are based on the properties of the computational flow, additional difficult join point detection and composition problems may arise when more than one aspect has to be woven. When a second aspect indeed has to be woven, the join point might not any longer exist because it could have been modified by the first aspect advice. For aspect weaving to be defined on a pair-wise basis, the join point matching mechanism must take into account these composability issues. Further, with this way of specifying join points, the composition of the advice with the detected part cannot any longer be just a replacement of the detected part by the advice: we also have to define more sophisticated compositions operators.

We have illustrated these issues on a toy example where simple aspects, described as Sequence Diagram pairs (representing the aspect pointcut and advice), had to be woven into a base Sequence Diagram.

While it probably means that there is no hope for a fully general purpose model-level aspect weaver, we have shown that it is possible to develop aspect weav-require kermeta require "../models/bigSd.kmt" require "../detectionAlgorithm/Detection.kmt" require "../amalgamatedSum/LeftSum.kmt" using kermeta::standard using bigSd ing software components handling several aspects of aspect weaving, from general purpose model-level pattern matching to ad hoc and specializable model composers. These aspect weaving components could then be customized and combined to build domain specific or even project specific aspect weavers using for instance a an executable meta-modeling environment as available in Kermeta.

Still there are additional important issues that we did not specifically address in this article, for instance the problem of weaving heterogeneous models [START_REF] Barais | Composing multiview aspect models[END_REF], that is models consisting of different diagram types as available in UML. In that case, we have to be concerned with consistency of the models: does weaving take place only when information is represented consistently across the diagrams or should weaving tolerate the inconsistencies and clearly bring out problems arising from inconsistencies during or after the weaving? Answering these questions, as well as others including process issues such as how interactive vs. automatic should be the weaving, or when should the weaving take place (i.e. at once at modeling time, or in several steps including some steps carried out at runtime) will be the subject of much future works in our research team.

Figure 1

 1 Figure 1 Modeling the world

Figure 2

 2 Figure 2 Modeling several aspects

Figure 3

 3 Figure 3 Design is Weaving Models

Figure 5

 5 Figure 5 Examples of bSDs and combined SD

Figure 6 Figure 7

 67 Figure 6 Three aspects

Figure 8

 8 Figure 8 Example of a morphism between bSD

Figure 9

 9 Figure 9 An example of left amalgamated sum

Figure 10

 10 Figure 10 Extract of the bSD Metamodel and its corresponding Kermeta textual syntax

Figure 12

 12 Figure 12 Transformation of Models

Figure 11

 11 Figure 11 Weaving Aspects in Kermeta

This work has been partially supported by the AOSD-Europe Network of Excellence.

Since a Kermeta program is a model, it can also obviously reflectively support the kind of aspect weaving described in this article.

Acknowledgments

This work has been partially supported by the AOSD-Europe Network of Excellence.

We are also extremely grateful to Jacques Klein and Franck Fleurey for the development of the weaving example used all along this paper, and beyond that, for many interesting discussions around aspect weaving.


Maha Driss
email: maha.driss@irisa.fr

Yassine Jamoussi
email: yassine.jamoussi@ensi.rnu.tnhenda.benghezala@ensi.rnu.tn

Henda Hajjami

Ben Ghézala

QoS Testing of Service-Based Applications

Keywords: Service-Based Applications, Discrete-Events Simulation, QoS, Evaluation

Web services (WSs) are becoming increasingly popular because of their potential in several application domains including e-Enterprise, e-Business, e-Government, and e-Science. Based on open XML standards, WS technology allows the construction of massively distributed and loosely coupled applications. A service composition mechanism should satisfy not only functional properties but also non-functional Quality of Service (QoS) ones. In this paper, we introduce a discrete-events modeling approach for Service-Based Applications (SBAs). This approach is oriented towards QoS evaluation through simulation.

Introduction

In the past decades, the evolution of software systems observes continuous growth of the complexity levels and the maturation of the networks and protocols. The crossapplication integration and interoperability, the flexibility of implementation and reconfiguration became essential requirements for the modern architectural styles. The main challenge is to simplify the integration of software applications, regardless possible heterogeneity of implementing platforms, protocols, and devices. Service-Oriented Architecture (SOA) utilizes services as the fundamental elements in order to deliver low-cost, flexible, and scalable distributed applications [START_REF] Huhns | Service-oriented computing: Key concepts and principles[END_REF] [START_REF] Papazoglou | Service -oriented computing: Concepts, characteristics and directions[END_REF]. Web Services (WSs) are universally accessible software components advertised, discovered, and invoked over the Web [START_REF] Papazoglou | Service -oriented computing: Concepts, characteristics and directions[END_REF]. The key aspect of this emerging paradigm is the use of standard technologies such as: Web Services Description Language (WSDL) [START_REF] Chinnici | Web services description language (wsdl) version 2.0: Core language[END_REF], Universal Description, Discovery, and Integration (UDDI) [START_REF] Bellwood | Universal description, discovery and integration specification (uddi) 3.0[END_REF] and Simple Object Access Protocol (SOAP) [START_REF] Box | Simple object access protocol (soap) 1.1[END_REF]. These technologies aim to support the definition of services, their advertisement, and their binding for triggering purposes. The process-based composition of WSs is gaining a considerable momentum as an approach for the effective integration of distributed, heterogeneous, and autonomous applications [START_REF] Huhns | Service-oriented computing: Key concepts and principles[END_REF]. Quality of service (QoS) is an important concern for Service-Based Applications (SBAs). QoS for WSs refers to various non-functional characteristics such as response time, throughput, availability and security [START_REF] Bianculli | Monitoring conversational web services[END_REF]. Since many service providers provide similar services with common functionality, different WS processes can be composed satisfying the same user requirement. Users will discriminate these processes based on their QoS [START_REF] Zeng | Qos-aware middleware for web services composition[END_REF]. Also, WSs operate autonomously within a highly variable environment: the Web. As a result, their QoS may evolve relatively frequently to the dynamic and unpredictable nature of the execution environment (e.g., network resources, devices characteristics, etc.) [START_REF] Zeng | Qos-aware middleware for web services composition[END_REF]. In particular, during an execution of a composite service, the component services involved may change their QoS properties, others may become unavailable, and still others may emerge. For the above reasons, the management and assurance of the quality aspects of SBAs become of utmost importance. To achieve the desired quality of a SBA, different analytical quality assurance techniques can be applied. The goal of these techniques is to evaluate QoS and to uncover faults in the composed applications after their creation. One of the relevant techniques is testing. The goal of testing is to (systematically) execute services or SBAs in order to uncover failures. During testing, the service or SBA which is tested is fed with concrete inputs and the produced outputs are observed [START_REF] Osterweil | Strategic directions in software quality[END_REF] [18] [START_REF] Baresi | Test and analysis of web services[END_REF]. The observed outputs can deviate from the expected outputs with respect to functionality as well as QoS. When the observed outputs deviate from the expected outputs, a failure of the service or the SBA is uncovered. A special case of testing is simulation. The goal of the simulation is to emulate the conversational behaviour of atomic WSs participating in the composition. In this paper, we adopt a discrete-events simulation to test WS compositions. We introduce a modeling approach for SBAs. This approach enables analytical description of SBAs and allows QoS predictions in different status and conditions of the execution environment. We define a simple quality model for WSs focusing on essential properties of QoS that play a critical role for the effective management of WSs and that can be measured by simulation technique. The remainder of the paper is structured as follows: in Section 2, simulation issues are addressed. Experimental results are documented in Section 3. Related research is discussed in Section 4. This paper closes with concluding remarks and future work.

Discrete-events simulation modeling of SBAs

Simulation is an important testing technique, as it allows users to tune and to evaluate software systems without experiencing the cost of enacting them. In this work, we propose an SBA modeling approach that is oriented towards performance evaluation through discrete-events simulation. Discrete-events simulation is a kind of qualitative description of a dynamic system whose behaviour is event-driven. This technique is frequently used to analyze and predict the performance of real word systems. Given the evolution of the operation of a system, we can analyze its behaviour and evaluate appropriate quality measures. [START_REF] Sampath | Diagnosability of discrete-event systems[END_REF] and [START_REF] Cordier | Event-based diagnosis for evolutive systems[END_REF] are fundamental works about discrete-event systems diagnosis. Discrete-events simulation is suitable to model the behaviour of a SBA since it is composed of WSs which are decentralized and dynamic. The interactions between WSs can be modeled by a synchronized composition of several local models. To elaborate our simulation model for SBAs, we are based on the work presented in [START_REF] Nikolaidou | An applicationoriented approach for distributed system modeling and simulation[END_REF] that focuses on modeling distributed applications. We model an SBA as a combination of two types of entities: distributed application and network infrastructure entities. Our simulation model is shown in Figure 1.

Distributed application modeling

The operation of distributed application is based on the client-server model. In this model, the client sends a set of requests to the server and the server sends a response • Processing: indicating data processing;

• Request: indicating invocation of a server process;

• Write: indicating data storage;

• Read: indicating data retrieval;

• Transfer: indicating data transfer between client and server processes;

• Synchronize: indicating replica synchronization.

Each process is executed on a processing node. Processing action indicates invocation of the processing unit of the corresponding node and is characterized by the amount of data to be processed. Request action indicates invocation of a server process and is characterized by the name of the server, the name of the WS, its invoked interface and the required inputs. Request action implies activation of the network, since the request and the reply must be transferred from the invoking to the invoked process, and vice versa.

There are two available actions for data storing, read and write, which are characterized respectively by the amount of the stored and retrieved data and the invoked server. Observations and performance analysis of web services applications have proven that SOAP messages are small and simple [START_REF] Chen | Evaluation and modeling of web services performances[END_REF]. Transfer action is used to indicate SOAP messages exchange between processes. Synchronize action is needed since replication of processes and data is a common practice in such distributed applications. Synchronize action parameters include the process replicas that must be synchronized and the amount of transferred data.

To describe the operation of a SBA, we proceed by transforming the process behaviour written in BPEL into discrete-event actions. BPEL is a standard proposed by IBM and Microsoft along with several other companies to model composed Web services [START_REF]Business process execution language for web services[END_REF]. BPEL defines a grammar for describing the behaviour of a WS process. It is composed of fifteen activity types, some of them are basic activities and the others are structured activities. Among the basic activities, the most important ones are the following:

• The <receive> activity: is for accepting the triggering message from another Web service;

• The <reply> activity: is for returning the response to its requestor;

• The <invoke> activity: is for invoking another Web service.

The structured activities define the execution orders of the activities inside their scopes. For example:

• The <sequence> activity: defines the sequential order of the activities inside its scope;

• The <flow> activity: defines the concurrent relations of the activities inside its scope.

Each activity can be translated into the discrete-event formalism as one or several actions. Basic activities involve processing, request and data storing actions, while structured ones involve transfer and synchronize actions.

Network infrastructure modeling

In the proposed modeling scheme, the network infrastructure is considered as a collection of individual networks and internetworks, exchanging messages through relay nodes (active communication devices e.g. routers and switches). Communication element entity represents protocol suites (i.e. routing protocols (OSI layers 2 and 3) and peer-to-peer protocols (OSI layers 4-7)). According to the SOA, communication between processes is performed through exchanging SOAP messages. Figure 2 illustrates one way of making a remote call using SOAP in OSI network reference model [START_REF] Bertsekas | Data Networks[END_REF]. First at application level, a native data object needs to be serialized into XML as SOAP request. Then, the SOAP message is passed to HTTP level. The HTTP layer, on the client-side, needs to 'handshake' with service-side by sending a 'POST' request. This request initiated a TCP connection. Once receiving 'HTTP: ACK', the client-side HTTP begins to send the whole SOAP message via TCP/IP. The SOAP message may be partitioned into a set of small segments at TCP layer. Appropriate headers and footers are attached to each segment as the segments are passed through Transport, Network, Data Link layers, until reaching the Network Interface Card (NIC) at the physical layer. The NIC is responsible for putting the packages onto the wire at a specific speed (network bandwidth) to next network device (such as router or switch), till server NIC [START_REF] Bertsekas | Data Networks[END_REF]. The path from bottom (physical layer) to the top (application layer) on the service-side is opposite to the process on the clientside: the received packages are unpacked at each layer and forwarded to next layer for further retrieving.

Our simulation tool

We have conducted simulation experiments using NS-2 simulator [START_REF] Fall | The ns manual[END_REF]. NS-2 is a discrete-events simulator; its code is written in C++ with an OTcl interpreter as a front end. NS-2 is targeted at networking research. It provides substantial support for simulation of TCP, routing, and multicast protocols over wired and wireless networks. The main advantages of such an object-oriented simulator are reusability and easy maintenance. To support SBA simulation, we have extended the C++ class hierarchy in order to implement HTTP, SMTP and SOAP protocols. Our SBA Simulator (SBAS) is modular and includes: a graphical user interface, a BPEL generator, a simulation model generator, a models library and NS-2 simulator. The architecture of SBAS is presented in Figure 3. User specifies the SBA under study using activity diagrams. SBAS constructs corresponding BPEL model. Simulation model is implemented as actions organized in the object hierarchy of the NS-2 simulator. When simulation has been completed, results are collected and subjected to output QoS analysis.

Experimentation

As a running example, we use the Travel Planner (TP) composite service, whose BPEL code is sketched in Figure 4, while Figure 5 illustrates the corresponding activity diagram with its abstract services. In this paper,we focus on evaluating only response time. Other QoS parameters (e.g., reliability, availability and scalability) are described and analyzed in our previous works [START_REF] Driss | A discrete-events simulation approach for evaluation of service-based applications[END_REF]. Response Time corresponds to the total time needed by a WS to transform a set of inputs into outputs. Response Time (RT) for a service (s) can be computed as follows:

RT(s) = ST(s) + DT(s)

• Service Time (ST) is the time that the WS takes to perform its task.

• Delay Time (DT) is the time taken to send/receive SOAP messages.

DT(s) =T msgT rans (s) + T synch (s) + T app (s)

-T msgT rans represents the total cost to transfer a specific amount of messages over network;

-T synch represents the overhead of the extra synchronization required by protocols; -T app represents the time spent in business logic at application level.

For more details about T msgT rans , T synch and T app modeling see the work described in [START_REF] Chen | Evaluation and modeling of web services performances[END_REF]. We have performed a set of simulation experiments, and we have considered the average value. Our simulation results are summarized in Figure 7 and we conclude that service "BikeRental" is the fastest and the most scalable one among all tested WSs. "CarRental" service poses time problems so it must be changed.

Related work

To achieve the desired quality of an SBA, different analytical quality assurance techniques can be employed. The goal of these techniques is to evaluate QoS and to uncover faults in the SBA after it has been created. The review of relevant literature in the field of quality assurance for SBAs shows three major classes of analytical techniques and methods: (i) Testing, the goal of which is to (systematically) execute services or SBAs with predefined inputs in order to uncover failures, (ii) Monitoring, which observes services or SBAs as well as their context during their current execution, (iii) Static analysis, the aim of which is to systematically examine (without execution) an artifact (e.g., a service specification) in order to determine certain properties or to ascertain that some predefined properties are met. These classes have been proposed in the software quality assurance literature (e.g., see [START_REF] Osterweil | Strategic directions in software quality[END_REF] and [START_REF] Myers | Art of Software Testing[END_REF]) and have been used in a recent overview of quality assurance approaches for SBAs [START_REF] Baresi | Test and analysis of web services[END_REF]. There have been numerous efforts by leading research groups to use monitoring and static analysis to evaluate QoS and to discover problems in SBA execution. Relevant works in the area of SBAs monitoring are: [START_REF] Pistore | Assumption-based composition and monitoring of web services[END_REF] [6] [START_REF] Baresi | Towards dynamic monitoring of ws-bpel processes[END_REF] [27], etc. Static analysis is adopted in [START_REF] Salan | Describing and reasoningon web services using process algebra[END_REF] [14] [START_REF] Rouached | Towards formal verification of web service composition[END_REF], etc. In this work, testing technique is used for analyzing the efficiency of SBAs. We adopt simulation approach to test SBAs. Simulation allows us to predict system performance in different status and load conditions of the execution environment. The predicted results are used to provide feedback on the efficiency of the system. Simulating Web processes for performance evaluation is a research area with little previous work. Works in simulation that are the closest to ours are described by [START_REF] Narayanan | Simulation, verification and automated composition of web services[END_REF] [8] and [START_REF] Mancini | A simulation-based framework for autonomic web services[END_REF]. [START_REF] Narayanan | Simulation, verification and automated composition of web services[END_REF] proposes a model-theoretic semantics as well as distributed operational semantics that can be used for simulation, validation, verification, automated composition and enactment of DAML-S-described SBAs. To provide a fully service description, Narayanan and McIlraith use the machinery of situation calculus and its execution behaviour described with Petri Nets. They use the simulation and modeling environment KarmaSIM to translate DAML-S markups to situation calculus and Petri Nets. In this work, three verification problems are simulated and analyzed: reachability, liveness and existence of deadlocks. Use of simulation for WSs is described also in [START_REF] Chandrasekaran | Performance analysis and simulation of composite web services[END_REF]. This work focused on problems related to SBA specification, evaluation and execution using Service Composition and Execution Tool (SCET). SCET allows to compose statically a WS process with WSFL and to generate simulation model that can be processed by the JSIM simulation environment. In this work, Chandrasekaran et al. have enhanced WSFL to include QoS estimates obtained by performing simulation tests. Only the QoS response time dimension is supported by the implementation of JSIM [START_REF] Chandrasekaran | Performance analysis and simulation of composite web services[END_REF]. In contrast to our approach, both [START_REF] Narayanan | Simulation, verification and automated composition of web services[END_REF] and [START_REF] Chandrasekaran | Performance analysis and simulation of composite web services[END_REF] don't consider execution environment information in simulation model. [START_REF] Mancini | A simulation-based framework for autonomic web services[END_REF] presents a framework whose aim is to support the development of self-optimizing, predictive and autonomic systems for WS architectures. It adopts a simulation-based methodology, which allows predicting system QoS in different status and load conditions. In contrast to [START_REF] Narayanan | Simulation, verification and automated composition of web services[END_REF] and [START_REF] Chandrasekaran | Performance analysis and simulation of composite web services[END_REF], this work considers execution environment information in simulation model. This work focuses on simulating only atomic WSs. Also it proposes only one possible QoS optimization that is response time minimization. Enhancements are needed to simulate SBAs and to add more optimization rules for QoS parameters.

Conclusion

We have presented a discrete-events simulation approach for testing SBAs. We have contributed in the definition of a simulation model for SBAs. The proposed model is composed of two types of entities: distributed application and network infrastructure.

Both are described in terms of their elementary components. Distributed application is described by a set of primitive actions: Processing, Request, Write, Read, Transfer and Synchronize. Network infrastructure is considered as a collection of individual networks and internetworks, exchanging messages. Our modeling approach is oriented towards QoS evaluation. A simulation tool has been constructed for this purpose. To show the effectiveness of our approach, we have conducted a set of simulation experiments. One possible extension of our work is the support of dynamic adaptations of SBAs. This requires specific testing and analysis techniques to verify the adaptation behaviour.

Figure 1 .

 1 Figure 1. Simulation model for SBAs

Figure 2 .

 2 Figure 2. Sending a SOAP request under OSI

Figure 3 .

 3 Figure 3. SBAS architecture

Figure 4 .

 4 Figure 4. The TP BPEL specificationSimulation experiments were conducted in the testing platform described in Figure6. This platform consists of two identical 1.86GHz CPUs machines connected via 100Mbps LAN.

Figure 5 .Figure 6 .

 56 Figure 5. The TP activity diagram

Figure 7 .

 7 Figure 7. Simulation results

Authorized licensed use limited to: UR Rennes. Downloaded on March 24, 2009 at 08:20 from IEEE Xplore. Restrictions apply.


PTLC 2007

Visual representation of prosody for tactful communication skills -the case of request in Japanese as a Foreign Language taught to French university students KAMIYAMA Takeki, Laboratoire de Phonétique et Phonologie (UMR 7018), CNRS / University of Sorbonne Nouvelle -Paris 3 YAMAMOTO Yoshino, Charles de Gaulle University -Lille 3 Abstract Prosody conveys not only linguistic but also paralinguistic information. Some features are language-specific, and L2 learners have to learn them implicitly or explicitly. For instance, some French learners of L2 Japanese produce expressions of request with a prosody that can sound somewhat rude to native speakers, especially if they do not diminish intensity enough at the end of the sentence. This article reports how the appropriate prosody was taught through explicit instruction and repetition task, with the aid of visual representation.

1 Background Some foreign/second language learners end up producing utterances which sound rude to native listeners. Learners have to use not only appropriate vocabulary items, expressions, constructions, and communication strategies, but also appropriate prosody that accompanies them. However, similar prosodic patterns do not necessarily convey similar paralinguistic information across languages. It was shown that some attitudes were perceived easily by non-native listeners, while others were confounded when they formed prosodic "faux amis" [START_REF] Shochi | Comment les attitudes prosodiques sont parfois de « faux-amis » : les affects sociaux du japonais vs. français[END_REF] for French and Japanese). It is therefore essential to teach the appropriate prosodic patterns of L2 explicitly when they differ from the ones expected in the native language of the learners.

In the case of Japanese taught to French university students as a foreign language, we notice cases of this kind in expressions of request or refusal, which could threaten the face of the recipient of the message. Inappropriate prosody produced by learners might offend the listener, who, in the case of request, would be reluctant to do them a favour, and hinder a fluent communication in spite of the learner's intention to succeed in the interaction. Learners at elementary level might be excused, but advanced learners who speak fluently would not be, since the expectation of the listener is higher. It is a pity that a highly fluent learner should be considered rude simply because they do not produce appropriate prosody. It is therefore important to teach it explicitly in language classes. The present paper reports the instruction given to the students of Japanese at Charles de Gaulle University (Lille 3) in France, with a focus on the visual representation of prosody used in the classes.

Expressions of request and prosody in Japanese

In the present paper, we take three expressions of request: 1) "V + te itadakemasenka", 2) "V + te idadakemasen deshouka", 3) "V + te itadakeruto arigataindesuga". The first two forms end with the interrogative particle "ka". Interrogative sentences with "ka" are usually pronounced with a final rise on the last syllable, namely, "ka" (Abe 1998, among others). However, in the case of the expressions of request, the final rise is smaller in 1), and almost inexistent in 2), even though the sentences are morphologically and syntactically interrogative. The figure 1 shows two sentences "kaite itadakemasenka" and "kaite itadakemasendeshouka" (kaite < kaku "to write, to draw") pronounced by the instructor of the classes (female native speaker of Japanese). We notice that the syllable /ka/ at the end of the sentences is lengthened, though the vowel is phonemically short. In the expression "… masenka", F0 is slightly rising, while the intensity is decreasing. We can observe a similar tendency in "… masendeshouka", except that F0 is flat during /ka/. In both cases, the intensity of the syllable /ka/ is smaller than that of the preceding syllables in spite of the relatively high intrinsic intensity of the vowel /a/. This indicates that the decrease in intensity is quite important for this particle 1 .

The construction "V + te itadakeruto arigataindesuga" is a more indirect expression that could be translated as "(I) would be grateful if …". The morpheme "ga" is an adversative conjunction, and therefore, the sentence is not finished syntactically and is sometimes transcribed with suspension points in spelling. The prosodic features are similar to those of "… masendeshouka", that is to say that the final syllable is lengthened, F0 stays flat, and the intensity decreases progressively.

3 Learners' production before instruction The difficulties that the learners encounter in producing the prosodic patterns described above are the following: 1) constructions "… masenka" and "… masendeshouka" are morphologically and syntactically interrogative. For those who have acquired the final rise in interrogatives, these are new prosodic patterns associated with syntactically similar constructions. 2) In many languages, high F0 is associated with politeness (Ohala's "frequency code": Ohala 1984 and 1996), while it is not necessarily the case in Japanese [START_REF] Ito | Japanese Politeness and Suprasegmentals: A Study based on Natural Speech Materials[END_REF]. Therefore, making a polite request without a high final rise may not be instinctively natural to the learners.

Figure 2 shows two sentences "kaite itadakemasenka" and "okutte itadakemasendeshouka" (okutte < okuru "to send") pronounced by two different learners (male native speakers of French), and perceived as rude by the instructor. We notice that the final particle "ka" was pronounced with a remarkable rise in both cases, and that the intensity of this syllable is not smaller than that of the preceding syllables (compared even with the vowel /a/ in the syllable /ma/). In the second example, the vowel duration of the syllable /ka/ is lengthened as in the pronunciation of the instructor (figure 1), but it is not the case in the first one. 1 To our knowledge, there seems to be no experimental study which showed this tendency in this given context.

PTLC 2007

1.

2.

3.

Figure 3. Visual representation of F0, intensity and voice quality shown in the classes. 1) "kaite itadakemasenka", 2) "kaite itadakemasendeshouka", 3) "kaite itadakeruto arigataindesuga".

4.1: F0

There are a number of F0 representation systems for intonation 2 . To cite some of them, Tanaka & Kubozono (1999) use schematized pitch curves, and Matsuzaki proposes "prosodygraph", which figures circles and ellipses that trace the extracted F0 curve of sentences (cf. [START_REF] Matsuzaki | Purosodiigurafu wo mochiita nihongo onsei kyouiku: inritsu shidouyou karikyuramu ni tsuite (Use of prosody-graph in the teaching of Japanese: on the curriculum of prosody teaching)[END_REF]). In the present case, besides the use of F0 curves, we also adopted another system where kana letters were placed higher or lower according to a schematized pitch curve (fig. 2,3).

4.2: Intensity

To our knowledge, transcriptions that take intensity into consideration are almost inexistent. We used grey scale to represent the decrease in intensity (fig. 3-1, 2). 4.3: Voice quality In making requests, native speakers of Japanese often manifest the attitude of "kyoshuku", which Sadanobu (2004: 34) defines as follows: "a mixture of suffering ashamedness and embarrassment, (which) comes from the speaker's consciousness of the fact that his/her utterance of request imposes a burden to the hearer". "kyoshuku" is expressed by a pressed, 2 We treat sentence or phrase intonation separately from lexical accent.

PTLC 2007

creaky voice quality. Figure 3-3 shows the font "Onryo" which would help learners to notice and acquire this voice quality.

5 Results of the instruction and perspectives After working on these prosodic features explicitly, the instructor found differences between the learners who attended the classes and those who didn't: the former had raised consciousness on pronunciation, and produced less often utterances of request that sounded rude. Informal feedback given by some learners who participated actively includes following comments: they became conscious of prosody and they would pay more attention to it; the visual representation was very helpful; the use of different fonts and greyscaling helped them to raise consciousness; they got motivated to work further on prosody.

In the present article, we have only reported some remarkable utterances to illustrate the tendency studied. We have yet to conduct a series of quantitative studies to see if 1) the observed prosodic tendency is systematically produced by native speakers; 2) learners show the observed tendency systematically before instruction; 3) there is a measurable (by a listening experiment with native speakers, for instance) improvement after the instruction.

For future pedagogical developments, we will have to conceive material to support autonomous learning. Combining the visual representation with sound files of the model pronunciation will encourage learners to study autonomously.

Figure 1 .

 1 Figure 1. Sentences /kaite itadakemaseɴka/ (left) and /kaite itadakemaseɴdesjoʀka/ (right) pronounced by the instructor of the classes (female native speaker of Japanese). The continuous curve represents intensity, the other one the F0 (fundamental frequency) curve. /ɴ/ is a moraic nasal, and /ʀ/ is the second half of a long vowel.

Figure 2 .

 2 Figure 2. Sentences /kaite itadakemaseɴka/ (left) and /okuQte itadakemaseɴdesjoʀka/ (right) pronounced by two different learners (male native speakers of French). The continuous curve represents intensity, the other one the F0 (fundamental frequency) curve. /Q/ is the second half of a geminate obstruent. 4 Instruction in classes: the aid of visual representation The instruction of prosodic patterns was carried out in regular classes. The learners were told to repeat after the instructor with the aid of visual representation projected on a screen. Following parameters were included in the representation: F0, intensity, and voice quality.