Sagar Sen
email: ssen@irisa.fr

Benoit Baudry
email: bbaudry@irisa.fr

Hans Vangheluwe

Domain-specific Model Editors with Model Completion

Keywords: constraint logic programming, meta-model, model editor, declarative specification, partial model, AToM

Today, integrated development environments such as Eclipse allow users to write programs quickly by presenting a set of recommendations for code completion. Similarly, word processing tools such as Microsoft Word present corrections for grammatical errors in sentences. Both of these existing systems use a set of constraints expressed in the form of a grammar to restrict/correct the user. Taking this idea further, in this paper we present an integrated software system capable of generating recommendations for model completion of partial models built in arbitrary domain specific model editors. We synthesize the model editor equipped with automatic completion from a modelling language's declarative specification consisting of a meta-model and constraints on it along with a visual syntax. The automatic completion feature is powered by a Prolog engine whose input is a constraint logic program derived from some models. The input logic program is obtained by a model transformation from models in multiple languages: the meta-model (as a class diagram), constraints on it (as constraint logic clauses), and a partial model (in the domain specific language). The Prolog engine solves the generated logic program and the solution(if there is one) is returned to the model editor as a set of recommendations for properties of the partial model. We incorporate automatic completion in the generative tool AToM 3 and use SWI-Prolog for constraint representation and satisfaction. We present examples using an illustrative visual language of Finite State Machines.

Introduction

Generative modelling tools such as AToM 3 (A Tool for Multiformalism Metamodelling) [START_REF] Vangheluwe | Domain-Specific Modelling with AToM 3[END_REF],GME(Generic Modelling Environment) [START_REF] Ledeczi | Composing Domain-Specific Design Environments in Computer[END_REF], GMF (Eclipse Graphical Modelling Framework) [START_REF] Ehrig | Generation of visual editors as eclipse plug[END_REF] can synthesize a domain specific visual model editor from a declarative specification of a domain specific modelling language. A declarative specification consists of a meta-model, a set of constraints on all possible instances (or models) of the meta-model, and a visual syntax that describes how language elements(objects and relationships) manifesting the model editor. The designer of a model uses this model editor to construct a model on a canvas. This is analogous to a using an integrated development environment(IDE) to enter a program or a word processor to enter sentences. However, IDEs such as Eclipse present recommendations for completing a program statement when possible based on its grammar and existing libraries [START_REF] Ko | Design requirements for more flexible structured editors from a study of programmers text editing[END_REF]. Similarly, Microsoft Word presents grammatical correction recommendations if a sentence does not conform to natural language grammar. Can we extrapolate similar technology for partial models constructed in a model editor for a domain specific modelling language(DSML)?

The major difficulty for providing completion capabilities in model editors is to integrate heterogeneous sources of knowledge in the computation of the possible solutions for completion. The completion algorithm must take into account the concepts defined in the meta-model for the DSML, the constraints expressed on this meta-model and the partial model built by a domain expert. The difficulty is that these three sources of knowledge are obviously related(they refer to the same concepts) but are expressed in different languages, sometimes in different files, and in most cases by different people and at different moments in the development cycle as they are separable concerns. These constraints are expressed in different languages and can come from multiple paradigms. For instance, in a electrical system model the resistance of a resistor can be constrained both by a low-level circuit model based on Kirchoff's laws and a high-level business process constraint that wants to have low-energy consumption at the resistor. The goal is to integrate these constraints under one common language.

In this paper, we propose an automatic transformation from all these sources of knowledge to a constraint logic program (CLP).The generated program can then be fed in a Prolog engine that provides the possible solutions for completing the model. Our transformation is integrated in the software tool AToM 3 . The meta-model for a DSML is built directly in AToM 3 's model editor using its class diagram formalism. The constraints on this meta-model are defined with Prolog in a separate file. Using this information and a description of the concrete visual syntax(specified in an icon editor) for a modelling language, AToM 3 synthesizes a visual model editor for the DSML. The partial model can be built and edited in the generated model editor and the designer can ask for recommendations for possible completions. The closest implementation in the literature is that of the GEMS tool [START_REF] White | Intelligence Frameworks for Assisting Modelers in Combinatorically Challenging Domains[END_REF]. In their work the detailed process of transforming a class-diagram based meta-model to a Prolog knowledge base is not discussed. Also, we clearly define the model completion problem boundaries and restrict ourselves to finite-domain constraint logic programs.

An overview of our methodology is presented in Section 2. In Section 3 we present how domain specific modelling languages are specified and model editors for them are synthesized in MDE using meta-models, constraints and visual syntax. We also present in Section 3 an example of a partial model and a complete model in our chosen domain. Using the meta-model,constraints, and partial model we present the transformation to a constraint logic program in Section 4. We present examples of model completion recommendations generated for partial models in Section 5. We conclude in Section 6 with limitations of our work and we layout future directions.

Methodology Overview

Synthesis of model editors elicit the involvement of several different experts and users. We identify the involvement of language designers, domain experts or users of a DSML, visual syntax designers for automatic synthesis of model editors.

• Language Designers interact with the domain experts to specify the concepts in a DSML in the form of a meta-model which is an AToM 3 class diagram4 (meta-model from now on). Next, the designer specifies a set of Prolog clauses on the properties defined in the meta-model. We use SWI-Prolog for constraint representation.

• Visual Syntax Designers construct annotated icons that represent the different concepts in the meta-model. The icon for a class may be annotated with its property values. In Figure 1 we summarize how the meta-model, constraints,and visual syntax is used to synthesize a model editor for a DSML.

• Domain Experts and Users build models in the model editor that is synthesized from the meta-model, constraints, and visual syntax specifications. They also help the language designer define the concepts in the meta-model.

A domain expert uses the synthesized model editor to build models. He creates a model by inserting objects and building relationships between objects. He/she also sets values for properties. The model is simply a graph or a partial model until it conforms to its modelling language by satisfying all the constraints imposed on the modelling language. Manually performing such a task can be extremely tedious and sometimes impossible due to the size of the domains of model properties and complexity of constraints.

To automate the completion of a partial model we introduce a model transformation to construct a generative algorithm from the knowledge provided in the meta-model and constraints. The algorithm takes a partial model as input and generates a constraint logic program. This transformation is integrated into AToM 3 so that it can be used for completion of models in any domain specific language.

Logic programming tool developers have built Prolog compilers [START_REF] Wielemaker | SWI-Prolog 5.6.35 Reference Manual[END_REF] that can perform computer algebra and constraint satisfaction on an input constraint logic program. Such a Prolog compiler is invoked by AToM 3 and the synthesized CLP is solved and the results (if they exist) are returned to the model editor as recommendations. We use SWI-Prolog [START_REF] Wielemaker | SWI-Prolog 5.6.35 Reference Manual[END_REF] for compiling the constraint logic program. In Figure 2 we outline how we complete partial models in AToM 3 . Now that we have outlined our overall methodology we go ahead and study each aspect of the methodology in detail leading to examples that illustrate the working of the idea. We illustrate our methodology using the guiding example of a Finite State Machine (FSM) modelling language.

Specifying a Domain Specific Modelling Language

In this section we explain the steps taken to declaratively specifying a domain specific modelling language. We use Finite State Machines (FSM) as a running example for a modelling language. A FSM modelling language is a visual language with circles representing states and directed arrows representing transitions between states. To define a modelling language and to generate visual model editor from it requires three inputs: String {"a", "b", "c", "event1", .., }

Meta-model

A model consists of objects and relationships between them. The meta-model of the modelling language specifies the types of all the objects and their possible interrelationships. The type of an object is referred to as a class. The meta-model for the FSM modelling language is presented in Figure 3. The classes in the meta-model are State and Transition.

In this paper we use the class diagram formalism in AToM 3 for specifying a meta-model. The class diagram formalism can specify itself and hence exhibits the property of bootstrapping. We use the visual language notation of class diagrams to specify the meta-model for the FSM modelling language in Figure 3.

Each class in the meta-model has properties. A property is either an attribute or a reference. An attribute is of primitive type which is either Integer, String, or Boolean. For instance, the attributes of the class State are isInitial and isFinal both of which are of primitive type Boolean. An example domain of values for the primitive attributes is given in Table 1. The String variable can be a finite set consisting of a null string, and finite length strings that specify a set of strings. In this paper, we consider a finite domain for each attribute. The domain is specified in the meta-model and all the models that are instances of the meta-model know of the domain for each attribute.

Describing the state of a class of objects with only primitive attributes is not sufficient in many cases. Modelling many real-world systems elicits the need to model complex relationships such as modelling that an object contains another set of objects or an object is related to another finite set of objects. This set of related objects is constrained by a cardinality. When a class is related to another class, the related classes refer to each other via references. For instance, in Figure 3 There is no inheritance in our FSM meta-model, nevertheless we consider transformation of inheritance relationships in the transformation presented in Section 4.

Constraints on Meta-model

Constraints on a meta-model are not always conveniently specified using diagrams. They are better expressed in a textual constraint language who's semantics has no side-effect (does not change the state of an object or structure of the model) on the meta-model or its instances (models). The OMG standard for constraint specification is Object Constraint Language (OCL) however in our current work we use constraint logic programming clauses in the form of Prolog statements. These constraints are initially specified on meta-model properties. The transformation generates a set of constraints on a lists of properties (those influencing the constraint) in the partial model.

We use the CLP bounds library to specify constraints on properties with finite domain. There are several predicates in the standard Prolog library. For instance, one of the constraints for the FSM modelling language is:

• atLeastOneFinalState Variables: listOfisFinal is the list of all isFinal attributes for all states in the model.

Prolog Constraint: sum(listOfisFinal,>=,1) Explanation: The attribute isFinal is a boolean and the list of isFinals contains the values of all attributes in the partial model. The constraint ensures that the sum of the isFinals is greater than or equal to 1. This enforces the constraint that there is at least one final state.

Other constraints include exactly one initial state, and a unique label for a state object. To define constraints for arbitrary DSMLs we point the reader to the SWI-Prolog reference manual [START_REF] Wielemaker | SWI-Prolog 5.6.35 Reference Manual[END_REF]. The language and the libraries have been developed for two decades and we have a large repository of constraints to work with including facility to use a foreign language to define an arbitrary boolean function. Prolog has powerful mechanisms such as domain reduction. For instance, constraint alldifferent(listOfVariables) ensures the automatic reduction in the domain of variables in listOfVariables such that the each variable in the list has a domain with values not in the domain of the others. The textual specification of constraints is typically specified in an different file from the class diagram meta-model itself.

Visual Syntax

The final step(in specifying a DSML for synthesizing a model editor) we take is to specify the concrete visual syntax of the class of objects in the meta-model. The visual syntax specifies what an object looks like on a 2D canvas. An icon editor in AToM 3 is used to specify the visual syntax of the classes in the meta-model.

An icon editor is used to specify the visual syntax of meta-model concepts such as classes and relationships. The icon for State is a circle annotated with three of its attributes(isFinal, isInitial, and label). The connectors in the diagram are points of connection between State objects and Transition objects.

The visual syntax can also be dynamically changed based on the properties of the model for example. In an iconic visual modelling language such FSM the first step taken in specifying a visual syntax is drawing an icon that represents a class of objects. If needed it is annotated with text and its properties. Connectors are added to the visual object so that it can be connected to other objects if they are related.

Transformation from Declarative Specification and a Partial Model to CLP

We present the transformation of the different parts of a partial model to a CLP using the meta-model and constraints as input. The essential idea to generate CLPs constitutes the following steps:

(i) Create variables to represent properties of a partial model (ii) Define a domain on these variables.

(iii) Define constraints on these variables.

(iv) Finally, insert the label(SetOfVariables) clause to perform back-tracking search.

We associate a finite domain for each variable in the constraint logic program (CLP) hence, making it a constraint logic program in finite domain (CLP(FD)).We use the clp bounds library in SWI-Prolog to express domains and constraints in CLP(FD). We generate a conjunction of constraints in Prolog. The conjunction is given by a , operator. Finally, we insert the label predicate at the end of the program to perform back-tracking to find the value assignment/labeling of variables so as to generate completions for the partial model.

Transforming an Object

We now discuss how objects in a partial model are transformed to CLP. We illustrate this with a concrete example to enhance the reader's understanding. Consider the object shown in In the transformation first each attribute has a unique identity which is given by OwningObjectName attributeName. This unique ID is used to create a variable and is added to a list of variables in the CLP. If Model is the set of variables in the partial model. Then the variable State0 isFinal is included in this list:

Model=[..., State0 isFinal,...],
Next, we associate a domain with a variable already included in the list of model variables. This is done using the member Prolog predicate. For instance, the domain for the variable State0 isFinal is manifested in Prolog as follows:

member(State0 isFinal,[0,1])
We obtain the domain information for an attribute from the meta-model of the modelling language.

The CLP code generated for a State object is shown in Figure 4 (b). Solving the Prolog program gives a set of arrays with the result for the value assignment of each variable. This is shown in Figure 4 (c).

Transforming an Association

Next, we consider the transformation of an association in partial model to Prolog clauses. Consider the associations in Figure 5 (a). Two State objects are connected by two Transition objects. The existence of these relationships is determined by boolean existence variables such as Transition0 exists and Transition1 exists. In general, these variables are synthesized for all association in the partial model. We obtain the cardinality constraint for each association from the meta-model. In the partial model we look for all associations with the same source and destination object. We impose a cardinality constraint on all associations with the same source and destination. We synthesize two Prolog clauses to impose the cardinality constraint on a list of existence variables for the associations with the same source and destination. The example in Figure 5 (a) has its code generated in Figure 4 (b).

The cardinality constraints are imposed as sum of existence variables as follows:

sum([Transition0 exists,Transition1 exists],>=,0), sum([Transition0 exists,Transition1 exists],=<,100),

The solution obtained for completing the partial model is shown in Figure 5 (c).

Generating Constraints

Finally, we insert constraints defined on the meta-model. A constraint C is expressed on properties p1,p2,...pN of a meta-model MM. In a partial model we identify all properties that are constrained by C and generate a list of variables (those already generated as described in Sections 4.1 and 4.2). The constraint on the meta-model itself cannot be executed. The constraint of the partial model is handled by the Prolog compiler.

For instance, to ensure that every State object in the partial model has a unique label we generate the following constraint which is added as a conjunction to the constraints already generated:

all different([State0 label,State1 label,..])
The all different clause ensures that he value of each element in the list it receives as input is unique.

A Running Example

In this section, we present an example of a partial model that we use to generate model completion recommendations. In Figure 6 we present a partial model with two generated recommendations. For the same partial model we performed more tests. We generate 5 model completion recommendations. We randomly shuffle the domain constraints in the generated CLP. The shuffling changes the priority order in which values for properties are chosen by Prolog and has an effect on the result of model completion. We do not study this variability in detail. However, we present the time taken for generating 5 recommendations in Table 2.

For our example the time taken to generate a solution for the modelis reasonably acceptable with an average of 2.5 seconds. A large portion of the time taken involves pre-processing of the problem by the Prolog compiler. The rest of the time is taken to find value assignments for constraint satisfaction.

Conclusion

In this paper we present a framework for generating model completion recommendations in model editors. We illustrate our approach with the simple example of the FSM modelling language. At present we specify the meta-model as an AToM 3 class diagram (which is subset of UML class diagrams with sufficient facility for bootstrapping). Constraints on the meta-model are directly specified in Prolog. We also demonstrate, using a reasonably complex example, the working of our approach. However, there is room for several improvements. Currently we only support constraint satisfaction of constraints from the metamodel and constraints of the modelling language. We wish to extend this by introducing user-specific objective functions and other constraints such as model transformation pre-conditions. This could lead to synthesis of interesting models for tasks such as model transformation testing and design space exploration. It would also be interesting to see how constraints from multiple paradigms can co-exist in the same environment and how they can be solved to get meaningful results. Also, we start from a partial model with a fixed number of objects. In other words the dimensionality given by the object space is fixed. We plan to separate the notion of object space and property space to allow the synthesis of objects that add to a partial model before we go ahead and find values for proper ties as explained in this article. He have not rigoursly tested our approach for scalability. With the increase in the number of objects the Prolog engine takes longer to find a solution.

A way to speed up would be to reduce the number of elements in the domain of properties in the partial model. Another approach would be divide the model into components and complete each component before integration. Finally, we plan to use high-level constraints to formally communicate knowledge between modelling domains(multi-paradigm modelling) or scientific knowledge in general.

Fig. 1 .

 1 Fig. 1. Steps Taken by a DSML Designer to Synthesize a Model Editor in AToM 3

Fig. 2 .

 2 Fig. 2. Model Completion Outline

  (i) A Meta-model as an AToM 3 class diagram (ii) A Set of Prolog Constraints on the meta-model (iii) A Visual SyntaxWe briefly describe these in the following sub-sections.

Fig. 3 .

 3 Fig. 3. The Finite State Machine Meta-model

  the classes State and Transition refer to each other via references annotated with uni-directional relationships. The cardinality constraints are also annotated with the relationship. Apart from attributes and references, objects can inherit properties from other classes. The attributes and references of a class called a super class are inherited by derived classes. Similarly a derived class inherits the references in the super class.

Figure 4 .

 4 It is a State object. The attributes of a State object are isFinal, isInitial, currentState, and label. Each attribute also has a domain. The attributes isFinal, isInitial and currentState in the State object has a boolean domain of [0, 1]. The label attribute has an integer domain of [0, 1, 2, .., M axN umberOf States].

Fig. 4 .

 4 Fig. 4. (a) Object (example of a State object (b) Generated CLP code (c) Five Prolog solutions for each variable

Fig. 6 .

 6 Fig. 6. A Partial Model and Two Proposed RecommendationsTable 2 Generated Recommendations Recommendation CPU Time 1 1.3 2 0.55 3 3.34 4 3.50 5 3.72

Table 1

 1 Domains for Primitive Datatypes

	Type	Domain
	Boolean {0, 1}
	Integer	{M inInt, .., M axInt}

AToM 3 class diagram is a subset of UML class diagram for meta-modelling and has sufficient expressiveness for bootstrapping

Sen, Benoit, Vangheluwe


Sébastien Saudrais -Olivier Barais -Noël

Plouzeau -Jean-Marc Jézéquel

Monitoring your Lego Mindstorms™ with Giotto

Keywords: Timed specification, Model Driven Development, Giotto, Monitoring embedded system, Lego Mindstorms™

In the domain of soft real-time application design, the gap between component-specification models and their implementations often implies that the implementations cannot fully take advantage of the specification models. The component's time behaviour is not always used during the implementation process by the targeted programming languages because they cannot deal easily with time. In this presentation we propose a complete model transformation chain to generate monitors from time specification. We demonstrate the applicability of this approach for monitoring a Lego Mindstorms™ application with Giotto platform.

Motivations

The MDE (Model-Driven Engineering) initiatives, most prominently advanced by IBM with EMF, the OMG (Object Management Group) with the MDA or by Microsoft with Software Factories promote models to be the primary artifacts of software development, making executable code a pure derivative. According to this development paradigm, software is generated with the aid of suitable transformations from a compact description (the model) that is more easily read and maintained by humans than any other form of software specification in use today. In the domain of system engineering, we argue that the techniques promoted by those initiatives can be used to better profit from specifications even if those specifications are partially ignored by the developers during the development process. Specifications can be used to generate monitors that check the real-behaviour of the systems against its specification. We present, first, the development process. We present next how we have applied this process to monitor an embedded systems developed with Lego Mindstorms™. Finally, we discuss the benefits of this process.

Development process

The development process aims at facilitating the use of formal methods in a traditional development process. In this way, the designer can choose his implementation techniques (programming language, programming paradigm …) without restrictions. Our approach augments the traditional development process with time specifications. Those time specifications serve to generate monitors. The generated monitors also decorate the system implementation to keep a check on it. This new process can be done in parallel with the traditional development. The augmentation is performed in two steps as presented in Figure 1. The first one is controlled by the designer and the second one is fully automatic:

• During the first step, the architect is assisted to introduce time into component's behaviour. To achieve this, we defined a set of time properties expressed with time patterns: response time, execution time, delay, period… The application architect selects the suitable patterns that must be introduced into his components. Then, the patterns are woven into the original behaviour. The resulting behaviour is a timed automaton for each component. A global timed automaton for the whole application can be computed from the components' automata. The full process is explained in [START_REF] Saudrais | Barais --Integration of Time Issues into Component-Based Applications[END_REF] • During the second step, a monitor is generated to check, at runtime, that the behaviour is correct against the specified behaviour. This monitor is generated from the timed behaviour of the application (that represents the expected behaviour of the components). A model transformation, defined in Kermeta [START_REF] Muller | -Weaving executability into object-oriented meta-languages[END_REF], converts the timed automaton of the application into an implementation based on the Giotto framework [START_REF] Henzinger | Giotto: A time-triggered language for embedded programming[END_REF]. The monitor observes whether the execution of the components is correct by keeping a check on the interactions between components. The monitor can be generated in Java or C code. The transformation is explained in [START_REF] Saudrais | Duchien --Using Model-Driven Engineering to Generate QoS Monitors from a Formal Specification[END_REF].

Architecture

To evaluate the applicability of this approach, we present how to design and implement an embedded system using this development process. The target platform is a Lego Mindstorms™ NXT Robot. The operating system has been modified for the experiment. The Robot is now based on leJOS1 (pronounced like the Spanish word "lejos" for "far"). It is a tiny Javabased operating system. leJOS was originally forked out of the TinyVM project. It contains a VM for Java bytecodes and additional software to load and run Java programs. Lejos supports features such as: Object oriented language (Java), Preemptive threads (tasks) and Synchronization.

Figure 1: Generation process

The generation of the monitors is based on the Giotto framework [START_REF] Henzinger | Giotto: A time-triggered language for embedded programming[END_REF]. Giotto is a real-time framework for embedded control systems running on possibly distributed platforms. A Giotto program explicitly specifies the exact real-time interaction of software components with the physical world. A Giotto program is generated from the time specification. This program is in charge checking on the components' interaction. The Giotto compiler automatically generates timing code (ecode) that ensures the specified behaviour on a given platform. By default, this ecode is generated for a complete Java Virtual Machine.

In the case of the Robot Mindstorms™, some parts of the Java Standard Library are removed: no File support, no ClassLoader support, no Hashtable support, no switch statement support. To embed Giotto into leJOS, those shortcomings have been overcome. As leJOS supports preemptive threads, the main program and the monitors are executed in two different threads. The main program is instrumented to notify the monitors for each of message sent and received.

As an example, we consider a system of a self driving car in which the safe distance between two cars should not be violated more than a specific time denoted x. The system behaviour is defined with a timed automaton that contains a clock x. The generated monitor warns the driver about violations of this constraint via the Robot Mindstorms™ Liquid Crystal Display.

Conclusion and Discussion

This approach aims to monitor Quality of Service properties. The generated monitor does not control the implementation but only checks if the designed behaviour is correct during execution. If not, the user/system is notified who may choose to modify the QoS level. This approach can be justified for a set of systems in which the time is only one of the concerns of the system. In those cases, developers do not necessarily want to use a time control framework like Giotto to implement their system. We are currently working on a connection between the generated monitor and BIP [START_REF] Basu | Modeling Heterogeneous Real-time Components in BIP[END_REF]. This connection allows supervision of a BIP execution with a monitor generated for C.

http://lejos.sf.net


Freddy Mu Ñoz

Olivier Barais

Benoit Baudry

Vigilant usage of Aspects

In the last 10 years the Aspect-Oriented Software Development (AOSD) has gradually become a concern stone in Software Engineering as an engine to reduce complexity and increase reuse by providing modularization of concerns that tend to crosscut. Nevertheless, its use in certain situations can presents some problems that can not only discourage its mainstream adoption, but also hinder the realization of software quality goals. The first problem, the AOSD-Evolution paradox, encompasses the difficulties with evolving software developed using AOSD. The second arises as a result of the invasive nature of aspects. The use of aspects without any control can result in a harmful practice. This work describes these problems and exposes the strength and limitations of the current approaches to solve them. Thus allowing us to reason in a clear fashion about the problems and their solutions, then justifying a contract base approach, which aims to control the usage of aspect without constraining the power of AOSD. m(...

I. INTRODUCTION

The current mechanisms to implement aspects such As-pectJ [8], allow sophisticated ways to express pointcuts and advice. But fail to (1) define pointcuts abstracting from syntactical properties of the base code, and to (2) control the aspects invasiveness. These deficiencies lead to the following problems:

1) Evolution difficulties, reflected in the called AOSD-Evolution paradox [START_REF] Tourwé | On the existence of the AOSD-evolution paradox[END_REF], this means that software built using AOSD is more modular but less reliable. Then, as the base code evolves aspects pointcuts can miss the desired join points or capture undesired join points. 2) Invasiveness problems, caused by the ability of aspects to access unrestrictedly the base code. These aspects can invalidate some important properties of the system by modifying the program flow or leaving protected data structures in an inconsistent state, then becoming harmful to the base code. Both problems are exacerbated by the obliviousness property [START_REF] Filman | Aspect-oriented programming is quantification and obliviousness[END_REF], which requires aspects to be transparent for the base code, hence allowing it to evolve independently from aspects. Then, as base code evolves, seemingly safe modifications can break pointcuts turning aspects into harmful entities. Furthermore, as base code designers are oblivious about aspects, they have no means to protect their code from them.

The current approaches to solve these problems offer improved mechanisms to AOSD; but fail to either (1) control the aspects invasiveness without constraining its power, e.g. specifying where aspects are not allowed to be invasive, or [START_REF] Clifton | Observers and assistants: A proposal for modular aspect-oriented reasoning[END_REF] to fit aspects with an adequate mechanism to support evolution, e.g. a mechanism that tells when an aspect can do harm. This lack of invasiveness control and evolution support, impacts directly on evolution and reutilization of software built using AOSD, therefore discouraging its mainstream adoption. These deficiencies as the proposed solutions impose a strong need to bring solutions to the AOSD problems, not only encouraging its adoption, but also leading to software that is mode modular and reliable.

Our interest is to analyze the strengths and limitations of the current approaches for solving the AOSD problems. This allows us to reason in a clear fashion about them and propose the beginning of a contract based approach to solve them.

The reminder of this work is organized as follows. Section 2 presents the AOSD problems. Section 3 exposes the current approaches to solve these problems and discusses their strengths and limitations. Section 4 presents the beginning of our approach to solve AOSD problems by controlling its invasiveness. Finally, section 5 concludes and presents the future work.

II. PROBLEMS FROM ASPECTS

Aspects make a great contribution to improve system modularity. Unfortunately, in many situations aspects can carry some problems that can hinder the achievement of a reliable software system. This because, aspects can negatively affect the behavior and evolvability by introducing side effects into the advised base code.

This section exposes the problems that present a major threat for AOSD adoption: AOSD-Evolution Paradox and Invasive aspects.

A. AOSD Evolution Paradox

An intuitive notion is that software built using AOSD is more modular, evolvable and reusable. But contrarily, software evolution and reutilization can be negatively affected by the presence of aspects.

The AOSD-Evolution Paradox [START_REF] Tourwé | On the existence of the AOSD-evolution paradox[END_REF], encompasses the difficulties that arise when an application created using AOSD tries to evolve. It arises on the insufficiency of the current languages for defining pointcuts (crosscutting languages), to abstract over structural properties of the base code. Pointcut specification tends to be very concrete and make explicit assumptions about program structures. Then, as software evolves, pointcuts can lose correct join points or capture wrong join points leading to unexpected behavior or even make the software to break down. This means that AOSD leads to software that is more modular but with a reduced evolvability. The aspect will also apply to the method m(..) in E, no matter if it is needed or not. In the worst case, the class E has no need of the aspect and it application will lead to an incorrect behavior (Figure 2). In this case, the pattern matching over names allows developers to abstract over syntax, and thus avoid enumerating on join points. This provides some flexibility, but in some situations it is not enough. However, if the software is small enough, aspect and base code changes will be easy to coordinate when required. In realworld projects, size and complexity increase very fast making aspects management tricky and error-prone.

B. Invasive aspects

In order to perform separation of concerns and provide security, each paradigm promotes its own way of encapsulating concerns. For example the object-oriented paradigm encapsulates concerns in classes, fields and methods, defining a protection level for each one of them, ensuring that properties access will be respected.

Aspects can break the encapsulation that each paradigm provides, this because they have the ability to interject functionalities at almost any point in the base code, then leaving properties vulnerable to any change from the aspect side. This rupture can be fruitfully used in several situations resulting in a proper introduction of functionalities and flexibility; invalidating or twisting properties that can be considered undesirable.

However, aspects can invalidate some of the already existing desirable properties of the system, therefore becoming harmful to the base code. They can introduce side effects, by partially replacing procedures, modifying the control flow, assigning new values on protected fields, etc. Moreover, aspects can add a tight coupling to the base code, and consequence of the obliviousness property, any seemly safe modification in protected properties can break aspects leading to data inconsistencies or incorrect behavior. Hence, as they can compromise sensitive system properties, they represent a threat for software security [START_REF] De | On the importance of the separation-of-concerns principle in secure software engineering[END_REF] and reliability.

The real problem with aspects breaking encapsulation, is the absence of mechanisms to prevent aspects to invalidate desirable and important properties of the system without constraining the power of AOSD. The java code on top corresponds to a secured class with private fields and operations. On bottom, an aspect that adds unprotected (public access) fields to the secured class, then assigning them the values of the protected fields and keeping synchronized their values during the exe-cution. This aspect expose protected values maliciously, and as the base code is oblivious about it there is no mechanism to prevent this kind of situation.

III. CURRENT APPROACHES

The major difficulty for AOSD is the behavior assurance, specially when base code tends to evolve. In this scenario the obliviousness property and the tight coupling of aspects with the base code become a two edged sword. By one side increasing modularity, but representing a threat to software reliability on the other.

This section presents the current approaches to solve or reduce AOSD problems, categorized according to the means they use.

A. Guildelines

These approaches are intended to offer guidelines about good practices to avoid the existing problems related with the use of current AOSD technologies.

• An analysis of the limitation in the current AOSD mechanisms is carried out in [START_REF] Mceachen | Distributing classes with woven concerns-an exploration of potential fault scenarios[END_REF], thus leading to a set of guidelines for a good usage of those mechanisms in order avoid their limitations, hence overcoming evolution and invasiveness problems.

• The defects of the current crosscutting languages are studied in [START_REF] Tourwé | On the existence of the AOSD-evolution paradox[END_REF], then generating a set of facts about the languages gaps that can be used as a guideline to pass over them.

• Kiczales and Mezini in [START_REF] Kiczales | Separation of concerns with procedures, annotations, advice and pointcuts[END_REF] perform an study of the different mechanism for concern separation. They emphasize the fashion and the flexibility that those mechanisms offer to localize concerns. By distilling a set of guidelines, they provide to developers an orientation about which mechanism is better suited for concern separation in a given scenario.

• Rinard et al. focused on the interaction between advice and methods propose a classification system for Aspect-Oriented Software [START_REF] Rinard | A classification system and analysis for interactions in aspect-oriented programs[END_REF]. This enable developers to reason modularly about aspects behavior when interacting with the base code, and to focus on the aspects causing nonmodular interaction.

• Dean Wampler explores the translation of design principles from Object Orientation to Aspect Orientation [START_REF] Wampler | Noninvasiveness and aspect-oriented design: Lessons from object-oriented design principles[END_REF].

Intended to avoid the problems related to invasive aspects, those principles should tell what type of restrictions and coupling between aspects and software entities are appropriate according to a given scenario in order to allow noninvasiveness. Guidelines make a contribution telling developers and designers (aspects and base code) what to do in a given situation when aspects are used, or how to use the current mechanism to be better prepared to support evolution and limit aspects invasiveness. For language designers, they tell which are the points that need more effort and development in order to carry the current mechanism to a mature state. But, as with any guideline there is no concrete solution, and to follow a guideline gives no confidence that the result will perform as expected.

B. Code Based

Code based approaches are intended to deliver new languages or extend an existing language in order to provide the functionality and flexibility necessary to avoid AOSD problems.

• Kiczales and Mezini in [START_REF] Kiczales | Aspect-oriented programming and modular reasoning[END_REF] proposes the foundations for Aspect-aware interfaces. Modules interfaces that are aware about the existence of an aspect advising them. They describe how aspects will crosscut modules and how modules will interact between them. This enable modular reason by exposing how aspects interact with the base code, therefore leading to a better evolution support by propagating aspects and base code changes across interfaces.

• Sullivan et al., based on the information hiding principle [START_REF] Parnas | On the criteria to be used in decomposing systems into modules[END_REF] present a new kind of interfaces called XPI [START_REF] Sullivan | Information hiding interfaces for aspect-oriented design[END_REF], [START_REF] Griswold | Modular software design with crosscutting interfaces[END_REF]. Abstracting the crosscutting behavior, they impose several documented rules in a design pattern fashion that have no explicit representation in either aspect or base code. This approach constrain the manner in which code is written, making the base code and aspect implementation to rely on the XPI definition. Hence, evolution will be controlled through the XPI.

• J. Aldrich proposes Open Modules [START_REF] Aldrich | Open modules: Modular reasoning about advice[END_REF] , a modular system for aspects, which focuses on the exposure of join pointss such that modules constructs export pointcuts as a part of their specifications. This leads to aspects that depends only on the details exposed by modules specifications and not on the internal details of each module. For this modular system, he proposes a language called "Tiny Aspects", which tries to assure that aspects will not change the program behavior in an unexpected way. This enable programmers to separate concerns and reason about them in a modular way abstracting from hard implementation details.

• Gyble and Brichau propose a prolog-like crosscutting language [START_REF] Gybels | Arranging language features for more robust pattern-based crosscuts[END_REF]. This language is intended to describe pointcuts as conditions on properties, then allowing to describe more expressive join points, based more on semantic than structural properties.

• In [START_REF] Ostermann | Expressive pointcuts for increased modularity[END_REF], a prolog like crosscutting language called AL-PHA is proposed. Intended to provide a rich model of programming semantics jointly with abstraction mechanism, it allows to write more expressive pointcuts, targeting join pointss by its semantical properties.

• Dantas and Walker proposes harmless advice. A piece of computation as standard advice, but being constrained to prevent it from interfering with the base code underlying computation. This unable the advice to affect data structures or change the base control flow. In [START_REF] Daniel | Harmless advice[END_REF], they present the core language as well as the operational semantics and type system for this advice system.

• Clifton and Leavens propose Spectators and Assistants for AspectJ [START_REF] Clifton | Observers and assistants: A proposal for modular aspect-oriented reasoning[END_REF]. In order to enable AspectJ's modular reasoning, they propose to classify aspect according to their effect on program flow. Spectators, that do not modify the behavior of the underlying program and assistants, that modify the behavior of the underlying program affecting its flow. Then, this classification allows the program modules to accept explicitly the assistance of assistant aspects.

• In [START_REF] Tyszberowicz | Constraining aspect usage[END_REF], an approach to constraint aspect usage is proposed. The underlying idea is to restrict aspect usage by imposing several constraint on their application. Such restriction range from restrict the data that aspects can modify to the actions that advice code can perform when reaching a join points, the moments and places in which aspects are allowed to intervene.

• Recebeli proposes the notion of aspects purity [START_REF] Recebli | Pure aspects[END_REF]. A pure aspect is an aspect that promises not to alter the behavior of an specified set of base code pieces. He present a prototype of this notion, called Pure Aspects, an extension to AspectJ compiler intended to reduce the harm that aspects can do.

• In [START_REF] Sihman | Superimpositions and aspectoriented programming[END_REF], the concept of Superimpositions is imported from distributed systems to aspects. Then they are a collection of generic aspects and singleton classes that are super imposed with the base code to generate an augmented final program. Superimpositions augment the semantics of AOP by allowing to express interactions and relations among generic aspects, combine collections of them.

All these code based approaches are intended to overcome the AOSD problems, by the proposition of new interfaces [START_REF] Sullivan | Information hiding interfaces for aspect-oriented design[END_REF], [START_REF] Griswold | Modular software design with crosscutting interfaces[END_REF], [START_REF] Aldrich | Open modules: Modular reasoning about advice[END_REF], [START_REF] Kiczales | Aspect-oriented programming and modular reasoning[END_REF], languages [START_REF] Gybels | Arranging language features for more robust pattern-based crosscuts[END_REF], [START_REF] Ostermann | Expressive pointcuts for increased modularity[END_REF], [START_REF] Daniel | Harmless advice[END_REF], [START_REF] Tyszberowicz | Constraining aspect usage[END_REF] and extensions to existing languages [START_REF] Recebli | Pure aspects[END_REF], [START_REF] Clifton | Observers and assistants: A proposal for modular aspect-oriented reasoning[END_REF], [START_REF] Sihman | Superimpositions and aspectoriented programming[END_REF]. But each approach presents its own limitations.

In order to provide harmless advice, Open Modules [1] and Harmless advice [START_REF] Daniel | Harmless advice[END_REF] constrain the power of AOSD by forbidden aspects to be invasive. XPIs [START_REF] Sullivan | Information hiding interfaces for aspect-oriented design[END_REF], [START_REF] Griswold | Modular software design with crosscutting interfaces[END_REF] do not define a concrete interface, instead they define a coordinate coding style between aspects and base code. Logic based crosscutting languages [START_REF] Gybels | Arranging language features for more robust pattern-based crosscuts[END_REF], [START_REF] Ostermann | Expressive pointcuts for increased modularity[END_REF] can be computationally too expensive like to scale real world applications. Pure Aspects [START_REF] Recebli | Pure aspects[END_REF] only assure harmless when aspects have pure intentions, but giving no assurance with other aspects.Spectators and Assistants [START_REF] Clifton | Observers and assistants: A proposal for modular aspect-oriented reasoning[END_REF] offer just a general granularity level about aspect affecting the behavior leaving more fine grain level unexplored (i.e: aspect modifying data fields). Finally, the constraint language presented in [START_REF] Tyszberowicz | Constraining aspect usage[END_REF] appears to be a promising idea, but is just a notion and no details are given.

C. Analysis

Analysis approaches are characterized by the analysis of properties and behavior present in software built using AOSD mechanisms. Most than a solutions, they are an orientations and a tools to predict when AOSD can become a threat to evolution and reliability.

• Koppen and Storzer propose a pointcut delta analysis [START_REF] Koppen | PCDiff: Attacking the fragile pointcut problem[END_REF], [START_REF] Störzer | Using pointcut delta analysis to support evolution of aspect-oriented software[END_REF]. This delta analysis operates by comparing the changes in the set of matched join points for two different version of the base code. It serves as a mean to diagnose and help programmers to find bugs and reveal unexpected changes in the behavior of broken pointcuts.

• Guided by the goal of specification and verification of aspect-oriented systems, [START_REF] Katz | Diagnosis of harmful aspects using regression verification[END_REF] proposes a regression test for AOSD in order to diagnose if a particular aspect is harmful or not for the base code. Harmful aspects analysis allows a weakening of obliviousness while maintaining extensibility, diagnosing malicious or inadvertent corruption of the desired properties of the underlying system.

• Based on algebraic foundations, a program analysis is proposed [START_REF] Roberto | A disciplined approach to aspect composition[END_REF]. Here aspects are seen as a "program transformation function", or a function that maps programs to programs, and the effects of the weaving process can be understood in terms of algebraic transformations. Around this definition, theoretical properties (commutativity, associativity and identity) and rules are associated to aspect compositions (in e.g. precedence rules for compositions). This allows to reason about composition, exposing its problems. Aspect analysis appears to be promising to support the evolution of software built using AOSD, by alerting when an aspect may have undesired effects on the system. But those approaches can be either too inefficient [START_REF] Koppen | PCDiff: Attacking the fragile pointcut problem[END_REF], [START_REF] Störzer | Using pointcut delta analysis to support evolution of aspect-oriented software[END_REF], [START_REF] Katz | Diagnosis of harmful aspects using regression verification[END_REF] (too expensive in computation time) or too abstract [START_REF] Roberto | A disciplined approach to aspect composition[END_REF] (may be impossible to implement without expensive computations) like to scale to real systems.

D. Model based

Model based approaches make use of a high abstraction level to deliver a solution that relies in modeling or meta modeling facilities to avoid AOSD problems.

• In [START_REF] Kellens | Managing the evolution of aspect-oriented software with model-based pointcuts[END_REF], a Model-based pointcut definition is proposed.

These pointcuts are defined in terms of a conceptual model of the base program, rather than referring directly to the implementation structure. This results in joint points based on conceptual properties instead of structural properties of the base program, hence leading to a low coupling of the pointcut definition and base code. These pointcuts are called view-based pointcuts, because they use the formalism of intentional views to express a conceptual model of a program and to keep it synchronized with the source code of that program.

• In [START_REF] Elrad | Motorola weavr: Model weaving in a large industrial context[END_REF], the Motorola WEAVR is proposed. This is a tool that can weave aspects defined at model level, by using Specific Domain Languages and UML 2.0 . These aspects are defined as abstract entities based on a transitionsoriented state machine, and the way in which they affect the base code is defined in terms of a novel join point model. This model is composed of call expressions, timer set actions and state transitions. The representations of pointcuts and advises (called connectors) is a finite state machine, where connectors always contains a start and an end state. This approach enables aspects to be defined in terms of a system specification without requiring a complete knowledge of its implementation, then giving additional robustness to aspects. The model based approaches abstract from code properties (eliminating the tight coupling between aspects and code) and bring generality to the aspect representation. Then, being promising to overcome evolution problems. Nevertheless, these approaches need a deeper study to determine the concrete impact of using models to define aspects and overcome the AOSD problems.

E. Contracts for Aspects

These approaches make use of Design by Contract [START_REF] Meyer | Applying "design by contract[END_REF] in order to avoid AOSD problems and increase the confidence in aspects usage.

• Skotiniotis and Lorenz propose some notions for Design by Contract applied to aspects [START_REF] Skotiniotis | Cona: aspects for contracts and contracts for aspects[END_REF]. They emphasize in the help that Design by contract can give to ensure, that aspects capture crosscutting concerns adequately, and aspects do not interfere with some other parts of the program. Later in [START_REF] Lorenz | Extending design by contract for aspect-oriented programming[END_REF] they study the combination of aspects and contracts, then generating a classification of aspects according to its interaction with contracts and determining who must be blamed in the case of contract violation. An implementation of this classification has been made in CONA an aspect based Design by Contract tool for Java.

• In [START_REF] Klaeren | Aspect composition applying the design by contract principle[END_REF] assertions are used as a means to validate aspect composition, verifying if a class or an application contains a suitable sets of aspects for whom the weavage can be validated. This validation is performed in respect to a set of specifications included as a contract that assess the correctness of the composition according to the design. Those specification can, for example, prohibit the application of two aspects in the same place, or enforce the interdependence of two aspects.

• In [START_REF] Lagaisse | Managing semantic interference with aspect integration contracts[END_REF], Aspect integration contracts (AiC) are presented.

Based on the idea of contracts for components, these contracts specify the permitted interference between an aspect and the base code. AiC are composed of the aspect requirements specifications (what aspects require from the base code), aspect functionalities and effects specifications (what aspect do with the base code), and the permitted interference specification (what aspect can do with the base code). Then, these contracts state that all the specifications are respected in order to weave aspects with the base code. In [START_REF] Skotiniotis | Cona: aspects for contracts and contracts for aspects[END_REF], [START_REF] Lorenz | Extending design by contract for aspect-oriented programming[END_REF], the interaction between contracts and aspects is studied. It gives an idea of how could be the blaming process in the case of assertions violation. But leaves several questions on the table like "How aspects can be contractualized to restrict their application to base program?" or "How contracts can assure that aspects adequately capture crosscutting concerns?". The approach of [START_REF] Klaeren | Aspect composition applying the design by contract principle[END_REF], allows to reason about interaspects interaction and aspects-methods interaction by defining weaving specification in a Design by Contract fashion. Finally, AiC [START_REF] Lagaisse | Managing semantic interference with aspect integration contracts[END_REF] have a lot of specifications about specific aspects and the interference that the base code allows from them. Then, may being too complex and specific to a software version like to be practical and scale to the real world.

We think that the current approaches to solve AOSD problems do well a part of the work, being partial solutions. But instead, we hope that a complete solution will be one that controls and does not constrain aspects invasiveness and suits aspect to better support evolution in a concrete fashion.

IV. TOWARDS CONTRACTS

Design by Contract [START_REF] Meyer | Applying "design by contract[END_REF] has proved its value in the objectoriented world, by specifying what a program is intended to be through precondition, postcondition and invariants. The presence of contracts in an object-oriented application increase its reliability and the confidence that its components have [START_REF] Le Traon | Design by contract to improve software vigilance[END_REF].

We think that contracts applied to aspects will result in a good way to reduce the AOSD problems and increase the confidence that developers have in aspects. Those contracts will bind responsibilities to aspects by specifying what the base code expects from them, thus ensuring that only aspects that satisfy contracts will have the right to interact with the base code.

Our aim is not to constrain the power of AOSD, but control aspects invasiveness and fit aspects to better support evolution. By being vigilant about the usage of AOSD, developers and designers reduce the risk of unexpected side effects and the harm that aspects can do.

A. Two sides contracts

In our approach, contracts are represented by a two-side specification. One side belongs to the base code, and specify what kind of aspects are allowed to interact with a given piece of the base code. The other, belongs to aspects and define which kind of advices it contains by placing them through a classification base on their incidence over the base code.

These contracts are roughly similar to their defined by Design by Contract. But instead of preconditions,postconditions and invariants, we have just preconditions and data invariants. While preconditions and data invariants are represented by the base contract side; the aspects side contract serves as a mean to determine if a given aspect can satisfy the conditions stated in the base code contract side. Aspect side classification can be determined automatically by performing static analysis over the aspect code. However, we think that the manual determination of that classification can report benefits by specifying what the aspect behavior must be, instead of rely on hard code deduction.

B. Aspects Classification

In order to allow contract to specify what kind of aspect are allowed to interact with the base code, we propose an aspect classification based on their incidence over the base code. For this classification we first sight three major groups of aspects:

1) Pure behavioral aspects, which only intervene the protected control flow of the base code. 2) Pure data aspects, which only manipulates protected data structures of the base code. 3) Hybrid aspects, which not only intervene the protected control flow of the base code, but also manipulate its protected data structures. Inside each one of this groups we have identified different kind of aspect advice that vary on harm level according on the actions they perform. For example, an aspect which modifies protected data structures and override protected methods will be harmful than an aspect that just read values from protected data structures.

This classification will allow us to specify in the contract, which kind of aspects is desired to advise the base code, or to protect the base code against aspects that can do unintentional harm.

C. Contracts violation and evolution

If a contract is violated, it may mean that aspects are not well suited to advise the base code, or base code is not well suited to be advised by aspects. Consequence of this, base code may needs to be refactored in order to be well suited to aspects or aspects might need to be reformulated in order to be well suited to advised the base code.

In the case of evolution, contracts will inform when aspects capture a wrong join point or do not hold the behavior expected by the base code, because it will violates base code specifications. Hence, when the source code evolves independently from aspect, we have a mechanism to know if aspects will perform harmful.

D. No more obliviousness

The obliviousness property of AOSD requires aspects to be transparent for the base code, thus meaning that the base program must be ignorant about the aspects that advice it. The placement of contract between the aspect and the base code breaks the obliviousness property of aspects and make the base code aware about the existence of aspects that can be weaved with it. We think that the obliviousness property is just desirable, and as exposed by Rashid and Moreira in [START_REF] Rashid | Domain models are NOT aspect free[END_REF], abstraction, modularity and composability are more fundamental properties.

E. Close approaches

Some of the previously presented approaches are close to our proposition. The regression test proposed in [START_REF] Katz | Diagnosis of harmful aspects using regression verification[END_REF] have similarities because it tries to state when an aspect can be harmful by making use of structural properties of the aspect and the base code. Our aspect classification is similar to the classification proposed in [START_REF] Rinard | A classification system and analysis for interactions in aspect-oriented programs[END_REF], but instead of focus our attention on the interaction aspect-base code, we focus our classification on the behavioral incidence of aspects over the base code. Pure Aspects [START_REF] Recebli | Pure aspects[END_REF] only assures that aspects presenting purity will perform harmless. Contracts not only assure that aspects with "purity" will perform harmless but also inform about the harm that non pure aspects can do.

The classification of Assistants and Spectators [START_REF] Clifton | Observers and assistants: A proposal for modular aspect-oriented reasoning[END_REF] is quite similar to our flow classification of aspects, but we try to address a more fine granularity level and the case when aspects affect data. While this approach breaks the obliviousness property in a such way that the base code is aware about specific aspect advising it, then adding coupling between the base code and the aspects, we make the base code aware about a special kind of aspects (defined in our classification) that can potentially advise it.

Aspect Integration contracts [START_REF] Lagaisse | Managing semantic interference with aspect integration contracts[END_REF] are very closer to our idea. But, instead of make contract assertions on specific aspects (referencing them by their names), we make assertions on our proposed classification in order to give more generality and simplicity to our contracts.

While the approach proposed by Open Modules [START_REF] Aldrich | Open modules: Modular reasoning about advice[END_REF] and Harmless advice [START_REF] Daniel | Harmless advice[END_REF] constraint the power of AOSD in order to achieve less invasiveness, we do not constrain the power of AOSD, instead we try to save its benefits by controlling it and telling when it can be harmful. Interfaces approaches like XPI [START_REF] Sullivan | Information hiding interfaces for aspect-oriented design[END_REF], [START_REF] Griswold | Modular software design with crosscutting interfaces[END_REF] and Aspect-aware interfaces [START_REF] Kiczales | Aspect-oriented programming and modular reasoning[END_REF], propose to control the evolution by making aspects and the base code dependent on a single interface. This abandoning the obliviousness property by making the base code aware about aspects. Instead, we abandon the obliviousness property, by establishing a mechanism that do not synchronize the aspect -base code evolution, but informing when aspects will break the base code specifications.

Current contract for aspects approaches [START_REF] Skotiniotis | Cona: aspects for contracts and contracts for aspects[END_REF], [START_REF] Lorenz | Extending design by contract for aspect-oriented programming[END_REF], [START_REF] Klaeren | Aspect composition applying the design by contract principle[END_REF] are focused on the establishment of pre and post conditions in the Design by Contract fashion, then trying to specify what the weaved application must be. Instead we believe that it is more adequate to adopt contracts that make assertions on what how aspects can influence the base code, then specifying what the base code expect from aspects. The aspect usage constraint approach [START_REF] Tyszberowicz | Constraining aspect usage[END_REF] is similar to our notion, but instead of constrain single aspects according to given conditions, our aim is to specify what well classified aspects are allowed to interact with.

We think that the guidelines proposed by Wampler in [START_REF] Wampler | Noninvasiveness and aspect-oriented design: Lessons from object-oriented design principles[END_REF], can be used with our approach of contracts in order to reduce the coupling of aspect with the base code and encouraging the use of specifications. Approaches like [START_REF] Ostermann | Expressive pointcuts for increased modularity[END_REF], [START_REF] Daniel | Harmless advice[END_REF], [START_REF] Tyszberowicz | Constraining aspect usage[END_REF] that propose new crosscutting languages or guidelines like [START_REF] Mceachen | Distributing classes with woven concerns-an exploration of potential fault scenarios[END_REF], [START_REF] Tourwé | On the existence of the AOSD-evolution paradox[END_REF], [START_REF] Kiczales | Separation of concerns with procedures, annotations, advice and pointcuts[END_REF] are completely compatible with our approach because they try to change, augment or advise the way in which join point are selected, while we try to specify what aspect advise can do with the advised join points.

V. CONCLUSIONS AND FUTURE WORK

The aim of this paper was to show the current problems that without a solution presents a major threat against a mainstream adoption of AOSD. By exposing the current approaches to solve them, we were able to reason about their strengths and limitations, then proposing a novel approach based on Design by contract principles. This approach will increase the confidence in aspects, allows to be vigilant about their usage by controlling their incidence over the base code and give earlier information when facing evolution.

Our current work is focused on validate this approach by the development of a prototype to suit the AspectJ compiler with our notions of contracts.

Fig. 1 .

 1 Fig. 1. Aspect applied to three different classes

EFig. 2 .

 2 Fig. 2. Aspect applied to a class that does not need it

Fig. 3 .

 3 Fig. 3. Security violation using aspects

(this.credit>amount){ 11 return true; 12 } 13 else return false; 14 } 15 public void withDraw(double amount){ 16 if(this.canBuy(amount)){ 17 this.credit=this.credit-amount;

	1 public class SecuredClass {
	2	private String Username;
	3	private double accountID;
	4	private double credit;
	5	public SecuredClass(String username){
	6	//obtain higly confidential data
	7	//using the username
	8	}
	9	private boolean canBuy(double amount){
	10 if18 }
	19	}
	20	...
	21 }
	1

public privileged aspect Leak { 2 public String SecuredClass.publicUsername; 3 public double SecuredClass.publicAccountID; 4 public double SecuredClass.publicCredit; 5 after(SecuredClass secured): 6 execution(* SecuredClass

		.*(..))&&target(secured){
	7	secured.publicUsername=secured.Username;
	8	secured.publicAccountID=secured.accountID;
	9	secured.publicCredit=secured.credit;
	10	}
	11	after

(SecuredClass secured): 12 execution(SecuredClass.new(..))&&target(secured){

		Base Code
	13	secured.publicUsername=secured.Username;
	14	secured.publicAccountID=secured.accountID;
	15	secured.publicCredit=secured.credit;
	16	}
	17 }	Aspect Code


M Monperrus
email: martin.monperrus@ensieta.fr

J Champeau

B Hoeltzener Ensieta

Counts count

Based on the 2006 edition of the Model Size Metrics workshop, we believe that counts are undervalued as useful model metrics. In this position paper, we provide arguments from the literature so as to consider counts as important metrics for the model measurement. We then state associated issues and sketch a model-driven framework to raise the abstraction level of the implementation of model metrics, starting with count metrics.

Introduction

According to historians [START_REF] Goody | The Domestication of the Savage Mind[END_REF], writing was invented by the end of the 4th millennium BC to record counts, for instance the number of animals in a herd. Indeed, the first quantitative knowledge of any system is a count.

However, in regard to the previous edition of this workshop 1 , it seems that model measurement by means of counts is undervalued . The following quotations are given so as to illustrate this statement. McQuillan et al. [START_REF] Mcquillan | Some observations on the application of software metrics to UML models[END_REF] state that the majority of the UML metrics proposed are primarily simple counting metrics. Weil et al [START_REF] Weil | Model size metrics research in motorola[END_REF] do not believe, however, that simply counting the element in a model to produce a single number provides a meaningful result. And Stoerrle [START_REF] Störrle | On different notions of model size[END_REF] considers that the simplest and most general approach is to always count everything, and instrument the count by an external weight table. The substantive "simple" is used three times: simple, simply, simplest without any counterbalancing adjectives.

In fact, we agree with the cited authors, a count itself is really simple. But replaced in a broader context, we believe that counts i.e., number of metrics, are more important than they first seem to be.

To set the context of our reflexion on model metrics, we consider the Goal-Question-Metric (GQM) approach [START_REF] Basili | The goal question metric approach[END_REF]. The GQM approach helps to specify a measurement system targeting a particular set of issues. Since this position paper does not introduce a particular metric, one cannot use directly the GQM approach, but a kind of GQM at a higher level of abstraction. In fact, we aim to show that count metrics are relevant answers to several questions linked to a primary goal that is measuring models. To sum up this point, we now consider the standard GQM notation: Goal Improve the quantitative knowledge on models from the modeler point of view. Question #1 What model metrics can be related to development cost? Question #2 What model metrics can be related to psychological complexity? Question #3 What model metrics can be related to product defects? Metrics The family of count metrics.

The paper is built as follows. The premises of our reflexion are elements of the software metrics literature. These elements are grouped into propositions that are: the software measurement literature is rich of useful count metrics; the Occam's razor principle defends counts; industrial measurement plan may include counts; complex metrics may be interestingly grounded by counts; counting is a fully-fledged modeling goal. These propositions support our initial claim: Count counts. We then discuss the consequences and present a model-driven framework as a preliminary answer.

Main arguments

Count metrics are important in software engineering

Metrics in model-driven engineering (MDE) can be compared with their software metric ancesters. Existing software metrics are defined as counts or are countbased. In this perspective, the undervaluation of counts in MDE described above constrats with the rich literature on counts in the software measurement domain.

For instance, whatever the definition (see [START_REF] Jones | Programming Productivity[END_REF] for several variations), the lines of code metric is a count. Empirical studies based on historical data have shown that the line of code metric is relevant to the correlation between the software product and the cost [START_REF] Boehm | An Overview of the COCOMO 2.0 Software Cost Model[END_REF], to evaluate an attribute of the software quality (e.g. the defect rate metric), or to study the team productivity [START_REF] Jones | Software Productivity and Quality Today: The Worldwide Perspective[END_REF].

Another example is the structural complexity SC [START_REF] Zuse | Software Complexity[END_REF] (see figure 1). The structural complexity is part of the psychological complexity of software [START_REF] Henderson-Sellers | Object-Oriented Metrics, measures of complexity[END_REF]. It impacts the time to understand and modify a system accordingly. The definition of SC [START_REF] Zuse | Software Complexity[END_REF], exposed in equation 1, involves the number of edges |A| and the number of modules |M |.

SC = |A| |M | (1)
The goal of this paragraph is not to list all software metrics which are counts but to emphasize that known and useful software metrics are counts or countbased. This is a clue not to discard counts in the upcoming generation of accepted model metrics.

The application of the law of parsimony to metrics

Using more sophisticated measures do not necessarily guarantee better results. Zuse [START_REF] Zuse | Software Complexity[END_REF]410] Fig. 1. The structural complexity [START_REF] Zuse | Software Complexity[END_REF] is based on the counts of dependency edges and modules The Occam's razor, also known as the law of parsimony [START_REF] Baker | Simplicity[END_REF], is a principle most commonly stated as follows: Entities are not to be multiplied beyond necessity. It is a polymorphic principle and one of its instance is the Keep It Short & Simple (or K.I.S.S) engineering rule. This principle applied to model metrics is a strong argument in favor of counts compared to more complex metrics. Counts are very simple metrics, but may give model users the appropriate information.

Considering that the law of parsimony has been proven as a powerful principle in both science and philosophy (e.g. [START_REF] Baker | Simplicity[END_REF]), counts should be considered with a positive a priori judgement.

Counts ground more complex metrics

Counts are simple but can ground more complex metrics. For instance, in [START_REF] Lo | Syntactical construct based apar projection[END_REF] (cited in [START_REF] Kan | Metrics and Models in Software Quality Engineering[END_REF]) a linear relationship is found with a high statistical confidence between defects and some language constructs in a given technical context (# denotes the number of ):

Field defects = 0.11#if then + 0.03#calls (2)
In this case, a defect measure is derived from some counts. In a similar manner, the Cocomo model [START_REF] Boehm | An Overview of the COCOMO 2.0 Software Cost Model[END_REF] outputs a cost with several inputs. Inputs are cost drivers and a size parameter. In a similar technical and management context i.e. for similar cost drivers, the main parameter is a count of lines of code.

Since counts are able to ground more complex metrics, they must be carefully considered. The first way to build more complex metrics is to define a weighted sum of counts (as in equation 2 and emphasized in [START_REF] Störrle | On different notions of model size[END_REF] and [START_REF] Weil | Model size metrics research in motorola[END_REF]). It is not the unique solution, non linear combinations in a bigger space of functions can be explored.

Counts are part of industrial development processes

Counts are valuable enough to be adopted in an industrial context. Cheng et al. [START_REF] Cheng | Lessons learned from automated analysis of industrial uml class models (an experience report)[END_REF] examine the automated metrics-based analysis and detection of design Table 1. Counts of violations of a given pattern from [START_REF] Cheng | Lessons learned from automated analysis of industrial uml class models (an experience report)[END_REF] guideline violations in the Siemens context. In fact, the metrics explored in this paper are counts of violations of a given pattern (see table 1) and ground the whole analysis. In another company, Motorola [START_REF] Weil | Model size metrics research in motorola[END_REF], a list of around 150 counts of UML elements is used to control the model-driven development process.

Counting is a fully-fledged modeling goal

Modeling goals are multiple [START_REF] Schmidt | Model-driven engineering[END_REF]: execution, test generation, transformation, etc.

In domains where textual artifacts are historically done, modeling is a way to isolate and count concepts. For instance, expressing software and system requirements with models allows a precise count of explicited elements [START_REF] Costello | Metrics for requirements engineering[END_REF]. These counts are difficult to retrieve with textual requirements with a similar validity and reliability. In such cases, counting is part of the primary modeling goals.

Consequences

This section discusses the consequences and challenges raised by the fact that counts count.

What artefacts in a model need to be counted?

The first challenge is to determine what needs to be counted in a model. A goal, a metamodel, and a corpus of models set the context of an empirical answer. Effectively, according to the GQM approach, a goal precises the question. A model space is identified with a metamodel or a part of a metamodel. For instance, what are the elements of UML2 models to be counted and given as inputs of a cost estimation model? Furthermore, since the quality of a metric resides on its empirical validation [START_REF] Basili | A methodology for collecting valid software engineering data[END_REF], a validation must be done on a statistically big enough corpus of data, with as less as possible of uncontrolled variables. Unfortunately, our community does not yet have such a corpus of data. By analogy with the non model-based database, maintained by the ISBSG [START_REF]The International Software Benchmarking Standards Group[END_REF], a database of count metrics of models and their associated dependent variables would be of great use to select count metrics and validate count based derived metrics. It is to be noted that the confidentiality of industry data obstruct the making of database. Contrary to whole models, count metrics have the advantage to be almost completely free of business information, yet are a kind of signature of models.

How are these artefacts counted?

As stressed in [START_REF] Baroni | Using OCL to formalize object-oriented design metrics definitions[END_REF] the natural language is not enough to precisely define metrics. For instance, in the figure 1, do signatures include parameters name? To that extent, an issue is to rigorously define what to count.

We also consider that the implementation of count metrics should satisfy the following requirements:

1. The model measurement tool is accessible via a command-line interface. 2. The model measurement tool integrates into a modeling environment. 3. The code includes an API to implement estimation models on top of count metrics. 4. The model measurement tool let the modeler to tailor implemented count metrics. 5. The model measurement tool let the end-user to define its own business relevant metrics. 6. The model measurement tool is independent of a specific persistence format.

Marinescu et al. [START_REF] Marinescu | Towards a simplified implementation of object-oriented design metrics[END_REF] underline the issue of the implementation complexity of object-oriented metrics. By analogy, and regarding to the above requirements, we assume that the implementation of model metrics, including count metrics, introduces a similar complexity. Consequently, it raises the development and maintenance cost of a modeling environment and may hamper the code quality of the whole tool. In section 3.3 below, this issue is adressed with an abstraction level to define model metrics from which implementation and integration into a modeling tool are automatically derived.

Model-driven implementation of count metrics for DSMLs

Motivation On the one hand, counts count. On the other hand, the implementation of count and count-based metrics can be costly. The development of a domain-specific modeling language (DSML) is usually done with tight time-tomarket and cost constraints [START_REF] White | Simplifying the development of product-line customization tools via model driven development[END_REF]. Thus, several frameworks and techniques try to generate as much as possible of the DSML modeling environment and associated tools (eg. [START_REF] Lédeczi | Composing domain-specific design environments[END_REF]). Our motivation is to leverage code generation for the DSML metric implementation, starting with counts, to eventually give an enhanced editor with metric capabilities. The design of a DSML environment starts with the metamodeling activity. The metamodel identifies the concepts of the domain and their relationships. Tools are implemented to create, edit and browse models as well as to check the conformity to the metamodel. Frameworks exist to generate such tools from a metamodel (e.g. EMF/GMF2 ).

Then, the DSML designer defines the metrics at a higher level of abstraction than code. The family of count metrics defines an abstraction level. Each metric of this family is specified by a predicate [?]. The value of the metric is the number of elements that satisfy the predicate. For sake of brevity, we only make a short presentation of predicates. A predicate is a function that takes an object as input and makes tests on it to determine if it has to be counted. Predicates refer to the concepts expressed in the metamodel. The tests are made on type, attribute values and/or referenced objects. A predicate can be as long and complex as needed. A predicate can be expressed in a metric specific language or in an existing query language (e.g. OCL). Two examples of predicates in an OCL-like language are shown in figure 3.

A toolchain generates the DSML modeling environment, then compiles the declarative description of metrics directly in the modeling tool to augment it with counting capabilities (the two central activities of the figure 2).

Finally, the DSML user sees its model changes instantly reflected in the metric values. This approach has three major advantages:

--metric #1: number of leaf abstract classes self.isTypeOf(Class) and self.abstract = true and self.children->size() = 0 --metric #2: number of too big use cases self.isTypeOf(UseCase) and self.includedUsesCases->size() > 10 Fig. 3. Examples of predicates expressed in OCL metrics are defined at a higher level of abstraction without caring about how this can be implemented in a DSML modeling environment; -the implementation of the enhanced editor is generated; -DSML users can edit and measure models in the same environment.

Implementation We are developing a prototype of this framework where the metamodel is expressed in Ecore 3 , and the predicates in Kermeta 4 , which has good query capabilities. EMF/GMF generate editors in Java and the prototype compiles the predicates inside the editor Java code.

Conclusion

We presented a set of arguments in order to rehabilitate counts as first class citizens for the model measurement:

software measurement history involves important count metrics; -the law of parsimony prefers simple metrics; -counts ground more complex metrics; -counts are part of industrial measurement processes; -counting is a fully-fledged modeling goal.

We hope that these arguments can provide a fertile basis for the discussion during the upcoming workshop. We then discussed the consequences and sketched a model-driven framework for count metrics. The contribution of this approach is to give an instant, reliable and low cost implementation of count metrics seamlessly integrated into modeling tools.

  one or more non-base classes 0 5 Interface to class expected but defined improperly 1 53 Two methods exist in the model with the same signature 1 0 Two objects exist in the model with the same name 5 23 Parent accessing attributes/operations of child class 0 2

Fig. 2 .

 2 Fig. 2. Model-driven engineering of counts

1

  Model Size Metrics workshop at Models'2006, Genova, october 2006

Eclipse/Graphical Modeling Framework, see www.eclipse.org/emf

Acknowledgments The authors would like to thank B.Baudry and the anonymous reviewers for helpful comments. This work is supported by a DGA grant.