Sahar Kallel
email: sahar.kallel@lirmm.fr

Bastien Tramoni
email: bastien.tramoni@lirmm.fr

Chouki Tibermacine
email: chouki.tibermacine@lirmm.fr

Christophe Dony
email: dony@lirmm.fr

Ahmed Hadj Kacem
email: ahmed.hadjkacem@fsegs.rnu.tn

Automatic Translation of Architecture Constraint Specifications into Components

Keywords: Architecture Constraint, Component, Reusability, OCL

Architecture constraints are specifications defined by developers at design-time and checked on design artifacts (architecture descriptions, like UML models). They enable to check, after an evolution, whether an architecture description still conforms to the conditions imposed by an architecture pattern, style or any design principle. One possible language for specifying such constraints is the OMG's OCL. Most of these architecture constraints are formalized as "gross" specifications, without any structure or parameterization possibilities. This causes difficulties in their reuse. We propose in this work a process for translating architecture constraints into a special kind of components called constraint-components. This makes these specifications reusable (easily put and checked out in/from repositories), parametrizable (generic and applicable in different contexts) and composable with others. We implemented this process by considering the translation of OCL constraints into constraint-components described with an ADL called CLACS.

Introduction: Context and Problem Statement

Architecture constraints are specifications of invariants that are checked by analyzing architecture descriptions. This kind of constraints should not be confused with functional constraints, which are checked by analyzing the state of the running components constituting the architecture. For example, if we consider a UML model (an architecture description) containing a class Employee (a component in that architecture) which has an integer attribute age, a functional constraint presenting an invariant in this class could impose that the values of this attribute (slot of an object) must be included in the interval for all instances of this class. This kind of constraints is inherently dynamic. They can be checked only at runtime.

On the other side, architecture constraints are specifications where architecture descriptions, and not component states, are analyzed [START_REF] Tibermacine | Software Architecture 2, chapter Architecture Constraints[END_REF]. They define invariants imposed by the choice of a particular design principle, architectural style or pattern, like the layered architecture style [START_REF] Shaw | Software Architecture: Perspectives on an Emerging Discipline[END_REF], where "components in non-adjacent layers must not be directly connected together". This is an example of an architecture constraint. OCL [START_REF]OMG: Object Management Group. Object constraint language (ocl), v2.4, specification: Omg document formal/2014-02-03[END_REF] is an OMG standard which specify two types of constraints : functional (constraints navigate in UML models) and architectural (constraints navigate in MOF metamodels).

Functional constraints are used in Design by Contract for ensuring the definition of accurate and checkable interfaces for software components [START_REF] Meyer | Touch of Class[END_REF]. Architecture constraints are used during the evolution of a software architecture for guaranteeing that changes do not have bad side effects on the applied architecture patterns or styles, and thus on the quality [START_REF] Tibermacine | On-demand qualityoriented assistance in component-based software evolution[END_REF].

Many architecture constraints have been formalized for the existing architecture patterns proposed in the literature and practice of software engineering [START_REF] Zdun | A catalog of architectural primitives for modeling architectural patterns[END_REF][START_REF] Gamma | Design patterns: Elements of Reusable Object-Oriented Software[END_REF][START_REF] Buschmann | Pattern-Oriented Software Architecture[END_REF]. But unfortunately, most of them are "gross" textual specifications. They do not offer any structure. Therefore, it is difficult to reuse them in other/different contexts. This is the reason why we propose in this paper a process to transform them into more structured assets in order to facilitate their reuse. In addition, our experience with architecture constraint specification leads us to say that most of the time, architecture constraints are composed of many "independent" parts that are assembled together via logical operators. Some of these parts are shared between several architecture constraints and have their own semantics. The idea of this paper is to propose a way to build OCL basic constraints as entities embedded in a special kind of software components, that can be reused, assembled, composed into higher-level ones and customized using standard component-based techniques.

In this paper, we propose to translate automatically architecture constraints specified in design stage into "constraint-components". We propose a two-step process which takes as input a gross OCL architecture constraint specification expressed in the UML metamodel, and which provides as output constraintscomponents expressed with CLACS ADL. We propose to generate architecture constraints as "constraint-components" [START_REF] Tibermacine | Component-based specification of software architecture constraints[END_REF] so that we can put them on "shelves" and thereafter make them reusable, customizable and composable with others to produce more complex constraints.

The remaining of this paper is organized as follows. In the following section, we give an illustrative example of the input and the output of the proposed process. These will serve as running examples throughout the paper. In Section 3, we describe in detail the steps of our process. In Section 4, we expose an evaluation of the approach. Before concluding and presenting the future work, we discuss the related work in Section 5.

Illustrative Example

To better understand the context of this work, we introduce an example of an architecture constraint (Listing 1.1) enabling the checking of the topological conditions imposed by the "Service Bus Architecture Pattern" [START_REF] Chappell | Enterprise Service Bus: Theory in Practice[END_REF]. This pattern introduces three kinds of components: the customers, the producers and the bus. The bus is defined as an adapter that establishes the communication between customers and producers as they may have mismatching interfaces. The architecture constraint which specifies the conditions imposed by this pattern is expressed in OCL using the UML metamodel [START_REF] Tibermacine | Software Architecture 2, chapter Architecture Constraints[END_REF] in the following listing. A detailed specification of the UML component model is presented in [START_REF]OMG: Object Management Group. Unified modeling language (uml)[END_REF].

1 context Component inv :
2 l e t bus : Component 3 = s e l f . r e a l i z a t i o n . r e a l i z i n g C l a s s i f i e r When applying our proposed approach, we change the format of the constraint (Listing 1.1) from a textual "gross" specification into an architecture description made of "constraint-components" and "query-components". These components are described with an ADL named CLACS [START_REF] Tibermacine | Component-based specification of software architecture constraints[END_REF] (pronounced Klax).

By "gross" specification, we mean a specification that does not offer enough structure, reusability and parameterization.

In the literature, there are many languages enabling the specification of architecture constraints (see [START_REF] Tibermacine | Software Architecture 2, chapter Architecture Constraints[END_REF] for a survey). Each one has its advantages and its particular application context. However, CLACS is the only language that provides a component model for software architecture constraint specification. The architecture constraints modeled with this language are constraint-components in which the checked invariants are still specified using OCL. But these OCL constraints navigate in CLACS metamodel and not in the UML's one. The choice of UML is simply motivated by the fact that it is an industrial standard1 , and that OCL is its original constraint language. We can consider here a repository of architecture constraints that can be fed by the software architecture community, by using these general modeling languages, which are UML and OCL.

The result of our translation process is shown in Fig. 1. We notice the presence of two kinds of component descriptors (query and constraint). Query-components embed OCL definition constraints that return a value whose type is different from Boolean and constraint-components embed OCL definition constraints that return only Boolean values. Indeed, our architecture constraint specification will be decomposed in a set of OCL definition constraints and these constraints will be embedded in these two kinds of components to reuse them.

There are three let expressions in the architecture constraint (Listing 1.1). Each one (Lines 2 -5, 6 -11, 12 -17) is supposed to be defined basically in a separate query-component descriptor. But let expressions 2 and 3 are similar according to a similarity measure which is defined in the following section. That is why they are represented by only one query-component (ParticipantsIdentification).

There are five constraint-components on the right of the figure. These components represent the OCL definitions that are extracted from our initial constraint and then parametrized. These definitions are called throughout the constraint and they will potentially serve other constraints.

There are in total five sub-constraints in the architecture constraint (Listing 1.1). Each one (Lines 21 -22, 25 -27, 30 -36, 39 -41 and 44 -50) is supposed to be defined basically in a separate component descriptor. But in this example, sub-constraints 2 and 4 can be grouped in the same component descriptor (PortConstraint) because they check similar "aspects". They check if all the components in a given set of instances (customers in the first sub-constraint and producers in the second) have specific kinds of ports (input or output). PortConstraint descriptor provides two operations which enable the checking of these two sub-constraints. On the other side, sub-constraints 3 and 5 check exactly the same invariant (in contrast to sub-constraints 2 and 4), except that they apply on different sets of components (customers for sub-constraint 3 and producers for sub-constraint 5). Thus, there is a single component descriptor (ConnectToBusConstraint) which is generated for these two sub-constraints. This constraint-component provides a single operation which is parameterized with the set of components on which the constraint should be checked.

We can see (on the top of the figure) the constraint checked by the composite, in which there are five operation invocations to the three internal components (on the left of the figure). These internal components (that constitute our initial constraint) call the operations that are declared in the others components using the name of the provided port. These later descriptors will be registered in a repository and will be potentially useful for other constraints. In other words, for each new "gross" constraint specification to decompose, we will measure the similarity between the OCL definitions extracted from it i.e. after applying the decomposition and the paramterization (see Section 3, subsection 3.1), and the registered OCL definitions embedded in the components, According to the similarity result, we can reuse an existing OCL definition constraint and also modify it, if necessary.

For this example, we will obtain, in addition to the descriptor of the "main" component (BusPatternArchitecture), three constraint-component descriptors (instead of five) corresponding to our initial constraint. These three components are connected to the two query-components (BusIdentification and ParticipantsIdentification) and five other constraint-components. These query-components provide queries that are shared between the constraint-components.

Through this "componentization", CLACS constraint-component and querycomponent descriptors can be reusable (instantiated many times in different contexts), composable (instances of them can be connected together or connected within a composite component to build complex constraint-components) and parameterizable (to check that customers or producers are connected only to the bus, we can pass the right arguments to the operation of ConnectToBusConstraint descriptor).

In the following section, we describe in detail the steps of the constraint translation process illustrated with examples.

Transformation of constraints into components

Our process is composed of two main steps. The first one consists in extracting sub-constraints from the constraint. These sub-constraints will be specified as parametrized OCL definitions. The second step consists in embedding these generated OCL definitions into components in order to make them reusable. We will detail these two steps in the following subsections.

Note that OCL constraints are predicates in the first order logic. They have a simple and intuitive concrete syntax. Even if the transformations presented in this paper apply on OCL, the proposed work can be generalized to any equivalent predicate logic language. This is not demonstrated experimentally in our work, but as the reader can notice, the syntactic tokens handled in our transformations are general to predicate logic.

Constraint refactoring

We propose first to extract sub-constraints as OCL definitions and then we identify parameters for them and we will obtain at the end an invariant which uses these definitions. These definitions are parametrizable and will be registered in a repository to be used by other constraints. To obtain this new form of our invariant, we propose a multi-step transformation micro-process. All steps use as input the abstract syntax tree of the initial constraint.

Let expressions extraction Sometimes a sub-expression is used several times in an OCL constraint. The operator let allows to report and set the value (i.e initialize) a variable that can be used in the expression which follows the inv. def is a type of constraints which is used to declare and define the values of attributes or returned values of operations.

The first step in our approach is to extract the let expressions from our textual constraint specification and define them as constraints stereotyped with def. These OCL definition constraints must return a value whose type is different from Boolean. At the same time, we modify our textual constraint i.e, the constraint undergoes changes and call these generated OCL definitions in their appropriate places. At this level, our initial constraint will be as follows: Operands of these operators are considered here as sub-constraints. This set of sub-constraints is refined recursively into a tree of sub-constraints if these subconstraints can be decomposed again. The stopping condition of the recursion is that no logic operator is found in the sub-constraint. All these sub-constraints will be represented as OCL definition constraints. The refactoring of the constraint (i.e modification of the constraint invariant) is performed every time we generate a new definition. At this level we obtain a bag of OCL definition constraints that return a Boolean value. Listing 1.3 represents an excerpt of our constraint during the decomposition stage. 24 def : p a r t 4 ( ) : . . . 25 def : p a r t 5 ( ) : . . . 26 inv : 27 p a r t 1 ( ) and p a r t 2 ( ) and p a r t 3 ( ) and p a r t 4 ( ) and p a r t 5 ( ) Listing 1.3. Bus architecture pattern Constraint during the decomposition stage In Listing 1.3, the constraint is composed of five "main" OCL sub-constraints (part1(), part2(), part3(), part4() and part5()). These sub-constraints can be decomposed again into other sub-constraints due to the recursive process 2 . For instance def4() contains the operator or, so it will be decomposed again. All these sub-constraints are defined as OCL definitions (def:) presented before the inv:. We can observe that there are some OCL definitions that have parameters. The reason to make some parameters at this stage (the decomposition) is to have the possibility to define all the generated OCL definitions with the same context as that of the constraint (Line 1). Redundancy removal After the constraints decomposition, we obtain a bag of OCL definitions. In this step, we remove all redundant definitions and then we update the constraint. For instance, in Listing 1.3 def1() and def3() are syntactically identical. Now we have a set of OCL definition constraints that constitute our textual constraint.

1 context Component
Constraint Parameterization When creating the signature of the operation that wraps a constraint, we add a parameter in this signature everywhere we find a literal value of a given data type. The type of these parameters is obtained from the abstract syntax tree of the constraint. For instance def2() in Listing 1.3 will be defined as follows: In this stage, we need to measure the similarity between the OCL definitions. This measure allows to optimize our process, i,e. remove some redundant OCL definitions (obtained in the parametrization stage). For example def4() in Listing 1.3 will be defined at this stage as follows: We remark that def2() (see Listing 1.4), def17(), def18() and def19() are similar. They are different only by the name of the parameter (the same type of the parameter). Then, we remove def17(), def18() and def19() and replace them by def2() presented in Listing 1.4. We also optimize the def4() definition which will take as parameter c:Classifier and consumersNames:Set(String). This is performed when comparing the OCL expressions before the "=" (c.name) in each literal value. This comparison is done using the AST of the OCL constraint. Concerning how we measured the similarity between OCL definitions, we implemented an automated process by analyzing the abstract syntax trees of definitions body. Each pair of trees is compared. These should share a common root and a minimal sub-tree (obtained in a breadth-first traversal). This ensures, to some extent, that constraints define predicates on the same kind of architectural elements, which are obtained through navigations in the OCL definition (reflected by these sub-trees). For the remaining sub-tree, an edit distance [START_REF] Tai | The tree-to-tree correction problem[END_REF] is measured between each pair of sub-trees. If this measure is less than a threshold3 , we consider that the two definitions are similar.

At the end of this step, our invariant is completely decomposed in OCL definition constraints. These constraints will be registered in a repository in order to reuse them to create others constraint specifications.

Constraint transformation into CLACS components

In this section, we describe the transformation of OCL definitions generated in the first step into CLACS components. A CLACS component is an instance of a component descriptor (like an object is an instance of a class). A component has a name, a description and a kind (business or constraint). It declares ports, which are characterized by a direction (required or provided) and a visibility (internal or external). Each port has an interface which specifies a set of operation signatures. Ports are linked via connectors. A connector receives operation invocations through its source port and transmits them through its target port. In our work, we focus on components of kind "constraint" and "query", interfaces and connectors of kind "constraintChecking" and "constraintEvaluation". For generating CLACS components, we proposed a multi-step transformation micro-process:

Operation grouping Each CLACS query-component descriptor will embed an OCL definition which returns a value whose type is different from Boolean and each CLACS constraint-component will embed an OCL definition which returns only boolean values. From the other side, among the generated OCL definitions, each one that corresponds to a let in the constraint (Subsection 3.1, like letConsumers()) will be embedded in a query-component descriptor and each one among the others will be embedded in a constraintcomponent. In this case, we can obtain a large number of components. Therefore, we propose to put together OCL definitions that check similar "aspects" in the same component descriptors. By checking similar aspects, we mean checking the connection, testing the kind, or some other property of a given architectural element (a port or a connector for example). For that we use the same technique of similarity measurement described before (Subsection 3.1, step Constraints Parametrization). For example, the OCL definitions part2() and part4() check the same aspect which is the kind of an architectural element (a Port). The two trees of these two sub-constraints have a common root which is a component and a common sub-tree generated from the expression .ownedPort->includes(p1,p2:Port| ). For the remaining sub-trees generated from the remaining expressions of the two sub-constraints, we can observe that there is a similarity between them (only two edit operations (node substitutions): required and provided tokens are inverted). So these are grouped as two operations in the same component descriptor.

Metamodel migration

In this step, we transform constraint navigations written in OCL/UML into OCL/CLACS. This is performed using a simple set of declarative mappings that we have specified between the two metamodels (UML and CLACS). These have been defined using the same template as in [START_REF] Tibermacine | Simplifying transformations of architectural constraints[END_REF]. For reasons of space limitation, we do not show these mappings. But note that, the self keyword4 is replaced by context, which is resolved to an implicit required port connected to a meta-descriptor of the business component on which the constraint is checked. This connection resolution is made (lazily) when the checking is launched.

CLACS architecture description generation Starting from the tree obtained in the first step, a component-based architecture description in CLACS is generated. This architecture description contains all the necessary constraintcomponents and query-components (instances) connected together. These components embed the refactored5 architecture constraints that navigate henceforth in CLACS metamodel.

Process Evaluation

We collected 25 architecture patterns characterized by their architecture constraints. In order to measure the reusability obtained in the result of our transformation process, we choose the metric proposed by Gaffney and Durek in [START_REF] John | Software reusekey to enhanced productivity: some quantitative models[END_REF]. This metric is defined as follows:

C = b + E n -1 R + 1
where:

-C: is the cost of software development (specification of an architecture constraint) b: is the cost of integrating the reused elements into the new artifact (integration of constraint-components in a composite) -E: is the cost of developing a reusable element (a constraint-component) n: is the number of uses of reused elements -R: is the proportion of reused elements C is an important indicator of the effectiveness of the reuse obtained in the final result of our transformation process. If there is no reuse at all, C is equal to 1. The more effective the reuse is, the less C is. b and E relate to the estimated cost of incorporating and developing, respectively, the reused elements. b is supposed to be greater than 0 because it always takes effort to reuse an element. E is supposed to be greater than 1 because the creation of a reusable element requires an extra effort. E is the sum of the costs of developing a new element (without reuse support) and reusing elements. For our experiment, R represents the proportion of the patterns (constraint's) structure which is reused to construct other patterns (constraints). R is the number of the reused constraints divided by the total number of constraints in the same pattern. As we can observe, the R value is in the range 20-100. We can also observe that there are 13 (out of 25) patterns having 100 % of their structure reused elsewhere. This reinforces our idea to transform architectural constraints into a reusable structure.

Another value that we have measured is n, which represents how many times a structure is reused in the whole set of evaluated constraints. Fig. 3 depicts the frequency of reusable constraints in each pattern. This demonstrates the potential to promote the reusability of pattern structure in the construction of a pattern library. We can see in Fig. 3 that the pattern P8 is composed of constraint-components that are reused 55 times by other patterns. We have six patterns that have a reusable structure called more than 50 times. b and E are difficult to measure because of various reasons as explained in [START_REF] Frakes | Software reuse: metrics and models[END_REF]. We take the b and E values estimated by [START_REF] Favaro | What price reusability?: a case study[END_REF] since our evaluation falls into the polylithic category 6 . Thus, b and E are equal to 0.15 and 1.2 respectively in our experiment. Fig. 4 shows the cost of constructing the 25 patterns. C is in the range of 18 to 89. As we can observe, all of the patterns have a cost less than 1 which means that the obtained reuse really has an effect in reducing pattern construction cost.

Related works

Works related to our approach can be classified in different categories: i) languages and tools for the specification of architecture constraints, ii) techniques for predicate/constraint transformations, iii) techniques for OCL constraints refactoring and iv) methods for constraint reuse.

A state of the art on languages used for the specification of architecture constraints at design and at implementation stages is given in [START_REF] Tibermacine | Software Architecture 2, chapter Architecture Constraints[END_REF]. These languages vary from embedded notations in existing ADLs, like Armani [START_REF] Monroe | Capturing software architecture design expertise with armani[END_REF] for Acme [START_REF] Garlan | Acme: Architectural description of component-based systems[END_REF], to notations with a logic programming style, like LogEn [START_REF] Eichberg | Defining and continuous checking of structural program dependencies[END_REF] or Spine [START_REF] Blewitt | Automatic verification of design patterns in java[END_REF], or notations with (or for) object-oriented programming style, like CDL [START_REF] Klarlund | Formal design constraints[END_REF]or SCL [START_REF] Hou | Using scl to specify and check design intent in source code[END_REF]. In practice there are several tools for static code quality analysis that enable the specification of architecture constraints, like Sonar (http://www.sonarqube. org/), Lattix (http://lattix.com/),among others. All these languages and tools do not provide any way for transforming or generating code starting from specifications in OCL or any other predicate language. In addition, they provide either no or a limited parameterization and reusability of architecture constraints. Hassam et al. [START_REF] Hassam | Adapting ocl constraints after a refactoring of their model using an mde process[END_REF] proposed a method for transforming OCL constraints during UML model refactoring, using model transformations. Their approach uses first an annotation method for marking the initial UML model in order to obtain an annotated target model. Then, a mapping table is created from these two annotations in order to use it for transforming OCL constraints of the initial model into OCL constraints of the target one. Their solution of constraint transformation cannot be used straightforwardly because it needs some knowledge about model transformation languages and tools. In our work, constraint transformation is performed in a simple an ad-hoc way without using additional modeling and transformation languages. In [START_REF] Ferdjoukh | A csp approach for metamodel instantiation[END_REF], the authors propose an approach for generating (instantiate) models from metamodels taking into account OCL constraints. Their approach is based on CSP (Constraint Satisfaction Problem). They defined some formal rules to transform models and constraints associated to them. Cabot et al. [START_REF] Cabot | Umltocsp: a tool for the formal verification of uml/ocl models using constraint programming[END_REF] worked also on UML/OCL transformation into CSP in order to check quality properties of models. These approaches are similar to our transformation process since the transformed/handled artifacts are the same (OCL specifications and metamodels). They use the same OCL compiler as us (DresdenOCL [START_REF] Demuth | The dresden ocl toolkit and its role in information systems development[END_REF]) to analyze constraints. In contrast to CSP, this does not require an external tool for the interpretation of constraints. In addition, in our approach, we transform only constraints. In the other approaches, everything should be transformed into a CSP to be solved (the constraints + the models/metamodels). Moreover, Bajwa and Lee presented in [START_REF] Imran | Transformation rules for translating business rules to ocl constraints[END_REF] a two-step process for transforming SBVR rules (Semantics of Business Vocabulary and Business Rules) into OCL constraints. The first step consists in realizing a mapping between SBVR rules elements and UML model elements. This step ensures that the OCL constraint that will be generated is semantically checkable in a UMl model. The second step consists in transforming an OCL model instance from SBVR model instance using a mapping between the two metamodels (OCL and SBVR). This paper uses model transformations techniques. Their process is troublesome when the constraints have a gross specification (very large models). The generated constraints are complex, not reusable and parametrizable.

OCL refactoring consists in simplifying the constraints and making them more expressive. In [START_REF] Correa | Refactoring to improve the understandability of specifications written in object constraint language[END_REF], Correa et al. have as goal to improve the readability and the comprehensibility of the constraint. Therefore, they prepared a catalog of smells. They proposed refactorings for removing a given smell in the constraint. It is true that this refactoring allows a greater comprehensibility of the constraints (validation in the paper) but these do not consider reuse. Besides, the authors consider in their approach only the functional constraints and not architectural ones. In [START_REF] Reimann | Tool supported ocl refactoring catalogue[END_REF], Reimann et al. complete the previous work of Correa et al., they proposed new smells and new refactorings like a decomposition of OCL constraints in atomic sub-constraints. These new refactorings does not address the parameterization of the constraint which enables more reuse.

In [START_REF] Chimiak-Opoka | Ocllib, oclunit, ocldoc: pragmatic extensions for the object constraint language[END_REF], Chimak-Opoka proposed a library OCLLib which contains a group of valid OCL constraints. The main objective of this library is to offer a set of OCL constraints that are reliable, tested and can be reusable. But, no method explain how to make the constraints customizable is presented. In [START_REF] Minh | Catalogue of architectural patterns characterized by constraint components[END_REF], Ton That et al. proposed a catalog of architecture pattern as constraint-components. They defined for each pattern its architectural constraints, they decomposed the constraints manually and embarked them in components. The componentconstraints built are reusable and parametrizable. In our approach, we realized these transformations automatically and we use the result of this paper as an oracle for our experimentation.

Conclusion and Future work

Architecture constraints are predicates that bring a valuable help for preserving architecture styles, patterns or general design principles in a given application after having evolved its architecture description. Such kind of specifications is subject to reuse. They are frequently assembled together to build more complex architecture constraints [START_REF] Tibermacine | Component-based specification of software architecture constraints[END_REF]. We have presented in this paper a process for translating architecture constraints into components. Our process is composed of two main steps. The first one consists in describing OCL constraints, extracted from "gross" textual constraint specifications, as OCL definitions. The second step consists in generating automatically constraint-components from these definitions. These components provide operations for checking the constraints. They are specified in an ADL named CLACS.

As a future work, we plan to make these generated constraint-components checkable in the implementation stage on component-based programs. We would like to automatically translate these constraint-components into checkable descriptors at runtime.

4 -Listing 1 . 1 .

 411 > s e l e c t ( c : C l a s s i f i e r | c . o c l I s K i n d O f ( Component ) 5 and c . oclAsType ( Component ) . name=' esbImpl ' ) 6 c u s t o m e r s : S e t ( Component ) 7 = s e l f . r e a l i z a t i o n . r e a l i z i n g C l a s s i f i e r 8 -> s e l e c t ( c : C l a s s i f i e r | c . o c l I s K i n d O f ( Component ) 9 and ( c . oclAsType ( Component ) . name=' c u s t 1 ' or c . oclAsType ( Component ) . name=' c u s t 2 ' or c . oclAsType ( Component ) . name=' c u s t 3 ' ) ) p r o d u c e r s : S e t ( Component ) = s e l f . r e a l i z a t i o n . r e a l i z i n g C l a s s i f i e r -> s e l e c t ( c : C l a s s i f i e r | c . o c l I s K i n d O f ( Component ) and ( c . oclAsType ( Component ) . name= ' prod1 ' or c . oclAsType ( Component ) . name=' prod2 ' or c . oclAsType ( Component ) . name=' prod3 ' ) ) i n --The bus s h o u l d have a t l e a s t one i n p u t p o r t --and one o u t p u t p o r t bus . ownedPort->e x i s t s ( p1 , p2 : P o r t | p1 . p r o v i d e d ->notEmpty ( ) and p2 . r e q u i r e d ->notEmpty ( ) ) and --Customers s h o u l d have o u t p u t p o r t s o n l y c u s t o m e r s ->f o r A l l ( c : Component | c . ownedPort->f o r A l l ( r e q u i r e d ->notEmpty ( ) and p r o v i d e d ->isEmpty ( ) ) ) and --Customers s h o u l d be c o n n e c t e d t o t h e bus o n l y c u s t o m e r s ->f o r A l l ( com : Component | com . p o r t ->f o r A l l ( p : P o r t | p . end->notEmpty ( ) i m pl i es s e l f . ownedConnector -> e x i s t s ( con : C o n n e c t o r | bus . ownedPort->e x i s t s ( pb : P o r t | con . end . r o l e ->i n c l u d e s ( pb ) ) and con . end->i n c l u d e s ( p . end ) ) ) ) and --P r o d u c e r s s h o u l d have i n p u t p o r t s o n l y p r o d u c e r s ->f o r A l l ( c : Component | c . ownedPort->f o r A l l ( p r o v i d e d ->notEmpty ( ) and r e q u i r e d ->isEmpty ( ) ) ) and --P r o d u c e r s s h o u l d be c o n n e c t e d t o t h e bus o n l y p r o d u c e r s ->f o r A l l ( com : Component | com . p o r t ->f o r A l l ( p : P o r t | p . end->notEmpty ( ) i m pl i es s e l f . ownedConnector->e x i s t s ( con : C o n n e c t o r | bus . ownedPort->e x i s t s ( pb : P o r t | con . end . r o l e ->i n c l u d e s ( pb ) ) and con . end->i n c l u d e s ( p . end ) ) ) ) Bus architecture pattern constraint in OCL/UML

Fig. 1 .

 1 Fig. 1. Sample of approach results

2 -Listing 1 . 2 .

 212 -l e t e x p r e s s i o n s e x t r a c t i o n 3 def : l e t B u s ( ) : Component = s e l f . r e a l i z a t i o n . 4 r e a l i z i n g C l a s s i f i e r ->s e l e c t ( c : C l a s s i f i e r | c . o c l I s K i n d O f ( Component ) 5 and c . oclAsType ( Component ) . name = ' esbImpl ' ) 6 def : l e t C u s t o m e r s ( ) : S e t ( Component ) = s e l f . r e a l i z a t i o n . 7 r e a l i z i n g C l a s s i f i e r ->s e l e c t ( c : C l a s s i f i e r | c . o c l I s K i n d O f ( Component ) 8 and ( c . oclAsType ( Component ) . name = ' c u s t 1 ' or 9 c . oclAsType ( Component ) . name = ' c u s t 2 ' or c . oclAsType ( Component ) . name = ' c u s t 3 ' ) ) def : l e t P r o d u c e r s ( ) : . . . inv : l e t B u s ( ) . ownedPort ->i n c l u d e s ( p1 , p2 : P o r t | p1 . p r o v i d e d ->notEmpty ( ) and p2 . r e q u i r e d ->notEmpty ( ) ) and l e t C u s t o m e r s ( )->f o r A l l ( c : Component | c . ownedPort ->f o r A l l ( r e q u i r e d ->notEmpty ( ) and p r o v i d e d ->isEmpty ( ) ) ) and . . . and . . . and . . . Constraint after extracting let expressions Constraint decomposition Second, we decompose automatically the obtained constraint into a set of sub-constraints. This decomposition is primary based on logical operators used at the top level (Lines 15, 18, 19 and 20 in Listing 1.2).

1

 1 context Component 2 def : d e f 1 ( c : C l a s s i f i e r ) : Boolean = c . o c l I s K i n d O f ( Component ) 3 def : d e f 2 ( c : C l a s s i f i e r ) : Boolean = c . oclAsType ( Component ) . name 4 = ' esbImpl ' 5 def : l e t B u s ( ) : Component = s e l f . r e a l i z a t i o n . r e a l i z i n g C l a s s i f i e r 6 -> s e l e c t ( c : C l a s s i f i e r | d e f 1 ( c ) and d e f 2 ( c ) ) 7 def : d e f 3 ( c : C l a s s i f i e r ) : Boolean = c . o c l I s K i n d O f ( Component ) 8 def : d e f 4 ( c : C l a s s i f i e r ) : Boolean = c . oclAsType ( Component ) . name 9 = ' c u s t 1 ' or c . oclAsType ( Component ) . name = ' c u s t 2 ' or c . oclAsType ( Component ) . name = ' c u s t 3 ' def : l e t C u s t o m e r s ( ) : S e t ( Component ) = s e l f . r e a l i z a t i o n . r e a l i z i n g C l a s s i f i e r ->s e l e c t ( c : C l a s s i f i e r | d e f 3 ( c ) and d e f 4 ( c ) ) . . . def : p a r t 1 ( ) : Boolean = l e t B u s ( ) . ownedPort ->i n c l u d e s ( p1 , p2 : P o r t | d e f 7 ( p1 ) and d e f 8 ( p2 ) ) def : p a r t 2 ( ) : . . . def : d e f 1 1 ( p : P o r t ) : Boolean = p . end->notEmpty ( ) def : d e f 1 2 ( p : P o r t ) : Boolean = s e l f . ownedConnector 19 -> e x i s t s ( con : C o n n e c t o r | l e t B u s ( ) . ownedPort -> e x i s t s ( pb : P o r t | 20 con . end . r o l e ->i n c l u d e s ( pb ) ) and con . end ->i n c l u d e s ( p . end ) ) 21 def : p a r t 3 ( ) : Boolean = l e t C u s t o m e r s ( ) 22 ->f o r A l l ( com : Component | com . p o r t 23 ->f o r A l l ( p : P o r t | d e f 1 1 ( p ) i mp l i es d e f 1 2 ( p ) ) )

context

  Component def : d e f 2 ( c : C l a s s i f e r , name : S t r i n g ) : Boolean = c . oclAsType ( Component ) . name = name Listing 1.4. OCL definition constraint paramatrizable

  context Component def : d e f 1 7 ( c : C l a s s i f i e r , name1 : S t r i n g ) : Boolean = c . oclAsType ( Component ) . name = name1 def : d e f 1 8 ( c : C l a s s i f i e r , name2 : S t r i n g ) : Boolean = c . oclAsType ( Component ) . name = name2 def : d e f 1 9 ( c : C l a s s i f i e r , name3 : S t r i n g ) : Boolean = c . oclAsType ( Component ) . name = name3 def : d e f 4 ( c : C l a s s i f i e r , name1 : S t r i n g , name2 : S t r i n g , name3 : S t r i n g ) : Boolean = d e f 1 7 ( c , name1 ) and d e f 1 8 ( c , name2 ) and d e f 1 9 ( c , name3 ) .

Listing 1 . 5 .

 15 Example of parametrization2 In Listing 1.3, the decomposition is stopped in part4()

Fig. 2 .

 2 Fig. 2. R values for all patterns

Fig. 3 .

 3 Fig. 3. n values for all patterns

Fig. 4 .

 4 Fig. 4. C values for all patterns

Even if a recent empirical study[START_REF] Petre | Uml in practice[END_REF] found out that UML is not fully (but selectively) used by developers in industry, and that it is used informally, there is a general agreement that UML is the de facto standard modeling language known by a large number of developers.

The value of this threshold will be fixed empirically.

self is located in the initial constraint written in UML metamodel

A constraint is refactored when the different steps described above have been applied on it.

This category concerns structures that can be divided into individual parts and each of them can be independently manipulated.


Stéphane Girard
email: stephane.girard@inrialpes.fr

Séphane Girard

Pierre Jacob
email: jacob@math.univ-montp2.fr

Frontier estimation via

Keywords: kernel estimator, power-transform, frontier estimation AMS 2000 subject classification: 62G05, 62G07, 62G20

come

Introduction

Let (X i , Y i ), i = 1, . . . , n be independent copies of a random pair (X, Y ) with support S defined by S = {(x, y) ∈ E × R; 0 ≤ y ≤ g(x)}.

(

) 1
The unknown function g : E → R is called the frontier. We address the problem of estimating g in the case E = R d . Our estimator of the frontier is based on a kernel regression on the powertransformed data. More precisely, the estimator of g is defined for all x ∈ R d by ĝn (x) = (p + 1)

n i=1 K h (x -X i )Y p i n i=1 K h (x -X i ) 1/p , (2)
where p = p n and h = h n are non random sequences such that h → 0 and p → ∞ as n → ∞.

This latter condition is the key so that the high power-transformed data "concentrate" along the 1 frontier. We have also introduced K h (t) = K(t/h)/h d where K is a probability density function (pdf) on R d . In this context, h is called the window-width.

From the practical point of view, note that, compared to the extreme value based estimators [START_REF] Gardes | Estimating the support of a Poisson process via the Faber-Shauder basis and extreme values[END_REF][START_REF] Geffroy | Sur un problème d'estimation géométrique[END_REF][START_REF] Girard | Extreme values and Haar series estimates of point process boundaries[END_REF][START_REF] Girard | Projection estimates of point processes boundaries[END_REF][START_REF] Girard | Central limit theorems for smoothed extreme value estimates of point processes boundaries[END_REF][START_REF] Girard | Extreme values and kernel estimates of point processes boundaries[END_REF], projection estimators [START_REF] Jacob | Estimating the edge of a Poisson process by orthogonal series[END_REF] or piecewise polynomial estimators [START_REF] Korostelev | Minimax theory of image reconstruction[END_REF][START_REF] Korostelev | Efficient estimation of monotone boundaries[END_REF][START_REF] Härdle | Estimation of a non sharp support boundaries[END_REF], this estimator does not require a partition of S and is thus not limited to bi-dimensional bounded supports. Moreover, it benefits from an explicit formulation which is not the case of estimators defined by optimization problems [START_REF] Girard | L 1 -optimal nonparametric frontier estimation via linear programming[END_REF] such as local polynomial estimators [START_REF] Hall | On polynomial estimators of frontiers and boundaries[END_REF][START_REF] Hall | Bandwidth choice for local polynomial estimation of smooth boundaries[END_REF][START_REF] Knight | Limiting distributions of linear programming estimators[END_REF]. From the theoretical point of view, this estimator reveals to be completely convergent to g without assumption neither on the distribution of X nor on the distribution of Y given X = x (see Section 3). Note however that (p + 1) 1/p → 1 when p → ∞. In fact, this correcting term is specially designed for the case where Y given X = x is uniformly distributed on [0, g(x)]. In this latter situation, the estimator is asymptotically Gaussian with the rate of convergence n -α/(d+α)

(see Section 4). This rate is proved to be minimax optimal for α-Lipschitzian d-dimensional frontiers [START_REF] Korostelev | Minimax theory of image reconstruction[END_REF], Chapter 5. This result is generalized in [START_REF] Mammen | Asymptotical minimax recovery of set with smooth boundaries[END_REF] to boundaries of more general regions.

Other extensions are provided in [START_REF] Hall | On the estimation of a support curve of indeterminate sharpness[END_REF][START_REF] Härdle | Estimation of a non sharp support boundaries[END_REF] to densities of Y given X = x decreasing as a power of the distance from the boundary. We refer to [START_REF] Deprins | Measuring labor efficiency in post offices[END_REF][START_REF] Farrel | The measurement of productive efficiency[END_REF][START_REF] Gijbels | On estimation of monotone and concave frontier functions[END_REF] for the estimation of frontier functions under monotonicity assumptions, and to [START_REF] Aragon | Nonparametric frontier estimation: a conditional quantile-based approach[END_REF][START_REF] Cazals | Nonparametric frontier estimation: A robust approach[END_REF] for the definition of robust estimators in this context.

We conclude this paper by an illustration of the behavior of our estimator on some finite sample situations in Section 5 and by describing our future work in Section 6. Technical lemmas are postponed to the appendix.

Notations and assumptions

To motivate the estimator [START_REF] Bosq | Théorie de l'estimation fonctionnelle. Economie et Statistiques avancées[END_REF], consider the random variable Z = (p + 1)Y p and the conditional expectation r n (x) = E(Z|X = x). Estimating the frontier g is often related to estimating the regression function r n . For instance, if Y given X = x is uniformly distributed on [0, g(x)], we have r

1/p n (x) = g(x)
. A similar remark is done in [START_REF] Jacob | Regression and edge estimation[END_REF] where regression estimators are modified to build estimators of the frontier, but the profound difference here is that p → ∞. This condition allows to obtain r 1/p n (x) → g(x) even when Y given X = x is not uniformly distributed (see Lemma 1 below). We denote by f the pdf of the random vector X and we introduce φn

(x) = 1 n n i=1 K h (x -X i )Z i , (3)
where Z i = (p + 1)Y p i . Note that φn (x) can be seen as a classical kernel estimator of

ϕ n (x) = f (x)r n (x) but keep in mind that p → ∞. Similarly, fn (x) = 1 n n i=1 K h (x -X i ) (4)
is an estimator of f (x) and rn (x) = φn (x)/ fn (x) [START_REF] Deprins | Measuring labor efficiency in post offices[END_REF] is an estimator of r n (x). Collecting (3), ( 4) and ( 5), our estimator (2) can be rewritten as ĝn (x) = rn (x) 1/p .

To establish the asymptotic properties of ĝn (x), the following assumptions are considered:

(A.1): g is α-Lipschitz, f is β-Lipschitz, with 0 < α ≤ β ≤ 1, (A.2): 0 < g min ≤ g(x), ∀x ∈ R d , (A.3): f (x) ≤ f max < ∞, ∀x ∈ R d , (A.4): K is a Lipschitzian pdf on R d , with support included in B, the unit ball of R d .
Note that (A.4) implies that, for all q ≥ 1, we have 0 < B K q (x)dx < +∞.

Complete convergence

In this section, the complete convergence of the frontier estimator toward the true frontier is established. The next lemma can be seen as the intuitive justification why no assumption on the conditional distribution of Y given X is required in the proof of Theorem 1.

Lemma 1 Under (A.2), for all x ∈ B, r n (x) 1/p → g(x)
as n → ∞.

Proof : Let ε > 0. Since (X, Y ) has support S defined by [START_REF] Aragon | Nonparametric frontier estimation: a conditional quantile-based approach[END_REF], it follows that

r n (x) = (p + 1)E (Y p |X = x) ≤ (p + 1)g p (x)
and thus, since (p + 1) 1/p → 1 as p → ∞, for n large enough and all x ∈ B,

r 1/p n (x) ≤ (1 + ε)g(x). (6)
Moreover, we have,

r n (x) ≥ (p + 1)E (Y p 1{Y > g(x) -ε}|X = x) ≥ (p + 1)(g(x) -ε) p P(Y > g(x) -ε|X = x).
Now, since (X, Y ) has support S, one can assume without loss of generality that Y given X = x has support [0, g(x)] such that P(Y > g(x) -ε|X = x) > 0. It follows that

[(p + 1)P(Y > g(x) -ε|X = x)] 1/p → 1
as p → ∞, and consequently, for n large enough,

r 1/p n (x) ≥ (1 -ε)g(x). (7)
Collecting ( 6) and [START_REF] Farrel | The measurement of productive efficiency[END_REF] gives the result.

Theorem 1 Suppose (A.1)-(A.4) hold and nh d / log n → ∞. Then g n (x) converges completely to g(x) for all x ∈ R d such that f (x) > 0.

Proof : Let x ∈ R d such that f (x) > 0 and let ε such that 0 < ε < g(x). Define 0 < η < 1/4 by η = ε/(4g(x)). Then, from Lemma 6,

{| g n (x) -g(x)| > ε} = r 1/p n (x) g(x) -1 > 4η ⊆ ϕ n (x) f (x)g p (x) 1/p -1 > η ∪    fn (x) f (x) 1/p -1 > η    .
Since fn (x) converges completely to f (x), see e.g. [START_REF] Bosq | Théorie de l'estimation fonctionnelle. Economie et Statistiques avancées[END_REF], Chapter 4, Theorem III.3, it follows that ( fn (x)/f (x)) 1/p converges completely to 1. Therefore, writing

ϕ n (x) f (x)g p (x) 1/p = (p + 1) 1/p T n (x) with T n (x) = 1 n n i=1 K h (x -X i ) Y i g(x) p 1 f (x) 1/p
and remarking that (p + 1) 1/p → 1 as n → ∞, it suffices to consider

{|T n (x) -1| > η} ⊆ {T n (x) > 1 + η} ∪ {T n (x) < 1 -η} .
The two events are studied separately. First, let 0 < δ < η. Then, x -X i ≤ h entails

Y i -g(x)(1 + δ) ≤ g(X i ) -g(x) -δg(x) ≤ L g h α -δg min < 0
for n large enough and where L g is the Lipschitz constant associated to g. We thus have

T n (x) = 1 n n i=1 K h (x -X i ) Y i g(x) p 1{Y i < g(x)(1 + δ)} 1 f (x) 1/p ≤ (1 + δ) 1 n n i=1 K h (x -X i )1{Y i < g(x)(1 + δ)} 1 f (x) 1/p
, and consequently,

{T n (x) > 1 + η} ⊆ 1 n n i=1 K h (x -X i )1{Y i < g(x)(1 + δ)} 1 f (x) > 1 + η 1 + δ p ⊆ 1 n n i=1 K h (x -X i )1{Y i < g(x)(1 + δ)} 1 f (x) > 2 ,
since, for n large enough, ((1 + η)/(1 + δ)) p > 2. From [START_REF] Bosq | Théorie de l'estimation fonctionnelle. Economie et Statistiques avancées[END_REF], Chapter 5, Corollary II.4, the following complete convergence holds:

1 n n i=1 K h (x -X i )1{Y i < g(x)(1 + δ)} 1 f (x) c -→ P(Y < g(x)(1 + δ)|X = x) = 1,
and therefore

∞ n=1 P(T n (x) > 1 + η) ≤ ∞ n=1 P 1 n n i=1 K h (x -X i )1{Y i < g(x)(1 + δ)} 1 f (x) -1 > 1 < +∞,
which concludes the first part of the proof. Second,

T n (x) ≥ 1 n n i=1 K h (x -X i ) Y i g(x) p 1{Y i > g(x)(1 -δ)} 1 f (x) 1/p ≥ (1 -δ) 1 n n i=1 K h (x -X i )1{Y i > g(x)(1 -δ)} 1 f (x) 1/p
, and consequently,

{T n (x) < 1 -η} ⊆ 1 n n i=1 K h (x -X i )1{Y i > g(x)(1 -δ)} 1 f (x) < 1 -η 1 -δ p .
Now, since P(Y > g(x)(1 -δ)|X = x) > 0, there exists γ > 0 such that, for n large enough,

1 -η 1 -δ p -P(Y > g(x)(1 -δ)|X = x) < -γ,
entailing that, for n large enough,

{T n (x) < 1-η} ⊆ 1 n n i=1 K h (x -X i )1{Y i > g(x)(1 -δ)} 1 f (x) -P(Y /g(x) > 1 -δ|X = x) < -γ .
Taking into account of the following complete convergence

1 n n i=1 K h (x -X i )1{Y i > g(x)(1 -δ)} 1 f (x) c -→ P(Y > g(x)(1 -δ)|X = x), it follows that ∞ n=1 P(T n (x) < 1 -η) ≤ ∞ n=1 P 1 n n i=1 K h (x -X i )1{Y i > g(x)(1 -δ)} 1 f (x) -P(Y > g(x)(1 -δ)|X = x) < -γ < +∞,
which concludes the second part of the proof.

Asymptotic normality

Second, the asymptotic normality of the frontier estimator centered on the true frontier is established. To this end, asymptotic expansions of the expectation and variance of φn (x) are needed.

These calculations are done under the additional assumption

(A.5): Y given X = x is uniformly distributed on [0, g(x)].
The next two lemmas are similar to classical ones in kernel regression (see for instance [START_REF] Ferraty | Nonparametric modelling for functional data[END_REF], Theorem 6.11), but the dependence on n of the function ϕ n (x) induces technical difficulties. We first establish that ϕ n (x) is an asymptotically unbiased estimator of ϕ n (x) in the sense that

E ϕ n (x)/ϕ n (x) → 1 as n → ∞ provided that ph α → 0. Lemma 2 Under (A.1)-(A.5), if ph α → 0, then for all x ∈ R d E ϕ n (x) = ϕ n (x) [1 + O(ph α )] .
Proof : From (3), it follows that

E ϕ n (x) = E(K h (x -X)Z) = E(K h (x -X)E(Z|X)),
so that, by a straightforward calculation, and recalling that ϕ n (u) = g p (u)f (u), we obtain

E ϕ n (x) = E(K h (x -X)g p (X)) = R d 1 h d K x -u h ϕ n (u)du (8) = B K(y)ϕ n (x -hy)dy,
with a classical change of variable, and since K has a compact support. We thus can write:

E ϕ n (x) -ϕ n (x) = B K(y) [ϕ n (x -hy) -ϕ n (x)] dy.
Consider now the decomposition below:

|ϕ n (x -hy) -ϕ n (x)| ≤ f (x -hy) |g p (x -hy) -g p (x)| + g p (x) |f (x -hy) -f (x)| := T 1 + T 2 .
Following Lemma 5,

T 1 = f (x -hy)g p (x) g p (x -hy) g p (x) -1 ≤ 2f max L g g min g p (x)ph α = g p (x)O(ph α ), T 2 ≤ g p (x)L f h β = g p (x)O(h β ) = g p (x)o(ph α ),
where L f and L g are the Lipschitz constants of the functions f and g. Finally,

E ϕ n (x) -ϕ n (x) = g p (x)O(ph α ) = ϕ n (x)O(ph α ),
and the conclusion follows.

Similarly, we now provide an equivalent expression for V( ϕ n (x)/ϕ n (x)) which appears to be of order p/(nh d ). Thus, condition p/(nh d ) → 0 will be necessary in Corollary 1 to obtain the weak consistency of ϕ n (x), i.e. to ensure that ϕ n (x)/ϕ n (x)

P → 1. Lemma 3 Under (A.1)-(A.5), if ph α → 0 then for all x ∈ R d , V( ϕ n (x)) = 1 nh d (p + 1) 2 2p + 1 B K 2 (s)ds ϕ 2 n (x) f (x) [1 + o(1)] .
Proof : We have

V( ϕ n (x)) = 1 n 2 n i=1 V (K h (x -X i )Z i ) = 1 n V (K h (x -X)Z) = 1 nh 2d E K 2 x -X h Z 2 - 1 n E 2 ( ϕ n (x)) := T 3 + T 4 .
From Lemma 2, we immediately derive

T 4 = 1 n ϕ 2 n (x) [1 + o(1)] .
We shall prove that

T 3 = 1 nh d (p + 1) 2 2p + 1 B K 2 (s)ds ϕ 2 n (x) f (x) [1 + o(1)] , (9)
leading to T 4 /T 3 = O(h/p), and the announced result follows. To this end, remark that

T 3 = 1 nh 2d E K 2 x -X h E(Z 2 |X) = 1 nh 2d (p + 1) 2 2p + 1 E K 2 x -X h g 2p (X) = 1 nh d (p + 1) 2 2p + 1 B K 2 (s)ds R d 1 h d Q x -u h g 2p (u)f (u)du,
where we have introduced the kernel Q = K 2 / B K 2 (s)ds. It is easily seen that the second integral is similar to this appearing in E ϕ n (x), (see ( 8)), with K replaced by Q and p by 2p. Thus, as in the proof of Lemma 2, we have

R d 1 h d Q x -u h g 2p (u)f (u)du = g 2p (x)f (x) [1 + o(1)] = ϕ 2 n (x) f (x) [1 + o(1)] ,
and ( 9) is proved.

As a simple consequence of Lemma 2 and Lemma 3, we have

Corollary 1 Under (A.1)-(A.5), if ph α → 0 and p/(nh d ) → 0, then, for all x ∈ R d , ϕ n (x)/ϕ n (x) P → 1.
We can now turn to our main result.

Theorem 2 Suppose that nph d+2α → 0 and p/(nh d ) → 0. Let us define

σ -1 n (x) = ((2p + 1)nh d ) 1/2 f (x) B K 2 (t)dt 1/2 . Then, under (A.1)-(A.5), for all x ∈ R d , σ -1 n (x) g n (x) g(x) -1 d → N (0, 1).
Proof : First, note that nph d+2α → 0 and p/(nh d ) → 0 imply ph α → 0. From Lemma 9, it suffices to prove that

ξ n := σ -1 n (x) p ϕ n (x) ϕ n (x) - E ϕ n (x) ϕ n (x) d → N (0, 1).
To this end, define

W i,n = σ -1 n (x) np 1 ϕ n (x) K h (x -X i )Z i
so that we can write

ξ n = n i=1 (W i,n -EW i,n ) .
Following Lemma 3, we have

V (ξ n ) = nV (W 1,n ) = σ -2 n (x) p 2 1 ϕ 2 n (x) V( ϕ n (x)) = (2p + 1) nh d f (x) p 2 B K 2 (s)ds 1 ϕ 2 n (x) 1 nh d (p + 1) 2 2p + 1 B K 2 (s)ds ϕ 2 n (x) f (x) [1 + o(1)] = 1 + o(1).
Thus, the condition of Lyapounov reduces to

n i=1 E |W i,n -EW i,n | 3 = nE |W 1,n -EW 1,n | 3 → 0. (10)
Taking into account that W 1,n is a positive random variable, the triangular inequality together with Jensen's inequality yield

E |W 1,n -EW 1,n | 3 ≤ 8E W 3 1,n .
Introducing the kernel K 3 / B K 3 (s)ds, and mimicking the proof of Lemma 3, we obtain

E(W 3 1,n ) = n -3/2 h -d/2 p 1/2 2 3/2 3f (x) 3/2 B K 3 (s)ds B K 2 (s)ds 3/2 (1 + o(1)) = κn -3/2 h -d/2 p 1/2 (1 + o(1)), ( 11
)
where κ is a positive constant. Returning to [START_REF] Geffroy | Sur un problème d'estimation géométrique[END_REF], we have

n i=1 E |W i,n -EW i,n | 3 ≤ 8κ p nh d 1/2 (1 + o(1)) → 0,
and the result is proved.

Remark 1 Theorem 2 holds when σ -1 n (x) is replaced with

σ -1 n (x) = ((2p + 1)nh d ) 1/2 f n (x) B K 2 (t)dt 1/2 , since in this context f n (x) P → f (x)
. This allows to produce pointwise confident intervals for the frontier.

Remark 2 To fulfill the assumptions of Theorem 2, one can choose h = n -1/(d+α) and p = ε n n α/(d+α) , where (ε n ) is a sequence tending to zero arbitrarily slowly. These choices yield

σ -1 n (x) = ε 1/2 n n α/(d+α) 2f (x) B K 2 (t)dt 1/2 (1 + o(1)),
which is the optimal speed (up to the ε n factor) for estimating α-Lipschitzian d-dimensional frontiers, see [START_REF] Korostelev | Minimax theory of image reconstruction[END_REF], Chapter 5.

The good performances of ĝn (x) on finite sample situations are illustrated in the next section.

Remark 2 will be of great help to choose p and h sequences.

Numerical experiments

Here, we limit ourselves to unidimensional random variables X (p = 1) with compact support

E = [0, 1]. Besides, Y given X = x is distributed on [0, g(x)] such that P(Y > y|X = x) = 1 - y g(x) γ , (12)
with γ > 0. This conditional survival distribution function belongs to the Weibull domain of attraction, with extreme value index -γ, see [START_REF] Embrechts | Modelling extremal events[END_REF] for a review on this topic. The case γ = 1 corresponds to the situation where Y given X = x is uniformly distributed on [0, g(x)]. The larger γ is, the smaller the probability ( 12) is, when y is close to the frontier g(x). The behavior of the proposed frontier estimator is investigated on different situations:

• Two distributions are considered for X: a uniform distribution U ([0, 1]) and a beta distribution B(2, 2).

• Two frontiers are introduced. The first one

g 1 (x) = 1 + exp (-60(x -1/4) 2 ) if 0 ≤ x ≤ 1/3, 1 + exp (-5/12) if 1/3 < x ≤ 2/3, 1 + 5 exp (-5/12) -6 exp (-5/12)x if 2/3 < x ≤ 5/6, 6x -4 if 5/6 < x ≤ 1.
is continuous but is not derivable at x = 1/3, x = 2/3 and x = 5/6. The second one

g 2 (x) = (1/10 + sin(πx)) 11/10 -exp -64(x -1/2) 2 /2 is C ∞ .
• Four sample sizes are simulated n ∈ {200, 300, 500, 1000}.

• Three exponents are used γ ∈ {1, 2, 3}.

The following kernel is chosen

K(t) = cos 2 (πt/2)1{t ∈ [-1, 1]},
with associated window width h = 4σ(X)n -1/2 and with p = n 1/2 . The dependence of these sequences with respect to n is chosen according to Remark 2 with α = d = 1. The multiplicative constant 4σ(X) in h is chosen heuristically. The dependence with respect to the standard-deviation of X is inspired from the density estimation case. The scale factor 4 was chosen on the basis of intensive simulations.

Here, the experiment involves several steps:

• First, m = 500 replications of the sample are simulated.

• For each of the m previous set of points, the frontier estimator ĝn is computed.

• The m associated L 1 distances to g are evaluated on a grid.

• The mean, smallest and largest L 1 errors are recorded.

Some results are depicted on Figure 123, where the best situation (i.e. the estimation corresponding to the smallest L 1 error) and the worst situation (i.e. the estimation corresponding to the largest L 1 error) are represented. Note that, even in the worst situations, the empirical choices of sequences h and p seem satisfying for all the considered frontiers and densities of X. In fact, the worst situations are obtained when no points were simulated at the boundaries of the support. This is specially the case on Figure 3(b) since the density of X decreases to 0 at the boundaries of the [0, 1] interval and the density of Y |X = x decreases to 0 in the neighborhood of g(x).

Finally, the above estimator is compared to three other ones:

• The estimator ĝn with p = 1, which reduces to a rescaling of the regression estimator, in a similar spirit as in [START_REF] Jacob | Regression and edge estimation[END_REF].

• Geffroy's estimator [START_REF] Geffroy | Sur un problème d'estimation géométrique[END_REF], denoted by ĝG n , which is a step function based on the extreme values of the sample.

• The kernel estimator ĝK n introduced in [START_REF] Girard | Extreme values and kernel estimates of point processes boundaries[END_REF], which is a smoothed and bias-corrected version of Geffroy's estimator.

Results are summarized in Table 1. It appears that, when γ increases, performances of all estimators decrease, since the simulated points are getting more and more distant from the frontier function. In the case p = 1 and γ = 3, one can see that ĝn does not converge to the true frontier when n increases. This shows that the condition p → ∞ is necessary to obtain the convergence of the estimator. Finally, note that in all the situations considered in Table 1, ĝn outperforms ĝG n and ĝK n .

Conclusion and further work

To conclude, let us note that, even though ĝn converges to the true frontier g in case of non uniform conditional distributions, it is possible to design new estimators dedicated to particular parametric models. For instance, in case of model [START_REF] Girard | L 1 -optimal nonparametric frontier estimation via linear programming[END_REF], estimator ĝn could be modified to obtain gn,γ (x) = 1 γB(1 + p, γ)

n i=1 K h (x -X i )Y p i n i=1 K h (x -X i ) 1/p
, where B is the beta function defined by

B(a, b) = 1 0 u a-1 (1 -u) b-1 du.
Of course, ĝn corresponds to the particular case gn,1 . When γ is assumed to be known, the new multiplicative constant yields a very efficient bias correction, see Figure 4 for an illustration. A part of our future work will consist in defining an estimator of γ and plugging it into gn,γ . New asymptotic results will be established. We also plan to investigate the asymptotic properties of local polynomial estimators based on the same ideas as those used for ĝn and gn,γ .

Appendix: Auxiliary lemmas

The following lemma provides convenient bounds obtained by a specific study of the functions

u → |(1 + u) p -1| -2p|u| and u → (1 + u) 1/p -1 -1 p u.
The study is left to the reader. Note that these bounds could not be directly derived from the Taylor formulas

|(1 + u) p -1| = |pu + o(u)| and (1 + u) 1/p -1 -1 p u = 1 2p ( 1 p -1)u 2 + o(u 2 )
where the dependence on p of o(u) and o(u 2 ) is not precised.

Lemma 4 Suppose p ≥ 1. (i) Then, p|u| ≤ ln 2 entails |(1 + u) p -1| ≤ 2p|u|. (ii) Let C ≥ 2. Then, |u| < 1/2 entails (1 + u) 1/p -1 -1 p u ≤ C p u 2 .
The next lemma is dedicated to the control of the local variations of the frontier on a neighborhood of size h.

Lemma 5 Suppose (A.1), (A.2) hold. If ph α → 0 and x -y ≤ h, then for sufficiently large n, g(x) g(y)

p -1 ≤ 2 L g g min ph α ,
where L g is the Lipschitz constant of the function g.

Proof : Take u = g(x) g(y) -1 and observe that p|u| ≤ p Lg gmin x -y α , Thus, if x -y ≤ h, and ph α → 0, we have p|u| ≤ ln 2 for sufficiently large n. Then, following Lemma 4(i), for sufficiently large n, we obtain

|(1 + u) p -1| = g(x) g(y) p -1 ≤ 2p|u| ≤ 2 L g g min ph α ,
and the result is proved.

Lemma 6 is used to establish the complete convergence of random variables ratio.

Lemma 6 Let S, T be real random variables, a, b non zero real numbers, and

0 < η < 1/2. Then, S T - a b > 4η a b ⊆ S a -1 > η ∪ T b -1 > η .
Proof : Consider the following obvious equality:

S T - a b = a b S a -1 + a b 1 - T b + S T - a b 1 - T b . ( 13
)
The triangular inequality yields for all η > 0:

S a -1 ≤ η ∩ T b -1 ≤ η ⊆ S T - a b ≤ 2η a b + η S T - a b .
Taking 0 < η < 1, we obtain

S a -1 ≤ η ∩ T b -1 ≤ η ⊆ S T - a b ≤ 2η 1 -η a b .
Finally, note that 2η 1-η < 4η for 0 < η < 1/2.

The next three lemmas are of great use to deduce successively the asymptotic normality of g n (x) from r n (x) and the asymptotic normality of r n (x) from ϕ n (x).

Lemma 7 Let x ∈ R d . If f n (x)/f (x) P → 1 and ϕ n (x)/ϕ n (x) P → 1, then r n (x) r n (x) -1 = ϕ n (x) ϕ n (x) -1 - f n (x) f (x) -1 (1 + o p (1)). Proof : The hypotheses yield b rn(x) rn(x) = b ϕn(x) b fn(x) / ϕn(x) f (x) P → 1. Thus it suffices to consider S = b ϕn(x) ϕn(x) , T = b fn(x) f (x)
, and a = b = 1 in the equality [START_REF] Girard | Extreme values and Haar series estimates of point process boundaries[END_REF].

Lemma 8 Let x ∈ R d . If f n (x)/f (x) P → 1 and ϕ n (x)/ϕ n (x) P → 1, then g n (x) g(x) -1 = 1 p r n (x) r n (x) -1 (1 + o p ( 1

)).

Proof : From the hypotheses, w n (x) := b rn(x) rn(x) -1 = o p (1). Moreover, following Lemma 4(ii), on the event {|w n (x)| < 1/2} we have:

∆ n (x) := g n (x) g(x) -1 - 1 p r n (x) r n (x) -1 = (1 + w n (x)) 1/p -1 - w n (x) p ≤ C 1 p w 2 n (x).
We thus have, on the one hand,

p∆ n (x)1 {|wn(x)|<1/2} = o p (w n (x)).
On the other hand, for all ε > 0,

p ∆ n (x) w n (x) 1 {|wn(x)|≥1/2} > ε ⊆ {|w n (x)| ≥ 1/2} leading to P p ∆ n (x) w n (x) 1 {|wn(x)|≥1/2} > ε ≤ P {|w n (x)| ≥ 1/2} → 0,
and thus

p ∆ n (x) w n (x) 1 {|wn(x)|≥1/2} = o p (w n (x)),
which completes the proof.

Lemma 9 Suppose that nph d+2α → 0 and p/(nh d ) → 0. Let us define

σ -1 n (x) = ((2p + 1)nh d ) 1/2 f (x) B K 2 (t)dt 1/2
, and let Q be an arbitrary distribution. Then, under (A.1)-(A.5),

σ -1 n (x) p ϕ n (x) ϕ n (x) - E ϕ n (x) ϕ n (x) d → Q =⇒ σ -1 n (x) g n (x) g(x) -1 d → Q .
Proof : First, note that nph d+2α → 0 and p/(nh d ) → 0 imply ph α → 0. Thus, from Corollary 1,

ϕ n (x)/ϕ n (x) P → 1.
Besides, p/(nh d ) → 0 implies nh d → ∞, and thus, using a classical result on density estimation (see for instance [START_REF] Bosq | Théorie de l'estimation fonctionnelle. Economie et Statistiques avancées[END_REF], Chapter 4, Theorem II.1), we have f n (x)/f (x)

P → 1.
Lemma 7 thus entails

σ -1 n (x) p r n (x) r n (x) -1 = σ -1 n (x) p ϕ n (x) ϕ n (x) -1 - σ -1 n (x) p f n (x) f (x) -1 (1 + o p (1)) = σ -1 n (x) p ϕ n (x) ϕ n (x) - E ϕ n (x) ϕ n (x) - σ -1 n (x) p f n (x) f (x) - E f n (x) f (x) (1 + o p (1)) + σ -1 n (x) p E ϕ n (x) ϕ n (x) -1 - σ -1 n (x) p E f n (x) f (x) -1 (1 + o p (1)).
Following Lemma 2, we have,

σ -1 n (x) p E ϕ n (x) ϕ n (x) -1 = O nh d p 1/2 O (ph α ) = O nph d+2α 1/2 = o(1),
and from a classical result on density estimation

E f n (x) -f (x) = O(h α ), see [4], Proposition 2.1,
we have

σ -1 n (x) p E f n (x) f (x) -1 = O nh d p 1/2 O (h α ) = O np -1 h d+2α 1/2 = o(1).
Consequently,

σ -1 n (x) p r n (x) r n (x) -1 = σ -1 n (x) p ϕ n (x) ϕ n (x) -1 - σ -1 n (x) p f n (x) f (x) -1 (1 + o p (1)) + o p (1).
Again, using a classical result on density estimation, V( f n (x)) = O(1/(nh d )), see [START_REF] Collomb | Estimation non paramétrique de la régression par la méthode du noyau[END_REF], Proposition 2.2, we have

V σ -1 n (x) p f n (x) f (x) = O nh d p O 1 nh d = O(1/p) = o(1),
and thus

σ -1 n (x) p r n (x) r n (x) -1 = σ -1 n (x) p ϕ n (x) ϕ n (x) -1 + o p (1). ( 14
)
Suppose now that there exists a probability distribution Q such that

σ -1 n (x) p ϕ n (x) ϕ n (x) - E ϕ n (x) ϕ n (x) d → Q.
From ( 14), we deduce that

σ -1 n (x) p r n (x) r n (x) -1 d → Q.
Finally, from Lemma 8 we can conclude that

σ -1 n (x) g n (x) g(x) -1 d → Q,
and the result is proved. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + (b) Worst situation Figure 1: The frontier g 1 (continuous line) and its estimation (dashed line). The sample size is n = 300, X is uniformly distributed on [0, 1] and γ = 1.

Figure 2 :Figure 3 :

 23 Figure2: The frontier g 1 (continuous line) and its estimation (dashed line). The sample size is n = 300, X is B(2, 2) distributed on [0, 1] and γ = 1.

Acknowledgement

The authors are indebted to the anonymous referees for their helpful comments and suggestions.

They have contributed to a greatly improved presentation of the results of this paper.