J Fruitet
email: joan.fruitet@sophia.inria.fr

M Clerc

We compare the results given by different methods to reconstruct cortical sources activity in order to classify EEG in real time. Two motor imagery experiments were performed. The aim was to retrieve from 1 windows of signal which motor imagery task the subjects were performing. The use of cortical activity reconstruction was compared to Laplacian filtering, which is often used in BCI. A recursive algorithm using Student's t-test was used to select relevant cortical sources. The Beamformer method led to an improvement of the classification for the first experiment, which included six motor imagery tasks. The weighted Minimum-Norm method required the use of a specific head model, extracted from the subject's MRI, to improve the classification. It then gave the best results on the second experiment, achieving a classification rate of 77% compared to 71% for direct use of electrode data and 75% for Laplacian filtering and Beamformer.

I.INTRODUCTION

Numerous studies over the last two decades scalp recorded electroencephalography activity (EEG) can be used for non-muscular communication and control systems, commonly called brain-computer interfaces (BCI) [START_REF] Farwell | Talking off the top of your head: toward a mental prosthesis utilizing event-related brain potentials[END_REF][START_REF] Pfurtscheller | Brain-computer interfacea new communication device for handicapped persons[END_REF][START_REF] Wolpaw | An EEGbased brain-computer interface for cursor control[END_REF][START_REF] Birbaumer | A spelling device for the paralyzed[END_REF]. One of the goals of these systems is to offer alternative methods of communication to people suffering from severe motor disabilities.

EEG is non-invasive, portable, relatively very precise temporal resolution, which make it the most widely used recording method for human BCI. Unfortunately, because the signals are measured with electrodes on the surface of the scalp and have crossed the skull barrier, it is difficult to distinguish phenomena which have close origins within the brain. The solution we have focused on is to deconvolve the signals by reconstructing cortical sources that are at the origin of the measurements on the scalp.

Although it has been shown that this approach can improve some BCI [START_REF] Besserve | Analyse de la dynamique neuronale pour les Interfaces Cerveau-Machines : un retour aux sources[END_REF], it is as yet rarely used. On both of our experiments, using reconstructed cortical activity gives better results than directly using electrode data.

II.MATERIALS AND METHODS

A.The Experiment

The users were two right-handed male volunteers, both 25 years old and with no disabilities. They were sitting at 1,5m of a 23' LCD screen and were asked to stay motionles Reconstruction of cortical sources activities for on of electroencephalographic signals. are measured with electrodes on the surface of the scalp and have crossed the skull barrier, it is difficult to distinguish phenomena which have close origins within the brain. The solution we have focused on is to deconvolve the signals by reconstructing the cortical sources that are at the origin of the measurements on

Although it has been shown that this approach can improve some BCI [START_REF] Besserve | Analyse de la dynamique neuronale pour les Interfaces Cerveau-Machines : un retour aux sources[END_REF], it is as yet rarely used. On both of our experiments, using reconstructed cortical activity gives results than directly using electrode data.

ETHODS handed male volunteers, both 25 years old and with no disabilities. They were sitting at 1,5m of a 23' LCD screen and were asked to stay motionless during the experiment. Scalp electrodes were recorded at a sampling rate of 2048Hz, on 64 channels of a TMSI amplifier, using electrode AFZ as ground electrode.

The experiment was composed of 5 to 8 blocks of 12 to 24 trials. Each trial started with the appearance of a fixation cross in the center of the screen, 0.5 seconds before the appearance of an image illustrating one out imagery tasks. The subject had to realize this task during 8 seconds while keeping his eyes on the fixation cross break of 1.5 seconds was observed before the next trial (Fig1). For subject one, the six motor imagery tasks were: playing the bass guitar (the subject's hobby), moving the right index, the right or the left hand and the right or the left foot (Fig. 2). For subject two, only three motor imagery tasks were proposed: moving the right or the left hand or both feet.

B.Preprocessing, feature extraction and classification

To minimize the influence of noise, the signal was re referenced on the mean of the electrodes and then filtered between 4 and 40Hz.

To be compatible with real time experiments, each 8 second trial was divided into 1-second windows with 0.25 second overlap, leading to 29 windows per trial. The goal of the analysis was to recover from each 1 mental task performed by the subject.

We used as classification features the power of the signal recorded at each electrode in 21 frequency bands betwee and 36Hz. When considering cortical activity, after solving an inverse problem, the same features were used, but on cortical activity instead of electrode data.

Reconstruction of cortical sources activities for online classification of electroencephalographic signals.

Joan Fruitet and Maureen Clerc during the experiment. Scalp electrodes were recorded at a sampling rate of 2048Hz, on 64 channels of a TMSI amplifier, using electrode AFZ as ground electrode.

The experiment was composed of 5 to 8 blocks of 12 to e appearance of a fixation cross in the center of the screen, 0.5 seconds before the appearance of an image illustrating one out of six motor imagery tasks. The subject had to realize this task during 8 seconds while keeping his eyes on the fixation cross. A break of 1.5 seconds was observed before the next trial For subject one, the six motor imagery tasks were: playing the bass guitar (the subject's hobby), moving the right index, hand and the right or the left foot (Fig. 2). For subject two, only three motor imagery tasks were proposed: moving the right or the left hand or both feet.

or imagery tasks proposed to the first subject: playing the ng the right index, the right or the left hand and the right or the left foot. The goal of the analysis was to recover which task the user was second windows of EEG signal.

Preprocessing, feature extraction and classification inimize the influence of noise, the signal was rethe mean of the electrodes and then filtered To be compatible with real time experiments, each 8second windows with 0.25eading to 29 windows per trial. The goal of to recover from each 1-second window the mental task performed by the subject.

We used as classification features the power of the signal recorded at each electrode in 21 frequency bands between 6 and 36Hz. When considering cortical activity, after solving an inverse problem, the same features were used, but on cortical activity instead of electrode data.

line classification

A linear support vector machine (SVM) was then used for classification [START_REF] Vapnik | The nature of statistical learning theory[END_REF]. The different methods were evaluated by cross validation, while the parameters were automatically adjusted by a second level of cross validation on the training data sets (see [START_REF] Fruitet | A Comparison of Regression Techniques for a Two-Dimensional Sensorimotor Rhythm-Based Brain Computer Interface[END_REF] for more details).

C.Different methods for extracting cortical activity in real time.

Several methods exist for cortical source activity estimation from EEG recordings. They are generally used on signals that have been averaged over many trials to improve the signal to noise ratio. The challenge to be addressed here is to analyze online data, in which the part of the signal related to the task is very weak.

Our purpose is to use cortical source activity to enhance classification for BCI, so we have used solutions that can be applied on single trials and that are compatible with realtime computation.

The results obtained with these methods were compared to the use of Laplacian filtering which is frequent BCI [START_REF] Mcfarland | Spatial filter selection for EEG-based communication[END_REF].

1) Surface Minimum-Norm

Cortical sources are represented by a large number of dipoles (around 1800) distributed over a surface that models the cortical gray matter. Each dipole represents a cortical macro-column, and the amplitude of the dipole models the bulk activity of the column.

The first stage consists of modeling and solving the forward problem, i.e., computing the lead field matrix L relating the cortical source activity to the electrode measurements. The relationship between the measurements M and the cortical activity S is modeled by

ܯሺݐሻ = ܵܮሺݐሻ + ܰሺݐሻ (1)
where N represents an Gaussian, centered white noise.

The second stage consists of solving the inverse problem. The Minimum-Norm method selects the source activity S that minimizes the difference between the measurements M(t) and the ideal measurements LS(t):

݉݅݊ ௌ ሺԡܯ -ܵܮԡ ଶ ଶ ሻ (2)
Because the of cortical sources is much greater than the number of electrodes, the minimizer is not unique. One method to obtain a unique minimum is to use a Tikhonov regularization (3) whose unique solution is given by ( 4)

݉݅݊ ௌ ሺԡܯ -ܵܮԡ ଶ ଶ + ߣԡܵԡ ଶ ଶ ሻ (3) ܵ ఒ ሺݐሻ = ܣ ఒ ܯሺݐሻ with ܣ ఒ = ܮ ௧ ܮܮሺ ௧ + ߣܫሻ ିଵ (4)
The benefit of this method is that the matrix A can be computed offline; the reconstruction of the cortical activity S can then be obtained in real time through a single matrix multiplication.

Source localization by looks for the distribution of source activity with the smallest norm that best explains the measurements. One inconvenience of this method is that the measurement noise can be projected onto the cortical sources. The adjustment of the regularization parameter λ is intended to limit this effect.

Another drawback is that the L2 norm for the regularization tends to produce very smooth cortical activity. An L1 norm can give solutions with greater spatial accuracy;

unfortunately it can no longer be computed linearly, which is a problem as we are working in real-time.

In this paper we have tested a variant of the Minimum-Norm method called the weighted Minimum-Norm. A weighting matrix W, calculated from the lead field matrix L, is applied to the source distribution in the regularization term, so that the sources more distant from the electrodes are not penalized [START_REF] Lin | Assessing and improving the spatial accuracy in MEG source localization by depth-weighted minimum-norm estimates[END_REF]:

݉݅݊ ௌ ሺԡܯ -ܵܮԡ ଶ ଶ + ߣԡܹܵԡ ଶ ଶ ሻ (5)

2) Beamformer

The second method which we have tested for cortical activity reconstruction is the minimum-variance distortionfree beamformer originally developed in the field of array signal processing [START_REF] Capon | High-resolution frequency wavenumber spectrum analysis[END_REF]. This method constructs a spatial filter that extracts from the measured signals the activity coming from a specific position in the brain. It relies on the hypothesis that cortical sources that are spatially distinct are not correlated and that the noise is not correlated with the sources.

Like the Minimum-Norm, the Beamformer first requires to model and solve the forward problem to compute the lead field vector l(x 0 ) associated to the position x 0 in the cortex.

The signal M(t) is filtered with a spatial filter w(x 0 ) to recover the activity of the source at x 0 .

ݔሺݏ , ݐሻ = ݓ ௧ ሺݔ ሻ ܯሺݐሻ (6)

The weight vector w(x 0 ) is derived by minimizing ݓ ௧ ሺݔ ሻ ܥ ெ ݔሺݓ ሻ under the constraint ݈ ௧ ሺݔ ሻݓሺݔ ሻ = 1 which leads to:

ݔሺݓ ሻ = ಾ షభ ሺ௫ బ ሻ ሺ௫ బ ሻ ಾ షభ ሺ௫ బ ሻ (7)
where C M is the covariance matrix of the measurements and l(x 0 ) is the lead field vector corresponding to the position x 0 . The main difference with the Minimum-Norm method is that the Beamformer does not try to explain the whole signal by an activation of the sources, but tries to filter the signal to extract what originates from a specific position within the brain. The noise that is present in the measurements and that is not correlated with the sources (ambient noise, ocular and muscular activities...) is better filtered out than with the Minimum-Norm method and supposedly will not be projected on the sources.

The main drawback is that the fidelity of the cortical source reconstruction depends on the quality of the covariance matrix of the measurements. Several tens of minutes of recording can be necessary to obtain a good covariance matrix. The Beamformer can nevertheless be applied online, provided an imprecise covariance matrix is used at the beginning of the experiment.

D.Head model

The reconstruction of cortical activity is an inverse problem whose first step, as explained above, consists of modeling and solving a forward problem to compute the lead field matrix L.

We have used for each subject a three-layer head model composed of the scalp, the skull and the brain (around 600 points per interface). The source space was composed of around 600 sources with no fixed orientation (which is represented by 1800 dipoles with fixed orientation).

For subject one, a generic head model was used. For subject two, a specific head model was built from the subject's anatomical MRI with ASA 1 .

The lead field matrix L was computed with Open-MEEG using the Symmetric Boundary Element Method (BEM) [START_REF] Kybic | A common formalism for the integral formulations of the forward EEG Problem[END_REF].

E.Feature selection

There are two different approaches for feature selection: the filtering approach, which consists of eliminating the irrelevant features (or selecting the useful ones) before applying a classification algorithm, and the Wrapper approach, which on the contrary tests the classification on different subsets of features to determine the optimal one. The Wrapper approach can provide better feature selection [START_REF] Kohavi | Wrappers for feature subset selection[END_REF], at a higher computational cost. Due to the large amount of features, we have chosen the filtering approach and a recursive selection algorithm described in [START_REF] Fruitet | A Comparison of Regression Techniques for a Two-Dimensional Sensorimotor Rhythm-Based Brain Computer Interface[END_REF] that relies on Student's t-test [START_REF] Lin | Assessing and improving the spatial accuracy in MEG source localization by depth-weighted minimum-norm estimates[END_REF].

The first selected feature is the one with the highest t-test:

ܨሺݒሻ = |௩ ത భ ି௩ ത మ | ට భ శ మ (8)
where ݒҧ and d k are the mean and variance of the feature on the class k.

It is most likely that the features extracted from cortical sources close to the first selected feature will be similar. They will then have a very high t-test score but will not bring new information for the classification. Our objective is to select other features that may have lower t-test score but contain different information.

We define a scalar product on the space of the features (9) and use it to project the remaining features orthogonally to the first one selected [START_REF] Kybic | A common formalism for the integral formulations of the forward EEG Problem[END_REF].

ۧݒ|ݑۦ = ∑ ݑሺ݅ሻݒሺ݅ሻ ∈ா (9) ݒ = ݒ - ۦ௩|௩ * ۧ ԡ௩ * ԡ మ ݒ * (10)
where u(i) is the value of the feature u for the i th trial, E is the ensemble of all the trials and ݒ is the projection of v orthogonally to the first selected feature ݒ * .

The next feature selected is the one whose projection has the highest t-test score, the other features are projected orthogonally to this newly selected feature and the selection continues recursively.

As shown in figure 3, this feature selection algorithm leads to better classification and with fewer features than selecting directly the features having a high t-test. Although this procedure is designed to maximize the information yield out of a limited number of features, it also improves their discriminative power.

1 Advance Source Analysis software. ANT, Enschede, The Netherlands Fig. 3. Result on the training data set (dashed lines) and testing data set (full lines) as a function of the number of selected features. In black (no markers): the N features with the highest t-test score are selected. In red (square markers): results for the recursive feature selection algorithm. The recursive selection algorithm leads to better results with less features.

III.RESULTS

A.First subject: Results with a generic head model and six different tasks

The idea behind this experiment was to try different tasks to see which ones led to the best performances and whether recovering the cortical source activity could improve the results [START_REF] Le Pavec | Adaptive classification of mental states for asynchronous brain computer interfaces[END_REF]. The performances for all pairs of tasks were computed and the average for each method is given in table 1.

The results vary greatly depending on the tasks (not presented in the table). For example it is possible to differentiate "playing the bass guitar" from "moving the right index" with more than 80% accuracy. On the contrary it was not possible to discriminate "moving the left foot" from "moving the right one". The difficulty of separating between the two feet is due to the proximity of the right and left foot motor areas in the central region.

The only method that significantly increases the result is the Beamformer.

C. Localization of cortical sources

Figure 4 shows the localization of the most discriminative cortical sources for the Beamformer compared to the weighted Minimum-Norm and to the electrode data. The Beamformer method leads to slightly higher t-test scores but the discriminative sources are less focal. With the weighted Minimum-Norm method some discriminative sources appear on the left hemisphere, while only electrodes over the right motor cortex are discriminant. IV.DISCUSSION AND PERSPECTIVES Another type of method, called dipole fitting, is often used for source localization in EEG (MUSIC, RAP-MUSIC,... [START_REF] Baillet | Electromagnetic brain mapping[END_REF]). It consists of finding a small number of dipoles (1 to 10) that best explain the measurements. In our opinion, it is more appropriate for BCI to reconstruct a distributed activity (constituted of thousands of dipoles) and then select the few dipoles that maximize the discrimination between the different tasks.

For the first subject, source localization with Minimum-Norm did not lead to a significant improvement of the results, whereas for the second subject, for whom a specific head model was used, the best results were obtained with the weighted Minimum-Norm. A good inverse solution really relies on a good forward model, and so precise source localization needs a precise head model which is subject specific.

In the first experiment, which was difficult because some of the tasks were similar, the Beamformer method led to an increase of the classification accuracy. This supports the idea that source reconstruction can increase discrimination between tasks whose activities are closely located on the cortex. In the second experiment, the increase due to source reconstruction was maximal for the right hand/left hand discrimination, which was the most difficult one when using preprocessing only or Laplacian filtering.

Although the gain reported here from using cortical activity rather than Laplacian filtering is rather small, reconstruction of the cortical activity has other benefits for EEG classification that need to be explored. One of them is that its output, meaning the activation of the sources, is coherent with the physiology of the subject. This can be use to check if the results are valid but also to incorporate neurophysiological knowledge that can be useful for the classification.

An other point that needs to be studied is the impact of source reconstruction on the training of BCI users. It is likely that using cortical activity instead of electrode measurements will facilitate the user training and may lead to a level of control otherwise not possible.

When using source localization, the position of the electrodes over the scalp are measured and registered to the head model. If the electrodes are not set in the exact same position during different sessions, the forward model can be recomputed. An expected advantage of using cortical source activity rather than Laplacian filtering is session to session stability.

One of our objectives is to develop feature selection and classification methods that take into account the spatial coherence of the cortical sources from which the features are extracted. These algorithms could better exploit the advantages of source reconstruction.

  compare the results given by different methods to reconstruct cortical sources activity in order to classify EEG in real time. Two motor imagery experiments were performed. The aim was to retrieve from 1-second magery task the subjects were performing. The use of cortical activity reconstruction was compared to Laplacian filtering, which is often used in BCI. A test was used to select rmer method led to an improvement of the classification for the first experiment, which included six motor imagery tasks. The weighted Norm method required the use of a specific head model, extracted from the subject's MRI, to improve the ation. It then gave the best results on the second experiment, achieving a classification rate of 77% compared to 71% for direct use of electrode data and 75% for Laplacian Numerous studies over the last two decades show that scalp recorded electroencephalography activity (EEG) can muscular communication and control computer interfaces (BCI) 4]. One of the goals of these systems is to offer nication to people suffering relatively cheap, and has a very precise temporal resolution, which make it the most widely used recording method for human BCI.

Fig 1 .

 1 Fig 1. Time line of a trial, in seconds.

Fig. 2 .

 2 Fig. 2. The six motor imagery tasks proposed to the first subject: bass guitar, moving the right index, the right or the left hand and the right or the left foot. The goal of the analysis was to recover which task the user was performing by analyzing 1-second windows of EEG signal.

Fig. 4 .

 4 Fig. 4. Localization of the discriminant features with a t-test to differentiate right hand movement imagination from left hand for the second subject. Cortical source reconstruction with weighted Minimum-Norm (on the left) and Beamformer (on the right). The positions of the electrodes and associated t-test values are superimposed on both figures.

Table 1 .

 1 Results for the first subject with different cortical sources reconstructions. The values are the percentage of 1-second windows from which a mental task out of two could be determined.

	Method		Average result
	Preprocessing only		59.9%
	Spatial Laplacian		60.9%
	Weighted Minimum-Norm		60.7%
	Beamformer			62.0%
	B.Second subject: Results with a specific head model and
	three different tasks
	For the second subject only three tasks were proposed:
	right hand, left hand or both feet. The results are given in
	table 2 for each method.
	The best results are obtained with the weighted Minimum-
	Norm. This benefit is maximal when differentiating right
	hand from left hand imagery.
	method	right/left right/feet left/feet average
	Preprocesing only	68%	75%	71% 70,9%
	Spatial Laplacian	69%	81%	75% 75,1%
	Minimum-Norm	76%	82%	72% 76,6%
	Weighted Minimum-Norm	77%	81%	74% 77,2%
	Beamformer	75%	75%	74% 74,7%

Table 2 .

 2 Results for the second subject with different cortical source reconstruction methods. The values are the percentage of 1-second windows from which a mental task out of two could be determined. The mental tasks were motor imagery of the right hand, left hand or both feet.

ACKNOWLEDGMENT

We wish to thank Alexandre Gramfort for providing Matlab scripts for efficient Minimum Norm computation.


Chouki Tibermacine
email: tibermac@univ-ubs.fr

R Égis Fleurquin

Salah Sadou
email: sadou@univ-ubs.fr

Simplifying Transformation of Software Architecture Constraints *

Keywords: Design, Languages Architecture Constraint Languages, Constraint Transformation, OCL, Component-Based Software Development

The heterogeneity of architectural constraint languages makes difficult the transformation of architectural constraints throughout the development process. Indeed they have significantly different metamodels, which make the definition of mapping rules complex. In this paper, we present an approach that aims at simplifying transformations of architectural constraints. It is based on an architectural constraint language (ACL), which includes one core constraint expression language and different profiles. Each profile is defined upon a metamodel, which represents the architectural abstractions manipulated at each stage in the development process.

INTRODUCTION

Software architecture models define the global structure of a software. It is argued that these models should be associated with a documentation that explains the architectural decisions made (called Rationale in Perry's architectural model [START_REF] Perry | Foundations for the Study of Software Architecture[END_REF]). This documentation aims at better understanding the architecture of the system, and at controlling its future evolution [START_REF] Tibermacine | NFRs-Aware Architectural Evolution of Component-based Software[END_REF]. It is often defined using a formal constraint language. The constraints composing this documentation relate on the structural aspect of a model and stipulate that only certain architectures (i.e. models) are allowed (for instance, in an architectural model all components should have less than 10 provided interfaces). They have a different concern than traditional constraints, which serve as guards on instances of a model, like OCL invariants on a UML model. The latter constraints are of model-level, while architectural constraints are of metamodel-level. In general, architectural constraints define some architectural styles in order to meet non-functional requirements. We notice that only structural constraints are discussed in this paper, the behavioral aspect of software architecture will not be dealt with.

Let us consider the component-based software development (CBSD) process. In an MDE approach a software architecture model can be transformed into another architecture model (for instance a design-level model into an implementation-level one). It is important that we transform not only the software architecture model, but also its associated documentation (architectural constraints). This makes the documentation available and consistent throughout the different stages of the CBSD process. In addition, constraints can be checked not only when evolving the design-level model, but also when evolving the implementationlevel model [START_REF] Tibermacine | Preserving Architectural Choices throughout the Component-based Software Development Process[END_REF]. However, transformation of architectural constraints is complex due to the fact that constraint languages, used at different stages in the CBSD process, are based on metamodels which are completely different (see section 2). In this paper, we present an approach which aims at simplifying architectural constraint transformation. This approach introduces a bicephalous architectural constraint language, named ACL (section 3). It is based on OCL, as a core constraint language, and on a set of MOF architecture metamodels. We show how we can use this language to describe uniformly architectural constraints throughout the CBSD process in order to facilitate the description of transformation (section 4).

IDENTIFIED PROBLEM

Consider that at design-level, we describe a software architecture of a system using xAcme [START_REF]xAcme: Acme Extensions to xArch[END_REF], an XML representation of Acme Architecture Language [START_REF] Garlan | Acme: Architectural Description of Component-Based Systems[END_REF]. The corresponding architectural constraints are specified using the constraint language of this ADL, namely Armani [START_REF] Monroe | Capturing Software Architecture Design Expertise with Armani[END_REF]. For example, let us suppose a simple architectural constraint that ensures in a given architecture model the existence of less than 5 provided (in) interfaces for all subcomponents of a specific component. This constraint is the translation of a rule stating that the quality measure CBM 1 (Coupling Between Mod- Suppose that we want to transform this architecture model, which conforms to the xAcme metamodel, into a model which conforms to another metamodel. There are two possible cases: i) the targeted technology does not provide a constraint language (CORBA Component Metamodel [START_REF]Object Management Group: CORBA Components, v3.0, Adopted Specification[END_REF], for example 2 ); ii) the target technology provide a constraint language (for example the WRIGHT language [START_REF] Abowd | Formalizing Style to Understand Descriptions of Software Architecture[END_REF]).

In the first case, a new language should be provided in order to maintain the architectural decisions throughout the CBSD process. This language should be designed in a way to minimize the transformation cost. In the second, metamodels of constraint languages at different stages of the CBSD process are often different. This is logically due to the distinct nature of concerns at each stage of the development process. Because constraint languages include in their grammars the architectural abstractions to be constrained (for example, Component and Ports, which are keywords of Armani language), the definition of transformation rules between languages at different stages is made complex. But even at the same stage constraint languages can be significantly different. For example, consider the same constraint written using WRIGHT constraint language:

∀c : Components; p : P ort| p ∈ P orts(c) • T ype(p) = DataInput ∧ #P orts(c) < 5
It is clear that although the two languages have several similar architectural concepts, they differ in the predicate language they use. Transformation of architecture constraints Objects) [START_REF] Chidamber | Towards a Metrics Suite for Object-Oriented Design[END_REF], which is used for object-oriented applications. 2 In the best of our knowledge, there is no implementationlevel architectural constraint language. is more difficult than architecture model transformation because we have not only to deal with architectural concepts mapping 3 (as in architecture models transformation) but also with predicate language mappings. Consequently, we propose an approach based on a family of architecural constraint languages, which facilitates the transformation of architectural constraint.

ACL AS A CONSTRAINT LANGUAGE

To resolve the problem mentioned above, we propose a new architectural constraint language, named ACL. This language is structured on two levels: the first level takes the form of a predicate language, and the second represents the manipulated architectural concepts.

The predicate language chosen is OCL [START_REF]Object Management Group: UML 2.0 OCL Final Adopted Specification[END_REF]. We slightly modified it to achieve our goals. This part of ACL has been called, the Core Constraint Language (CCL). The second level is represented by a set of MOF-compliant metamodels. Each metamodel defines the architectural abstractions manipulated at a given stage and the relationships between these abstractions. At each stage in the development process a couple composed of CCL and a metamodel, called an ACL profile, can be used. For example, we defined an ACL profile for xAcme, UML 2 and CCM.

In the following subsections, first we present CCL and its differences with OCL. Next, we introduce ACL profiles. At last, we illustrate the example specified previously in Armani, in the ACL profile for xAcme.

Core Constraint Language

Like OCL, CCL is a FOL 4 -based language. It supports set and graph operations, and provides capabilities for specifying navigations in structures. In addition and at the difference of OCL, CCL is characterized by:

• Context declarations with mandatory identifiers. These 3 In this parer, the word mapping is used to stipulate a relationship between two entities. 4 First-Order Logic • Only invariants can be specified using ACL. Pre-or post-conditions are not supported because not necessary.

• Additional operations and marks have been introduced in order to facilitate the description of certain types of constraints. For example, in order to describe constraints comparing different versions, we have introduced the @old mark.

• Constraints navigate on the metamodel, but are evaluated on a specific instance specified in the context.

To better understand the first and last items, it is necessary to go back over the usual mode of expression of OCL constraints in a class diagram. In this type of diagrams, OCL is generally used to specify class invariants, pre/post conditions of operations, constraints on cycles between associations, etc. These constraints restrict the number of the valid object diagrams instanciable from a class diagram. They mitigate the lack of expressivity of the UML graphical notation which, employed alone, can authorize in certain cases the instanciation of object diagrams incompatible with reality that we wish to model. In both cases, the context is a class (MTProceedingsPaper). The two constraints concern any instance of the context (here, an object instance of the class MTProceedingsPaper). It is the approach adopted for every OCL constraint. The first constraint references this instance using the keyword self, while the second one introduces an ad-hoc identifier paper. These two modes for referencing instances allowed by OCL are semantically equivalent. Every OCL constraint is made up of elements present either in the OCL language (->, size(), etc), or in the class diagram reachable from the context (the attribute size and the association-end writtenBy).

It is interesting to consider what might be the meaning of OCL constraints written not on a model, but on a metamodel. A metamodel exposes the concepts of a language and the links between them. It describes an abstract grammar. Thus, a constraint having for context a metaclass limits the expression power of the grammar's production rules and thus the number of the derived phrases (i.e. models). Certain phrase structures are dismissed. If this metamodel describes the abstract grammar of a language dedicated to architecture description, a constraint expresses, then, that only certain architectures (i.e. models) are derivable (i.e. can be instanciated) in this language. The language is restricted voluntarily in its expressiveness because we do not allow the description of certain types of architectures. For example, we can impose that every component in the model must have less than 10 required interfaces, by putting this constraint in the context of the metaclass Component. This constraint is exactly of the type we wish to express. Unfortunately it has a global scope. It applies to all components and not to a particular one, as we would wish it to be. To limit the scope of such a constraint to a particular component, we propose to slightly modify the syntax and semantics of the context part in OCL. At the syntactic level, we impose that every context introduces an identifier. Furthermore, this identifier must be the name of a particular instance of the metaclass cited in the context. At the semantic level, we interpret the constraint with the meaning it would have in the context of the metaclass but by limiting its scope to the instance cited in the context. Illustrative examples are presented in the next subsection.

ACL profiles

As mentioned previously, ACL has several profiles. Each profile has two levels of expressiveness. The first level is defined by CCL and the second by a specific MOF metamodel. Each metamodel represents architectural abstractions present in a given Architecture Description Language (ADL) or a component technology, and relationships be- tween these abstractions. Each profile can be used, at a given stage in the CBSD process with the corresponding developer's language or technology to describe architectural decisions.

¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¢ ¡¢
Among the ACL profiles, we present here the profile for xAcme ADL. As stated previously, this ACL profile is composed of CCL and the xAcme metamodel. Note that in our approach, only the structural aspect is represented in the metamodels. That is why we illustrate in figure 1 an xArch metamodel, which contains only the primitive structural elements that compose an xAcme architecture description 5 . An xAcme architecture instance is composed of a set of component instances, connector instances, link instances and logical groups of the previous architectural elements. Component or connector instances define a set of interface instances and optionally a subarchitecture for a hierarchical description. The subarchitecture defines a set of architecture instances and a list of mappings between inner and outer interface instances. Link instances bind two end points, each one references an interface instance.

The constraint presented in the previous section can be specified using xAcme profile as following: context ACS:ComponentInstance inv: ACS.subArchitecture.archInstance.componentInstance .interfaceInstance->select(i:InterfaceInstance| i.direction = 'in')->size() < 5

PROFILE TRANSFORMATIONS

Let us consider that we transform the xAcme architecture model, to which is associated the previous constraint, into a component description in CCM. Following the proposed approach, the constraint will be transformed to the ACL profile for CCM. As for the other ACL profiles, the CCM one is composed of CCL and the CCM metamodel (see figure 2). The constraint above becomes as follows:

context ACS:ComponentAssembly inv: ACS.connection.port.component.port .interface->select(i:Interface| i.kind ='Provided')->size() < 5

Having CCL in common, the two previous constraints have the same structure and basic predicate constructs with the same semantics (like, context, inv, select() or size(). However it navigates in different metamodels.

When transforming xAcme profile to the CCM one, only the part of the constraint related to the architectural aspect needs to be transformed. This is illustrated by the right side of figure 3. Now that we identified clearly the different parts between the constraints written in the two profiles, the transformation problem can be restricted to translation of the architectural part. In order to resolve this problem, we can use transformation languages, like MTL [START_REF] Consultancy | Revised submission for MOF 2.0 Query / Views / Transformations RFP[END_REF] or TRL [START_REF] Alcatel | Response to the MOF 2.0 Query/Views/Transformations RFP (ad/2002-04-10)[END_REF]. For example, in order to perform the transformation of the constraint defined with the xAcme profile into the CCM profile, we need to have the following mappings: This information can be derived from possible existing mappings between metamodels. These mappings are supposed to have been used in transforming models and not specially defined for constraint transformation. For example, the first mapping can be deduced from the MTL relation below.

Relation ComponentInstance2ComponentAssembly{ domain { (ComponentInstance)

[id = i, subArchitecture = s] when s->notEmpty()

} domain { (ComponentAssembly) [id = i,connection = (Connection) [port ={(Port)[// ... ]}] ] } }
We have not detailed here all transformations, because of the size of the two metamodels and the paper's page limitations. However, what we showed through this example is that once a constraint transformation is restricted to equivalences between elements of two different metamodels, it exists several means to elaborate a solution.

RELATED WORK

In the literature, it exists several works on software architecture transformation [START_REF] Carrière | Rick: Software Architectural Transformation[END_REF][START_REF] Fahmy | Software Architecture Transformations[END_REF], whose focus was on architecture refactoring. In these works, transformation of architectural constraints has not been dealt with. In [START_REF] Giese | Simplifying Transformations of OCL Constraints[END_REF], the proposed approach consists in transforming OCL constraints in order to remove redundancies and simplify them. We think that their approach is complementary to ours. It can be used once the constraints are generated in the target ACL profile, in order to simplify them.

CONCLUSION AND FUTURE WORK

In this paper, we proposed a bicephalous architectural constraint language, which clearly separates the invariable part from the variable one in order to simplify constraint transformations. Thus, in an architectural constraint expression we isolated the part that concerns architectural aspect in order to perform the transformation only on this part.

We think that the proposed approach promotes the reuse of mappings between metamodels established for architectural model transformation. Indeed it becomes possible to transform architectural constraints at the same time we transform the concerned models.

Our objective in the short run is to define MTL relations between xAcme, UML 2 and CCM metamodels. Then, we apply our architectural constraint transformation approach between different couples of metamodels. This will validates the proposed approach.

Figure 2 :

 2 Figure 2: A CCM structural metamodel

  OCL constraints are described relative to a context. This context is an element of the class diagram, generally a class, an operation or an association present on this diagram. The following are two examples of OCL constraints. context MTProceedingsPaper inv: self.size <= 8 context paper:MTProceedingsPaper inv: paper.writtenBy->size() >= 1

Figure 3 :

 3 Figure 3: Shifting from whole to partial transformations

1

  CBM metric is the equivalent of CBO (Coupling Between

	XArch
			+archInstance		ArchInstance
					+id[1]: Identifier
				1	+description[1]: Description
						1	+ownedArchInstance
	*	+componentInstance	*	+connectorInstance	*	+linkInstance	*	+group
	ComponentInstance	ConnectorInstance		LinkInstance	Group
	+id[1]: Identifier	+id[1]: Identifier			+id[1]: Identifier	+id[1]: Identifer
	+description[1]: Description	+description[1]: Description	+description[1]: Description	+description[1]: Description
									+member[*]: ArchInstance
	*	+interfaceInstance	0..1	+subArchitecture	2	+endPoint
	InterfaceInstance	SubArchitecture		Point	Direction
	+id[1]: Identifier +description[1]: Description	1		1	+anchorOnInterface[1]: InterfaceInstance	+none +in
	+direction[1]: Direction							+out
							InterfaceInstanceMapping	+inout
			* +interfaceInstanceMapping	+outerInterfaceInstance[1]: InterfaceInstance +innerInterfaceInstance[1]: InterfaceInstance
			Figure 1: The xArch metamodel
	ules) should be less than 5 [8]. This constraint helps to
	guarantee the maintainability of the architecture and can
	be formalized as following:
	invariant forall com:Component in self.Components|
	forall p:Port in com.Ports
	size(select p:Port in com.Ports |
	satisfiesType(p,inputT)) < 5

  ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢ ¡¢

		Object
		Constraint
		Language				ACL Profile
						for UML 2
		UML 2+OCL				UML 2	Metamodel
		Metamodel
						Core
						Constraint
	Armani Constraint Language	Armani Metamodel Metamodel CCM	CCM Constraint Language	ACL Profile for Acme	A c m e M e ta m o d e l	Language	M e ta m o d e l C C M	ACL Profile for CCM
		Whole Transformations			Partial Transformations

More details about xArch can be found in http://www.isr.uci.edu/architecture/xarch/

* This work is supported partially by the Brittany Region Council under contract number 20046839.

.


Chouki Tibermacine
email: tibermac@univ-ubs.fr

R Égis Fleurquin

Salah Sadou
email: sadou@univ-ubs.fr

NFRs-Aware Architectural Evolution of Component-Based Software *

During software maintenance, some non-functional properties may be lost. This is due to the lack of an explicit definition of their links with the corresponding architectural choices. In this paper, we present a solution that automates the checking of non-functional properties after the evolution of a component-based software. Our approach emphasizes the interest of formally documenting the links binding nonfunctional requirements to architectural choices. The proposed formalism is based on the Object Constraint Language (OCL) applied to a software component metamodel. We also present a prototype tool which uses this documentation to warn the developer of possible effects of an architectural change on non-functional requirements.

INTRODUCTION

Among the maintenance activities, regression testing is one of the most expensive. When problems are found during this activity, corrections on the software architecture are required. This involves a sequence of iterations of these maintenance activities, which increases undoubtedly its cost more and more. Often, the problems are caused by the lack of knowledge, during maintenance, of the reasons which had led, the initial architects, to make some architectural choices. Indeed, without this knowledge, it is easy to lose some properties by a simple change on a specific architectural choice.

In this paper, we present an approach which helps reduce the number of the necessary iterations, in the context of component-based software. It consists of warning the software developer of the possible loss of certain non-functional properties during an evolution, well before starting regression tests. Under the assumption that the architecture of an application is determined by the non-functional require- * This material is based upon work supported by the Brittany Region Council under contract number 20046839.

. ments (NFRs) [START_REF] Bass | Software Architecture in Practice[END_REF] -mainly the quality attributes, such as, maintainability, portability, availability-, we propose to formally document the links binding non-functional properties to their realizing architectural choices. Thus, we automate the checking of these non-functional properties after an architectural change has been made.

In the next section, we present the principles of our approach which resolves the problem pointed above. In section 3, we present an implementation of our approach, which is based on a constraint language and an association mechanism. Before concluding and presenting the perspectives, we discuss some related works in section 4.

PRINCIPLES OF OUR APPROACH

Our approach aims at solving the problems mentionned in the previous section, by expliciting, in a formal way, the reasons behind the architectural choices. Based on the assumption that architectural choices are determined by nonfunctional requirements, we propose to maintain the knowledge of the links binding non-functional properties to architectural choices. Thus, it becomes possible to automatically warn the developer, at each architectural evolution stage, of the potential deterioration of some non-functional properties.

In the remaining of this paper, we use the following definitions:

Non-Functional Property (NFP): a statement of the software non-functional specification;

Architectural Choice (AC): a part of the software architecture that targets one or several NFPs;

Non-Functional Tactic (NFT): a couple composed of an AC and an NFP defining the link binding one architectural choice to one non-functional property;

Non-Functional Strategy (NFS): a set of all the NFTs defined for a software;

The NFS is elaborated during the development of the first version of the architecture. NFTs appear in each development stage where a motivated AC is made. Thus, the NFS is built gradually and enriched as the project evolves. NFTs can even be inherited from a Software Quality Plan and, thus, can emerge even before the beginning of the software development. During the maintenance, the NFS may be modified along the following three rules:

P/AC1 P/AC1 Q/AC3 P/AC1 Q/AC3 R/AC4 P/AC1 Q/AC3 R/AC4 PQ/AC2 P/AC1 Q/AC3 R/AC4 PQ/AC2 PR/AC5
Step 0

Step 1

Step 2

Step 3

Step 4

Step 5

P Q R P Q R AC1 AC2 AC2 AC3 AC4 AC2 AC4 AC3 AC2 P Q R P Q R P Q R P Q R AC2
Figure 1: Assisting the evolution activity with NFS specifications

• Rule 1: "a consistent system is a system where all its NFPs are involved in at least one NFT ". This condition ensures that, at the end of the maintenance process, there is no dangling NFP (i.e. with no associated AC). The breach of this condition implies de facto the obligation to modify the non-functional specification;

• Rule 2: "we should not prohibit an evolution stage.

We simply notify the attempt of breaking an AC and we specify the affected NFPs stated in the NFS ". It is of the developer's responsibility, fully aware of the consequences, to maintain or not the modification. If this modification is maintained, the corresponding NFTs are discarded. Indeed, The substitution of an architectural choice by another may be done without affecting the targeted non-functional properties. Moreover, we can be brought to invalidate, temporarily, a choice to perform a specific modification;

• Rule 3: "we can add new NFTs to the NFS ". Thus, during an evolution, new architectural choices can complete, improve or replace old ones.

On the basis of these rules, we illustrate a maintenance scenario in figure 1. Let us suppose that in step 0 of a maintenance process, there are three NFPs: P, Q and R. During development, each one has been associated to a number of ACs. Choices AC1 and AC2 guarantee the property P; AC2 and AC3 target the property Q; and R is achieved by AC4. Thus, the NFS is composed of five NFTs. These are shown in the table at the top left of figure 1. In the first step, the maintainer of the system modifies the architecture. The result does not anymore hold the choice AC1. In this case, the maintainer is notified that the property P could be affected. He decides to continue his activity, aware of what he is doing and what the consequences are. The NFS is considered valid (the table on the bottom of the figure), while the first rule is satisfied (there is still a choice (AC2) associated to the property P). In step 2, the choice AC3 associated to the property Q is affected. After notification, the developer does not maintain his decision this time, and undoes the changes made on the architecture. Thus, choice AC3 is still present in the architecture. Later (in step 3), he modifies the system and affects choice AC4. He is warned that the property R will not hold anymore, because only AC4 guarantees it. Nevertheless, he decides to carry on. But this time, the NFS becomes invalid because there is a dangling property (R) with no associated choices. In step 4, the maintainer does the same with AC2. For one reason or another, he decides to continue and the NFS specification remains invalid. This time, it contains also another property (P) with no associated architectural choices. In step 5, rule 1 is satisfied again by adding a new AC (AC5) which guarantees the properties P and R. The NFS becomes valid since there is, at least, one architectural choice associated to each initial property.

We have shown through this scenario that our approach helps to obtain an architecture satisfying the initial nonfunctional requirements.

NFS IMPLEMENTATION

As stated previously, our approach requires the use of a formal language to describe an AC [START_REF] Tibermacine | Preserving Architectural Choices throughout the Component-based Software Development Process[END_REF], an association mecanism to express an NFT, and a support tool for NFS evaluation.

AC Description Language

In this implementation, an AC is perceived as an architectural constraint. It is difficult to enumerate all types of constraints which the developers could be led to express. Nevertheless, it is obvious that constraints of the following kinds should be expressible: i) general rules of an organization's Software Quality Manual and Quality Plan; ii) constraints for respecting a particular architectural or design pattern.

These different types of constraints are seen as invariants and purely atemporal. From a temporal perspective, another type of constraints should be expressible. These rules have a temporal dimension and thus involve two consecutive versions of the architecture. For example, "we cannot add more than one provided interface to a component from one version to another". This type of constraints can be found in the general evolution rules of an organization, as stated in [START_REF] Van Ommering | The Koala Component Model for Consumer Electronics Software[END_REF].

We chose a two-level solution to manage this diversity. The first level is based on OCL. Usually, OCL is used to constrain a model by navigating on it, whereas, we use it to constrain a model by navigating on a metamodel. We propose to slightly modify the syntax and semantics of the context part in OCL. At the syntactic level, we impose that every context introduces an identifier. Furthermore, this identifier must be the name of a particular instance of the metaclass cited in the context. At the semantic level, we interpret the constraint with the meaning it would have in the context of the metaclass but limiting its scope only to the instance cited in the context.

The second level takes the form of a generic MOF-compliant metamodel ArchMM (see figure 2). It contains abstractions present in analysis/design models, such as those provided by Architecture Description Languages (ADLs, like Acme [START_REF] Garlan | Acme: Architectural Description of Component-Based Systems[END_REF] and xADL 2.0 [START_REF] Dashofy | A comprehensive approach for the development of modular software architecture description languages[END_REF]) or UML 2, and implementation models, such as those provided by component technologies, like Enterprise JavaBeans and CORBA components. This metamodel enables us to adapt OCL, without making major changes on its syntax, to express constraints on architectures of component-based systems. This second level also allows, by a simple enrichment of the metamodel, to extend the list of the available operators without changing the syntax of the first-level language (i.e. OCL syntax). This two-level structure, called ACL -Architecture Constraint Language-, guarantees the extensibility of our formalism's expressiveness 1 .

Let us consider a constraint which states that only one provided interface can be added to a primitive component, named DataRetrievalService, between two consecutive versions [START_REF] Van Ommering | The Koala Component Model for Consumer Electronics Software[END_REF]. This is a typical evolution constraint because it involves two consecutive versions of the system. It fulfills the non-functional requirement stating that each component version should be evolved safely. It can be expressed as follows:

context DataRetrievalService:PrimitiveComponent inv: DataRetrievalService.port.interface ->select(i:Interface|i.kind = 'Provided')@old ->comparedTo(DataRetrievalService.port.interface ->select(i:Interface|i.kind = 'Provided')) ->size() <= 1 Note that we have introduced a new syntactic construct to ACL so that we can reference old versions of architecture descriptions: the @old mark. The @old returns the descriptions of the former version of an architecture. In this example, it returns a collection of the provided interfaces descriptions of the DataRetrievalService component version before evolution. Note that we have also added a collection operation: comparedTo(c2:collection(T)):Collection(T). It returns a collection which represents the difference between the collection to which it is applied and the parameter collection (c2). We introduced this new operation in order to not affect OCL semantics of the set difference operator (-). Indeed, traditionally in OCL, the set difference operator compares references of object collections, whereas 1 More details about ArchMM and ACL can be found in [START_REF] Tibermacine | Preserving Architectural Choices throughout the Component-based Software Development Process[END_REF] comparedTo(...) uses the value of the id attribute. In our situation, we are confronted to a comparison of collections of architecture descriptions. The elements of these collections are objects which have different references from one version to another, but the same value of the id attribute.

Association Mecanism

An association mechanism allows the binding of an architectural constraint (AC) described with ACL to a list of NFPs. Thus it merges several NFTs, sharing the same AC, in one structure. The mechanism we propose follows a structure inspired by the ISO 9126 quality standard [START_REF]Software Engineering -Product quality -Part 1: Quality model[END_REF]. A binding associates an AC to an external quality characteristic with its comment extracted from the specification document. These characteristics are organized in the form of a forest, which counts 6 trees. The roots of these trees are, at the moment, the 6 higher-level external characteristics stated by the standard: maintainability, portability, reliability, efficiency, functionality and usability. The second level of each tree contains the external sub-characteristics detailed by the standard. Concretely, an NFS specification starts by announcing the different NFPs associated to an AC; then the AC is described. It is illustrated in the form of the following XML structure: <nfs id="000005"> <nft id="000193"> <nfp id="001043" characteristic="Portability"> The software system should be portable over different environments. It can serve different applications for museum supervision or access control data administration </nfp> <ac id="010116" name="FacadePattern"> <!--Here we edit the ACL constraint--> </ac> </nft> </nfs> Each nfp element has an attribute that specifies the external characteristic which represents the NFP. The property, as stated in the non-functional specification, is then introduced in this XML element. Each NFS specification is associated to the architecture description to which it applies.

Support Tool

We developed a prototype tool, which allows the edition, the validation and the evaluation of NFS specifications, and the assistance of a software developer during an evolution operation. It is composed of an:

• NFS Editor: It uses the XMI format of the metamodel (ArchMM), to guide the developer in editing its architectural constraints (ACs) and their binds to NFPs.

• NFS Validator: This module validates the NFS of the initial version of the component by checking all its ACs. Then, it produces an archive file composed of the architecture description file and the NFS specification file.

• Evolution Assistant: During an evolution, the new version of the component's architecture is proposed to the tool. It evaluates the NFS using the old and the new architectural descriptions. If the NFS is valid, the new architecture description may be associated to the NFS specification and then it may be saved; else the architecture evolver is warned that some ACs may be altered and consequently that the associated NFPs may be affected.

The presented prototype takes into account only architecture descriptors defined in the Fractal model or xAcme ADL, but, was conceived to easily support other ADLs or component models.

RELATED WORK

In the literature, non-functional properties has been supported on the software development through two approaches. The first one is process-oriented, while the second is productcentric. In the first approach, methods for software development driven by NFRs are proposed. They support NFRs refinement to obtain a software product which is compliant with the initial NFRs [START_REF] Mylopoulos | Representing and Using Nonfunctional Requirements: A Process-Oriented Approach[END_REF]. In the second approach, the non-functional information is embedded within the software product. This is also the case in our approach, where NFS specifications are associated to architectural descriptions. Using the same approach, Franch and Botella [START_REF] Franch | Supporting Software Maintenance with Non-Functional Information[END_REF] propose to formalize non-functional requirement specifications. These are encapsulated in modules, which are associated to a component definition and to its implementations. They also propose an algorithm, which allows the selection of the best implementation for a given component definition. This selection method can be used when a new implementation is proposed to ensure that the best one is used. The authors mean by "best" the implementation that better fits to its non-functional requirements. Compared to our work, components are seen differently. We focus on an architectural aspect of components, while they consider the abstract data type view of components. In addition, in our case, the maintenance is performed on architectural descriptions while changes in their approach are at an implementation level. Furthermore, in our work we deal at the moment only with static quality attributes, like maintainability. In their work, dynamic quality attributes (like, performance and reliability) are taken into account.

CONCLUSION AND FUTURE WORK

Perry and Wolf [START_REF] Perry | Foundations for the Study of Software Architecture[END_REF] modeled software architectures as a set of Elements, Form and Rationale. Elements are architectural entities responsible for processing and storing data or encapsulating interactions. Form consists of properties

Figure 2 :

 2 Figure 2: ArchMM: A generic metamodel representing architectural abstractions

-constraints on the choice of elements, and relationshipsconstraints on the topology of the elements. The rationale captures the motivation for the choice of an architectural style, the choice of elements and the form. While the description of the two first aspects have received a lot of attention by the software architecture community[START_REF] Medvidovic | A Classification and Comparison Framework for Software Architecture Description Languages[END_REF], there has been a little effort devoted to the last aspect. In this paper, we presented NFS specifications, as a contribution to the description of the last element in Perry's model. This allows us to assist the architectural maintenance activity and, thus, prevent the loss of non-functional properties. In addition, it is, as we think best, a good practice for documenting software architectures and, thus, facilitating software comprehension in maintenance activities.On the conceptual level, we plan: i) to associate metrics to the NFPs. This makes for a better assistance in the maintenance activity; ii) the definition of a library of architectural styles and design patterns, in order to facilitate the description of architectural constraints. On the tool level, we are working on its extension to support architectures described in UML 2 and in CORBA Component Model;For more information about the project, on which depends this work, the reader is invited to follow the link: http://www-valoria.univ-ubs.fr/Composants/se/current/Cell