Chouki Tibermacine
email: chouki.tibermacine@univ-ubs.fr

Régis Fleurquin
email: regis.fleurquin@univ-ubs.fr

Salah Sadou
email: salah.sadou@univ-ubs.fr

Preserving Architectural Choices throughout the Component-based Software Development Process

Keywords:

It is argued that architecture comprehension and regression testing of a software system are the most expensive maintenance activities. This is mainly due to the fact that architectural choices are either not explicit, at every stage of the software development process, or not preserved from one stage to another. In this paper, we present an Architectural Constraint Language (ACL) as a means to formally describe architectural choices at all the stages. This language is based on the UML's Object Constraint Language and on a set of MOF-compliant metamodels. We also present a prototype which validates the proposed approach. It allows the evaluation of ACL expressions at two stages and ensures, by using a transformation mechanism, that the constraints stated at one stage are subsequently preserved.

Controller

Introduction

Software architectures need to be well documented, so that maintenance activities could be performed easily and safely. Indeed, among the maintenance activities, understanding the software architecture before its evolution, and regression testing after it has evolved, are by far the most expensive. By making explicit and formal all architectural choices, we facilitate on the one hand, the program comprehension and on the other, the automatic regression testing. These architectural choices are often expressed using a constraint language. Many existing Architecture Description Languages (ADLs) provide such languages [START_REF] Medvidovic | A classification and comparison framework for software architecture description languages[END_REF]. However, in the following stages of the software development process, there is often no mean neither to express the new choices nor to preserve those expressed previously. For instance, in component-based software, none of the existing implementation models, e.g. SUN's Enterprise JavaBeans (EJB) [START_REF]Enterprise JavaBeans(TM) specification, version 2.1[END_REF], OMG's CORBA Component Model (CCM) [START_REF] Omg | Corba components, v3.0, adpoted specification, doc[END_REF] or Mi-crosoft Component Object Model (COM+) [START_REF]COM: Component object model technologies[END_REF], provide such features. The architectural choices are thus often embedded into code and then become implicit at this level. Consequently, if an evolution is made on this level, the architectural choices may be affected (see section 2 for a detailed example).

To resolve this problem, architectural choices made at each stage of the software development process should, not only be explicit but they should be preserved in the following stages as well. In this paper, we present an Architecture Constraint Language (ACL). This predicate language serves to formally document component-based software architectures throughout the different stages of the development process (see section 3). ACL is based on the UML's Object Constraint Language (OCL), associated to several MOFcompliant metamodels. Each metamodel meets the needs of one stage of the software development. The software designer can thus continue to use concepts from his favourite (usual) ADL or component technology. To preserve the architectural choices, from one stage to the others, we use a generic metamodel (ArchMM). This pivot metamodel is the basis of a constraint transformation mechanism. ACL expressions are interpreted by an Architectural Constraint Evaluator (ACE). This tool, presented in section 4, makes possible to evaluate the compliance of the implementation models with the constraints stated during the component design stage.

Illustrative Example

Let us consider a simple example of an Access Control System (ACS). The different parts of figure 1 provide an overview of its architecture. This architecture is mainly organized as a pipeline [START_REF] Shaw | Software Architecture: Perspectives on an Emerging Discipline[END_REF]. The system receives as input the necessary data for user authentication (Authenticator component). After identification, the data is sent to the Access-Controller component. The latter checks whether the user is authorized to enter to the controlled area or not. If the access is authorized, the Logger component adds to the data the entrance date and hour, and stores it locally for the controlled area. Then, it sends these logs to the Transmitter component, which adds information about the controlled area and transmits them for global archival storage.

To illustrate our purpose, we briefly describe the development process of ACS, from architectural design to implementation. Then, we describe the raised problems.

Architectural Design Stage

The architecture designer of this system chooses the pipeline style aiming at a high level of maintainability of the software. Suppose that the architecture of this system was described using xAcme [START_REF]xAcme: Acme Extensions to xArch[END_REF]. Using graph theory, we enumerate the structural constraints that guarantee this architectural style. These constraints are defined using the Armani predicate language [START_REF] Monroe | Capturing software architecture design expertise with Armani[END_REF] as follows 1 :

1. The first constraint implies the definition of vertices and arcs, and that each arc must be connected to two vertices:

(a) A vertex stands for a component with input or output ports:

i n v a r i a n t f o r a l l comp : Component i n s e l f . Components | f o r a l l p : P o r t i n comp . P o r t s | s a t i s f i e s T y p e ( p , i n p u t T ) o r s a t i s f i e s T y p e ( p , o u t p u t T ) (b) An arc represents a connector with exactly two roles (one sink and one source):

1 Concretely in xAcme constraint descriptions are decomposed in many XML elements. For the sake of brevity, we present the constraints as they are described traditionally in the Armani Language. 2. The second constraint implies two sub-constraints:

(a) The graph should be connected:

i n v a r i a n t f o r a l l c1 , c2 : Component i n s e l f . Components | c1 ! = c2 -> r e a c h a b l e ( c1 , c2 ) (b
) And, it contains n-1 arcs (connectors), n being the number of vertices (components):

i n v a r i a n t s i z e ( s e l f . C o n n e c t o r s ) = = s i z e ( s e l f . Components )-1

3. The last constraint stipulates that the tree must be a list. It may be expressed as following: The constraints, described above, guarantee the structural compliance with the pipeline style at this stage. During the following stages, we should also be able to check whether this style is still respected.

Component Design Stage

Before implementing ACS, using CORBA components, we decided to establish an intermediate UML model for a smooth transition2 . In this case, the constraint specification CS1 should be transformed into CS1' (see figure 1). Additional constraints specific to this UML diagram may be added (CSS2, in figure 1). For example, to meet a maintainability requirement, we may specify in CSS2 that the ACS component should provide no more than two interfaces. At this stage, the overall constraint specification (noted CS2 in the figure) consists of CS1' union CSS2. Unfortunately, neither the CSS2 constraint nor those expressed at the previous stage (CS1') can be specified and checked using the UML language. This is due to the fact that its predicate language (OCL) cannot express this type of constraints, which imply restrictions on UML meta-classes, such as Component or Interface. Consequently, there is no means: i) to guarantee that CS1' is respected and ii) to document CSS2, in order to be explicit and checkable.

Component Implementation Stage

At this stage, we should also be able to transform CS2 into CS2' and possibly add other constraints (CSS3). CS2' represents here the mapping of the CS2 constraints into the CORBA Component Model. The overall constraint specification (noted CS3 in the figure) consists of CS2' union CSS3. As in the previous stage, there is no constraint language in this technology which allows the definition of CSS3. In addition, there is no means to transform CS2 into CS2'.

An Evolution Scenario

Let us suppose the following evolution scenario: To gain performance in the application processing, we decide to send directly some data, which are not useful for local logging, to the central server.

One solution to meet the requirement above is to add a direct connection between the components AccessController and Transmitter. Unfortunately, this change breaks the pipeline structure of the system architecture and consequently weakens its level of maintainability. If this change is made on the architecture design, the system maintainer is notified of the consequences, because the pipeline style was formally described (CS1 specification) and thus checkable. However, if it is made on the UML diagrams, or on implementation models, which is often the case, there is no mean to notify the system maintainer.

The next section introduces ACL, a constraint language which allows the specification of structural constraints at each stage of a component-based software development process (CS1, CSS2 and CSS3 in the previous example). In addition to the specification of architectural constraints, ACL associated to its interpreter (ACE) allows a transformation process of constraints from one stage to another (in the example above, transform CS1 into CS1' and CS2 into CS2'). This implies the persistence of architectural choices.

Architectural Constraint Language

Because many aspects of a software might be of interest, we can use various modeling languages to highlight one or more particular perspectives or views of that system depending on what is relevant at every point of the development process. A language is used during such or such stage of the process for its effectiveness at solving the problems arising at this particular stage. Each language uses concepts defined in its metamodel. Because two languages can be based on different concepts, it is frequent to have to manage many concepts during the software development process.

In order to propose a constraint language usable at all the stages of the software development process and to support this diversity, we chose a two-level solution. The first level is based on a constraint language, easy to grasp and standardized by the OMG, namely OCL [START_REF] Omg | UML 2.0 OCL final adopted specification, document ptc/03-10-14. Object Management Group Web Site[END_REF]. The second level takes the form of a set of metamodels. Each metamodel enables us to adapt ACL, without making changes on its grammatical part, to express predicates on models written in a specific language. For instance, we propose a metamodel for xAcme architecture descriptions, UML 2 component models or CCM component descriptions. To specify a constraint on an xAcme model, we write an OCL statement in the context of the proposed xAcme metamodel (see figure 2). This two-level structure guarantees that at each stage of the software development process, the designer uses the same notation (OCL), but applied to the concepts that he is accustomed to handle usually at this stage.

Transforming an architectural constraint from one model to another in order to check it, is often difficult because there is not a one-to-one concept mapping between two meta- To solve this problem we proposed a two-step transformation process using an intermediate representation. We introduced a generic metamodel, called ArchMM. Expressions written on a given metamodel are systematically translated internally into their equivalents defined on ArchMM. The latter plays the role of a pivot between the different metamodels.

In the sequel, we will describe the OCL part of ACL, the different metamodels that enable us to cover the development process, how ArchMM was designed and finally how it is used to translate constraints written from one metamodel to another.

Constraint Language

OCL is originally used to add more semantics to UML semi-formal diagrams. It has been standardized by the OMG as version 1.5 and is currently available as the UML 2 final adopted specification [START_REF] Omg | Meta Object Facility (MOF) 2.0 final adopted specification[END_REF]. In addition, Briand et al. [START_REF] Briand | A controlled experiment on the impact of the object constraint language in UML-based maintenance[END_REF] has recently experimented the OCL language in the maintenance of UML models. They concluded that it improves significantly the comprehension and the maintainability of these models.

Usually OCL is used to express constraints on a UML model, whereas, we use it to express constraints on a metamodel. Thus, constraints such as "components in the model must have less than 10 required interfaces" can be expressed. Unfortunately they have a global scope. They apply to all components and not to a particular one as we would like it to be. To limit the scope of such constraints to a particular component, we propose to slightly modify the syntax and semantics of the context part in OCL. At the syntactic level, every constraint context should introduce an identifier. This identifier must be the name of a particular instance of the meta-class cited in the context. At the semantic level, we interpret a 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.

According to this principle, the following constraint, applied to the UML metamodel (see figure 3), states that the required interface ArchivalStorage, of the primitive component of name Logger (introduced in the example of section 2), must be bound to one and only one component.

c o n t e x t L o g g e r : Component i n v : L o g g e r . ownedPort ->s e l e c t ( p : P o r t | p . r e q u i r e d . name = ' A r c h i v a l S t o r a g e ' ) . end->s i z e ( ) = 1 Thus, with a tiny modification of OCL syntax and semantics, we succeed in describing constraints that present an introspection mechanism, by using a 'bicephalous' linguistic structure OCL/Metamodel. A component is able to define a constraint on its own structure. Note that only invariants can be expressed in ACL. Pre-and post-conditions are dismissed.

Architecture Metamodels

In order to cover the development process, we propose different metamodels.

Architectural Abstractions in the ADLs.

In the literature, there exists a plethora of domain-specific and general purpose ADLs. We studied many languages and we established a MOF metamodel for each one. For the sake of brevity, we focus only on those of general purpose, In figure 2, we present a metamodel illustrating xArch. An xArch 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.

xAcme adds to these elements, properties which can be associated to component instances, connector instances and interface instances. It distinguishes also type definitions of the architectural elements from instance descriptions. In addition, it introduces constraints to the different elements.

xADL 2.0 extends the xArch metamodel with some configuration management concepts, like guards for architectural constraints, optional architectural elements, variants of architectural elements which can be used as alternatives, versions of architecture descriptions, and differences in descriptions.

Architectural Abstractions in the UML 2 Metamodel.

Unlike in the version 1.5 of the UML specification, in the final adopted specification of the UML 2 a component is considered as a first-class modelling element. It inherits from the metaclass Class, thus it can participate in associations and in generalizations. It also specializes Encapsu-latedClassifier and StructuredClassifier. So, it can declare ports that group provided and required interfaces, and can be assembled with other components through assembly and delegation (hierarchical) connectors.

Architectural Abstractions in the Component

Technologies.

Among existing component technologies, we studied the Enterprise JavaBeans, Microsoft COM+ and CORBA Component Model (CCM). We present only the latter as it is the OMG standard, but also because it aims at synthesising the concepts found in the other technologies. Through the figure 4 we illustrate these concepts.

A CORBA component defines a set of ports. Each one declares either, emitted, published or consumed events, or used or provided interfaces. A component can be derived from existing components, declare many supported interfaces, may declare a set of attributes and should define one home interface. An interface is characterized by a set of operations. A component assembly defines a set of connections. Each one links a consumed port to a published or emitted port, a provided to a used port or two home interfaces together.

ArchMM: A Generic Architecture Metamodel

This metamodel represents a support for all architectural elements that can be constrained. Because constraints should be expressed throughout the software life cycle, the metamodel should contain abstractions present at the same time in analysis/design models (architecture descriptions or ArchMM supports also connectors as first class entities. They are described as a set of roles, which correspond to connector interfaces in xArch. The metamodel abstracts hierarchical models of components and connectors. Composite components or connectors have configurations, which correspond to subarchitectures in xArch metamodel. Each configuration defines a set of bindings. A binding, corresponding to a connection in CCM and to a link instance or an interface instance mapping in xArch, links: i) two component interfaces together, ii) a component interface to a connector role, iii) the port of a composite component to the interface of one of its subcomponents, iv) or, two connector roles together.

Properties are associated to components, to connectors and to interfaces. They are named and have a typed value. They correspond to CCM component attributes or xAcme properties.

Note that CCM is a flat component model. That is, no hierarchical descriptions of components or connectors are possible. In order to perform transformations of hierarchi-cal descriptions into CCM, component assemblies are used. These allow us to define flattened hierarchical descriptions. Some abstractions exist in all the metamodels, such as component and required or provided interface. However, some concepts present in ArchMM do not exist in some other metamodels. These concepts, such as port, binding, connector or role, may be inferred during the transformation to ArchMM. For example, in CCM there are no connectors. When transforming CCM descriptions into ArchMM, connectors are generated with two roles. Depending on the port kind of the connected components Facet, Receptacle and Event, the generated roles are, respectively, Callee, Caller and Listener or Trigger. The distinction between events of kind Published and Emitted of the CCM metamodel is made at Interface level in ArchMM.

Examples of Constraints

In this section, we present some examples of architectural constraints using ACL applied to ArchMM. We start with a simple example which states that no more than two provided interfaces can be described by a component. Despite its simplicity, this constraint is not of less importance. Such constraints can be found in the quality manuals of certain software development organizations. This kind of constraints can be described on all the subcomponents3 of the component ACS as following: Another type of constraints can be expressed with ACL. In the constraint below, we describe a rule using a quality measure for components, which are cited modules by its This metric is the equivalent of CBO (Coupling Between Objects) [START_REF] Chidamber | Towards a metrics suite for object-oriented design[END_REF] for object-oriented applications. It represents the number of non-directional, distinct inter-component references. In order to preserve a certain level of maintainability of the ACS component and to limit its dependencies with the other components, we described a constraint stating that CBM should be low (CBM < 5) [START_REF] Lindvall | Avoiding architectural degeneration: An evaluation process for software architecture[END_REF].

The third example introduces a general architectural constraint which prevents the existence of a connector binding ACS subcomponents to an external component. The following example addresses a typical evolution constraint involving two consecutive versions. This constraint states that only one provided interface can be added to a component between two consecutive versions [START_REF] Van Ommering | The Koala component model for consumer electronics software[END_REF] of the architecture. It can be expressed as follows: Note that we introduced a new syntactic construct to OCL so that we can reference old versions of architecture descriptions: the @old mark. Unlike @pre which is used, traditionally in OCL, only in postconditions, the @old can be used in invariants. The @old returns the descriptions of the former version of an architecture. In this example, it returns a collection of the provided interface descriptions of the ACS component version before evolution. Note that we have also added a collection operation: com-paredTo(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 comparedTo(...) uses the value of the id attribute. In our situation, we are confronted to a comparison of collections of architectural 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.

As stated in section 2, ACS subcomponents are organized as a pipeline. This pattern can be structurally described using ACL as following: The Configuration meta-class of ArchMM contains some attributes and operations that allow the expression of constraints involving certain graph properties, such as connected graphs (in the constraints above), regular graphs, simple graphs, etc. In addition, we are able to query, for example, for the predecessors and the successors of a vertex (component), the in-and out-degrees of a vertex, the distance between two vertexes or the graph diameter.

Use Scenario of ACL

As stated previously, the constraint language that we proposed (ACL) is not exclusively associated to ArchMM. In fact, it is associated to many metamodels. Each association ACL/metamodel constitutes an ACL profile. So, there are as many profiles as ADLs and component technologies. Each developer uses the profile that corresponds to the language or the technology that he usually uses. In this way, he is not bound to manipulate some concepts, present in ArchMM, and that he is not familiar with, like for example, connectors or composite components for a CCM developer.

For the existing ADLs, having a constraint language, for example xAcme's Armani, ACL can be used as a complementary predicate language. It can describe, in addition to general structural constraints, constraints of pure evolution, stated previously, or constraints using graph operations. However, for the existing specifications written in xAcme, the architect is requested to translate manually the constraints written in Armani into ACL profile for xAcme. Consider the example presented in section 2. The pipeline structural constraints defined in Armani can be expressed in ACL profile for xAcme as follows: In one of the invariants, we make use of the operation isConnected(). This attribute is associated, in this ACL profile, to the type SubArchitecture. It has the same semantics as for the type Configuration in ACL profile for ArchMM. All graph operations are associated to the SubArchitecture type.

As we remark through this example, the syntaxes of Armani and of ACL profile for xAcme are quite similar. We believe that the manual translation could be performed easily. The advantage of translating constraints into the ACL profile is to have a homogeneous constraint specification throughout the software development process. In addition, transformations can be done automatically to obtain constraints that apply to implementation models, as shown below. However, the expression of constraints dealing with the behavioral aspect is not yet taken into account in ACL.

The constraints are evaluated each time new changes are made on the architecture or the component description. Upon their evaluation, these constraints are first transformed into constraints expressed in the standard ACL pro-file for ArchMM. The architecture or the component description is also transformed into a pivot description, which is ArchMM-compliant. This transformation to the standard ACL profile is also used to make transformations from one profile to another (different from the standard one). For example, the pipeline constraints are transformed into the following when implementing the system in CCM. Note that the invariant that checks for the existence of only two roles per connector has not been maintained in this constraint specification, because the connector abstraction does not exist in CCM metamodel. Note also that in this ACL profile, graph operations are associated to the Compo-nentAssembly type. This is the case for the operation isConnected() in one of the invariants.

As in the previous case, this constraint is first transformed so a constraint which conforms to ArchMM before evaluation.

In the example presented in section 2, we established a UML model before implementing the system in CCM. Note that the transformation from the ACL profile for xAcme to the one for UML is done in the same manner as if we directly implemented the system in CCM.

Prototype Tool

In order to validate our approach, we developed ACE: Architectural Constraint Evaluator. This prototype allows the edition and the evaluation of architectural constraints specified in different stages. In its current version, it interprets ACL profile for xAcme at the architecture design stage and ACL profile for the Fractal Component Model [START_REF] Bruneton | An open component model and its support in Java[END_REF] at the implementation stage.

ACE uses the XMI format of the metamodel to guide the developer in editing his architectural constraints. Constraints are transformed to be compliant with ArchMM, in order to be evaluated. This transformation is performed on the basis of a list of mappings between xAcme or Fractal metamodel and ArchMM. The generated constraints are evaluated on an intermediate model, which is obtained by a transformation of xAcme or Fractal descriptions. This pivot model is a specific instance of ArchMM which is defined as a set of XML schemas. The module performing constraint evaluation has been built upon a slightly modified version of OCL Compiler4 .

Suppose a constraint defined at design stage using the ACL profile for xAcme. In order to evaluate this constraint at implementation stage (in this case, on Fractal descriptions), the following steps will be performed: i) transform the constraint specified using ACL profile for xAcme into the standard profile; ii) transform the Fractal architecture description into the pivot model; iii) and evaluate the transformed constraint on the pivot model.

During a maintenance process, a new version of an architecture or a component description can be introduced to ACE. The constraints are evaluated for the new description, which is then transformed into the pivot model.

ACE was designed in order to be easily extended to support other ADLs or component technologies, like those presented in this paper (CCM or UML 2). For each new added ADL or component technology, a new metamodel should be established, which would generate a new ACL profile. Only the model and constraint transformers should be enhanced.

Related Work

Some existing ADLs provide constraint languages [START_REF] Medvidovic | A classification and comparison framework for software architecture description languages[END_REF].

In WRIGHT [START_REF] Allen | A Formal Approach to Software Architecture[END_REF], the constraint language used is a subset of the Z specification language [START_REF] Spivey | The Z Notation: A Reference Manual[END_REF]. In xAcme, architectural constraints are expressed using the Armani predicate language. All these languages have in common the same basis as with OCL. They are based on FOL (First Order Logic), manipulate collections of architectural elements and provide collection operations. In these languages, the architectural elements, to be constrained, are part of the language and are defined as keywords. The approach that we proposed disconnects these elements through the generic architecture metamodel, ArchMM. Thus, it becomes possible to cover all the development process with the same constraint language. ACL allows also the specification of pure evolution constraints, whereas the ADLs focus only on design constraints.

In [START_REF] Medvidovic | Modeling software architectures in the unified modeling language[END_REF], Medvidovic et al. propose three approaches to support modeling software architectures in UML 1.5. In the second approach, the authors suggest to extend UML through stereotypes, tagged values and OCL constraints in order to define architectural styles. In this work, the con-straints are considered as general rules that apply to all modelled architectural elements. However, in our approach the constraints are considered as specific rules that apply only to a component of the current model. They stipulate particular choices of the developer. We think that the two approaches are complementary. The first provides capabilities to define common rules for several projects, while the second can be used to specify rules for a specific project.

Conclusion and Future Work

In this paper, we presented a constraint language which allows to make explicit architectural choices at every stage of the component-based development process. This language was designed in such a manner to be extended easily in order to support other design or implementation models. The originality of this language is the separation between the basic constraint expression mode and the manipulated architectural concepts.

Throughout development process, various concepts are handled. The separation that we propose, enables us to use the same syntax to express constraints at different stages of the development process. Moreover, it is easier to identify the mappings between concepts from different metamodels, when they are not embedded into the language. Thus, it becomes easier to define constraint transformation mechanisms. We think that our approach may be helpful in the context of Model Driven Engineering.

The next step of our work will be the extension of our approach on behavioral aspect of architecture descriptions. Thus, we project to enhance ACL to provide such capabilities, by extending ArchMM with behavioral representations.

Figure 1 .

 1 Figure 1. Constraint preservation in a component-based software development process

  i n v a r i a n t f o r a l l conn : C o n n e c t o r i n s e l f . C o n n e c t o r s | s i z e ( conn . R o l e s ) = = 2 and e x i s t s r : R o l e i n conn . R o l e s | s a t i s f i e s T y p e ( r , s i n k T ) and e x i s t s r : R o l e i n conn . R o l e s | s a t i s f i e s T y p e ( r , s o u r c e T ) (c) Each connector (arc) binds two components (vertices). the input port to a sink role and the output port to a source role: i n v a r i a n t f o r a l l conn : C o n n e c t o r i n s e l f . C o n n e c t o r s | f o r a l l r : R o l e i n conn . R o l e s | e x i s t s comp : Component i n s e l f .

Figure 2 .

 2 Figure 2. The xArch metamodel

Figure 3 .

 3 Figure 3. A flattened excerpt of the UML 2 component metamodel

1 Figure 4 .

 14 Figure 4. The CORBA component structural metamodel

  c o n t e x t ACS : CompositeCompo ne n t i n v : ACS . subComponent ->f o r A l l ( C : Component | C . p o r t . i n t e r f a c e ->s e l e c t ( i : I n t e r f a c e | i . k i n d = ' P r o v i d e d ')-> s i z e ( ) < = 2 )

Figure 5 .

 5 Figure 5. ArchMM: A generic metamodel representing architectural abstractions

  c o n t e x t ACS : CompositeCompo ne nt i n v : ACS . c o n f i g u r a t i o n . b i n d i n g ->f o r A l l ( b : B i n d i n g | ACS . subComponent . p o r t . i n t e r f a c e ->i n c l u d e s ( b . i n t e r f a c e ) )

  c o n t e x t ACS : CompositeCompo ne nt i n v : ACS . p o r t . i n t e r f a c e ->s e l e c t ( i : I n t e r f a c e | i . k i n d = ' P r o v i d e d ' ) @old ->comparedTo (ACS . p o r t . i n t e r f a c e ->s e l e c t ( i : I n t e r f a c e | i . k i n d = ' P r o v i d e d ' ) ) ->s i z e ( ) < = 1

--

  Each s u b c o m p o n e n t s h o u l d h a v e --i n p u t and o u t p u t p o r t s c o n t e x t ACS : CompositeCompo ne n t i n v : ACS . subComponent . p o r t ->f o r A l l ( p : P o r t | ( p . k i n d = ' I n p u t ' ) o r ( p . k i n d = ' O u t p u t ' ) ) and --Each c o n n e c t o r s h o u l d d e f i n e two r o l e s --( one s i n k and one s o u r c e ) ACS . c o n f i g u r a t i o n . b i n d i n g . r o l e . c o n n e c t o r ->A s S e t ( ) ->f o r A l l ( con : C o n n e c t o r | ( con . r o l e ->s i z e ( ) = 2 ) and ( ( con . r o l e . k i n d = ' S o u r c e ' ) o r ( con . r o l e . k i n d = ' Sink ' ) ) ) and --Each c o n n e c t o r b i n d s two c o m p o n e n t s --( i n p u t bound t o s i n k and o u t p u t t o s o u r c e ) ACS . c o n f i g u r a t i o n . b i n d i n g . r o l e . c o n n e c t o r ->A s S e t ( ) ->f o r A l l ( con : C o n n e c t o r | con . r o l e ->f o r A l l ( r : R o l e | ACS . subComponent ->e x i s t s ( com : Component | com . p o r t ->e x i s t s ( p : P o r t | ( r i n ACS . c o n f i g u r a t i o n . b i n d i n g ) and ( ( p . k i n d = ' I n p u t ' ) and ( r . k i n d = ' Sink ' ) ) o r ( ( p . k i n d = ' O u t p u t ' ) and ( r . k i n d = ' S o u r c e ' ) ) ) ) ) ) and --The g r a p h s h o u l d be c o n n e c t e d ACS . c o n f i g u r a t i o n . i s C o n n e c t e d and --The g r a p h s h o u l d c o n t a i n t h e number --o f v e r t i c e s -1 , a r c s ACS . c o n f i g u r a t i o n . b i n d i n g . r o l e . c o n n e c t o r ->A s S e t ()-> s i z e ( ) = ACS . subComponent ->s i z e () -1 and --The g r a p h r e p r e s e n t s a l i s t ACS . subComponent ->f o r A l l ( com : Component | ( com . p o r t ->s i z e ( ) = 2 ) and ( com . p o r t ->e x i s t s ( p : P o r t | p . k i n d = ' I n p u t ' ) ) and ( com . p o r t ->e x i s t s ( p : P o r t | p . k i n d = ' O u t p u t ' ) ) )

  c o n t e x t ACS : C o m p o n e n t I n s t a n c e i n v : ACS . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o m p o n e n t I n s t a n c e . i n t e r f a c e I n s t a n c e ->f o r A l l ( i : I n t e r f a c e I n s t a n c e | ( i . d i r e c t i o n = ' i n ' ) o r ( i . d i r e c t i o n = ' o u t ' ) ) and ACS . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o n n e c t o r I n s t a n c e ->f o r A l l ( con : C o n n e c t o r I n s t a n c e | ( con . i n t e r f a c e I n s t a n c e ->s i z e ( ) = = 2 ) and ( ( con . i n t e r f a c e I n s t a n c e . d i r e c t i o n = ' i n ' ) o r ( con . i n t e r f a c e I n s t a n c e . d i r e c t i o n = ' o u t ' ) ) ) and ACS . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o n n e c t o r I n s t a n c e ->f o r A l l ( con : C o n n e c t o r I n s t a n c e | con . i n t e r f a c e I n s t a n c e ->f o r A l l ( iCon : I n t e r f a c e I n s t a n c e | ACS . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o m p o n e n t I n s t a n c e ->e x i s t s ( com : C o m p o n e n t I n s t a n c e | com . i n t e r f a c e I n s t a n c e ->e x i s t s ( iCom : I n t e r f a c e I n s t a n c e | ( iCon i n ACS . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . l i n k I n s t a n c e . p o i n t . a n c h o r O n I n t e r f a c e ) and ( ( iCom . d i r e c t i o n = ' i n ' ) and ( iCon . d i r e c t i o n = ' o u t ' ) ) o r ( ( iCom . d i r e c t i o n = ' o u t ' ) and ( iCon . d i r e c t i o n = ' i n ' ) ) ) ) ) ) and ACS . s u b A r c h i t e c t u r e . i s C o n n e c t e d ( ) and ACS . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o n n e c t o r I n s t a n c e ->s i z e ( ) = ACS . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o m p o n e n t I n s t a n c e ->s i z e ( ) -1 and ACS . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o m p o n e n t I n s t a n c e ->f o r A l l ( comp : C o m p o n e n t I n s t a n c e | ( comp . i n t e r f a c e I n s t a n c e ->s i z e ( ) = 2 ) and ( comp . i n t e r f a c e I n s t a n c e ->e x i s t s ( i : I n t e r f a c e I n s t a n c e | i . d i r e c t i o n = ' i n ' ) ) and ( comp . i n t e r f a c e I n s t a n c e ->e x i s t s ( i : I n t e r f a c e I n s t a n c e | i . d i r e c t i o n = ' o u t ' ) ) )

  c o n t e x t ACS : ComponentAssembly i n v : ACS . c o n n e c t i o n . p o r t ->f o r A l l ( p : P o r t | ( p . p r o v i d e d ->s i z e ( ) = 1 ) o r ( p . used ->s i z e ( ) = 1 ) ) and ACS . c o n n e c t i o n ->f o r A l l ( con : C o n n e c t i o n | ( con . p o r t . p r o v i d e d ->s i z e ( ) = 1 ) and ( con . p o r t . used->s i z e ( ) = 1 ) ) and ACS . i s C o n n e c t e d ( ) and ACS . c o n n e c t i o n ->s i z e ( ) = ACS . c o n n e c t i o n . p o r t . component ->A s S e t ()-> s i z e ( ) -1 and ACS . c o n n e c t i o n . p o r t . component->a s S e t ( ) ->f o r A l l ( com : Component | com . p o r t ->s i z e ( ) = 2 and com . p o r t ->e x i s t s ( p : P o r t | p . p r o v i d e d ->s i z e ( ) = 1 ) and com . p o r t ->e x i s t s ( p : P o r t | p . used ->s i z e ( ) = 1 )

Recent experiments[START_REF] Roshandel | Understanding tradeoffs among different architectural modeling approaches[END_REF] showed also that some ADLs and the UML can be used in a complementary fashion, in order to make better analysis of software architectures.

For the moment, we suppose that only direct subcomponents can be accessible from a composite component.

Available at http://dresden-ocl.sourceforge.net/

Acknowledgment

This material is based upon work supported by the Brittany Region Council under contract number 20046839.


Vincent Le Gloahec
email: v.legloahec@alkante.com

Regis Fleurquin
email: regis.fleurquin@irisa.fr

Salah Sadou
email: salah.sadou@univ-ubs.fr

Good Architecture = Good (ADL + Practices)

Keywords: Best Practices, Design, Software Architecture Quality

In order to ensure the quality of their software development, companies incorporate best practices from recognized repositories or from their own experiences. These best practices are often described in software quality manuals which does not guarantee their implementation. In this paper, we propose a framework for the implementation of best practices concerning the design of the software architecture. We treat rst the case of architecture design activity because it's the basis of the software development process. Our framework enables on the one hand to describe best practices and on the other hand to check their application by designers. We present an implementation of our framework in the Eclipse platform and for an ADL dedicated to Web applications. Finally, we give an example of use taken from the context of our industrial partner.

Introduction

The software architecture plays a fundamental role in modern development processes. Throughout a project, it can serve as a baseline against which the various stakeholders analyze, understand, build their decisions and evaluate the software [START_REF] Erdogmus | Architecture meets agility[END_REF]. The languages (Acme [START_REF] Garlan | Acme: architectural description of componentbased systems[END_REF], xADL [START_REF] Dashofy | A comprehensive approach for the development of modular software architecture description languages[END_REF], ByADL [START_REF] Di Ruscio | Developing next generation adls through mde techniques[END_REF], UML as an ADL [START_REF] Medvidovic | Modeling software architectures in the unied modeling language[END_REF]) used to elaborate architectures highlight concepts (such as connectors, components, etc.) that meet two requirements: i) be enough expressive to represent all targeted systems. ii) allow the architect to focus her/his attention on key issues such as information hiding, coupling, cohesion, precision, etc. Architecture Description Languages (ADL) direct and sometimes compel the architect to comply with certain relevant rules and universally recognized in the target area. Thus, they restrict the form of representable architectures by excluding undesirable ones. The aim is to produce architectures with good quality properties.

However, these languages are designed to allow the representation of architectures that answer a variety type of needs. Thus, some architectural motifs can be considered useful in some contexts and avoided in others. The quality of architecture is not absolute but is estimated according to each project's requirements (cost, schedule, quality of service, etc.) [START_REF] Bass | Software architecture in practice[END_REF] that sometimes are conicting.

So, the quality of an architecture is the result of a compromise. The language must be tolerant and not unduly restrict the range of possibilities, in order to let free the creativity of architects. Consequently, the use of an ADL alone, as elegant as it may be, can not guarantee obtaining an architecture that meets the quality requirements desired for a given project.

Best language Practices (BPs) found in the literature, such as modeling processes [START_REF] Henderson-Sellers | Method engineering for oo systems development[END_REF] [8], styles [START_REF] Ambler | The Elements of UML(TM) 2.0 Style[END_REF], patterns [START_REF] Buschmann | Patternoriented software architecture: a system of patterns[END_REF] and metrics can then provide an essential complementary tool. Based on the specic context of the project, they will help to direct the architect toward the subset of relevant models among those allowed by the language. In this sense, BPs help the architect to limit the area of choice thanks to a language restriction adapted to the project. They help to increase the eectiveness of development in terms of quality and productivity. Additional BPs specic to an application domain, a technology or a managerial and cultural context may also emerge from projects within companies. Properly used in a project, these best language practices constitute the expertise and the valueadded of a company. This valuable capital of knowledge guarantees to a company the quality of its architectural models and thus satisfy its customers, to stand out, to solicit labels and certicates [START_REF] Gratton | Beyond best practices[END_REF]. In other words, to be competitive.

Unfortunately, we show in section 2 of this paper that due to a lack of an adequate formalism to document this knowledge, companies that try to capitalize on this knowledge use informal documents, often incomplete, poorly referenced and sometimes scattered. This leads to an inadequate and an ineective use and sometimes loss of best language practices. This loss decrease the quality of the designed architectures. We rely for that on a study conducted with an industrial partner that uses a dedicated ADL for web applications. We propose a language (section 3) and a software platform (section 4) that allow respectively to document and to enact these BPs for any graphical ADL. In this way, we ensure the durability and reuse of knowledge, as well as a constant verication of the application of best language practices. We then show, in section 5, how this language can be used to document some BPs for web applications coming from our industrial partner. In the same section, we show also how these practices can be integrated in their ADL tool (AlCoWeb-Builder). Thus, this helps developers to respect the best language practices dened in their own companies, without changing their working habits. Finally, we describe related work in section 6 before concluding in section 7.

Problem Statement

In this section, we show the interest for a company to make productive its language practices. We rely on a study undertaken in one of our industrial partners:

the Alkante company 4 . We begin by presenting the development environment (language, tool, best practices) developed by this company for designing the architecture of its applications. Then, we present the diculties it faces in some of its developments. The analysis of the causes of these diculties highlights the interest to capitalize and automate best language practices.

Development Environment

In the context of rich Web application development, Alkante has dened an ADL (referred to as AlCoWeb) to help design the architecture of its applications [START_REF] Kadri | Building the Presentation-Tier of Rich Web Applications with Hierarchical Components[END_REF].

This ADL is an UML prole. The UML language has been chosen mainly because the version 2.0 of the UML specication contains most of the abstractions needed in modeling rich Web applications with hierarchical entities. Alkante develops mainly Geographical Information Systems (GIS) with the help of a componentoriented framework composed of PHP and Javascript code artifacts. Thus, when designers dene the architecture of their applications, they need to deal with entities such as modules, pages, forms, html controls and raw PHP scripts. In order to manipulate those specic entities in the AlCoWeb ADL, they have been dened as stereotypes dedicated to the specic Alkante's architecture. In this prole, we can found stereotypes such as AlkModule, AlkHtmlForm, AlkHtmlButton, etc.

Based on the AlCoWeb ADL, Alkante has developed a complete model-driven architecture platform called AlCoWeb-Builder. This tool allows the designers to model and assemble web-components to create large applications. Components are designed hierarchically and incrementally using component assemblies and connectors. Once atomic and hierarchical components have been designed, they are made available as components o-the-shelf and can be reused to build larger artifacts, like an authentication form or a geographical web service for example. AlCoWeb-Builder is a graphical editor, build upon several frameworks of the Eclipse platform. It also comes with a code generation facility. Based on a template system, this tool allows generating the code of the designed Web applications, as illustrated in Fig. 1.

Using this ADL in many projects, the company has identied over the years some language practices. For instance, to ensure a complete code generation, the architecture of Web applications should be very specic. Thus, the quality assurance manager (QAM) of the company has dened a dedicated BP in the form of a complete process, documented in a quality manual.

The core of this BP consists of the following steps: The QAM in charge of the denition has added some other BPs in the quality manual. Many of them take the form of modeling rules that needs to be checked to ensure the quality of a nal architecture. These BPs ensure things such as naming conventions or the way components can be put together.

Recurrent Problems

The MDA approach allows Alkante's team to ease their development eort, through components reuse at the model level and to automate, as possible, code generation and deployment. Although this approach reduces development costs, they observed on occasion that some architectures had not been properly designed.

Some architectures led to errors in the generated code. But, a major drawback of code generation is that it is dicult to nd, from the generated code, the origin of the errors in an architecture. Consequently, developers take a long time to repair. A causal analysis has showed that these errors result from faults made during the component assembly stages when building large applications, while atomic and small hierarchical components are mostly modeled correctly.

As AlCoWeb is an hierarchical language, the code generation engine expects the architecture to be designed hierarchically, where HTML forms must be contained in a page, pages must be contained in the root application component, and so on. If this constraint is not respected, the generated application won't be usable. Nevertheless, the BP cited above should have guarantee the respect of this constraint. Clearly, this BP has not been correctly applied or not applied at all.

Another recurrent problem concerns the way that components must be assembled. All basic and some more advanced HTML controls more than 30 components, such as buttons, expanded lists, tabs, calendars, etc. are available as components o the shelf. By default, all those components are designed to provide the service getHtml(), which returns the HTML code of the component.

At runtime, stacked calls of this service on a hierarchical component allows to produce the complete HTML code of a complex and rich Web page. However, structural components that form the basis of the architecture e.g. modules, application containers and scripts must be designed from scratch by the developers. To design a valid architecture, each getHtml() services of AlkHtmlPage components must be delegated to the parent application container (using a delegate connector from a page's provided port to one provided port of the application component). Then, those provided services must be connected to a required port of a script component using an assembly connector. As for the composition of hierarchical components, the non respect of this specic assembly leads to a poor quality of the architecture that results in the generation of unusable Web applications. Again, this problem results from the non-application or misapplication of a BP, yet documented in the quality manual.

Discussion

The source of the two problems cited above is the non-compliance with some of the BPs outlined in the quality manual. Further causal analysis shown that the root cause has always been one of the followings:

1. Involvement of new designers who did not know when and how the documented practices should be applied. This problem occurs because most of the documented practices do not describe precisely their application context and some are ambiguous;

2. Some BP become fastidious when the architecture complexity grows (for instance, inducing the same manual verication but on numerous model elements) thus developers have ignored or partially applied them;

3. Some BP are complex and consequently manually error prone (for instance, inducing many verications on several model elements);

4. When a project is subject to signicant time constraints, developers have chosen to ignore some BP in order to respect the deadline.

To remedy this, we must make productive the BPs. They must be enforced in the used tools (editor, transformations and code generator). We can try to hard-code the BP in the tools suite (if possible by the tool). But, we believe it would not be a good solution. Firstly, tools change over time. We do not want to have to re-code all the BPs each time a tool change. Secondly, BPs evolved too.

Each time a BP change, we have to do the corresponding changes in the tool's code. Thus, we must separate the BP denition from the tools.

We advocate that the BPs become rst class entities when using an ADL language. Thus, the language will be adapted to t a particular context (developer, project, company, application domain, etc.). In this way, each company can contextualize a general purpose language to its own needs.

Consequently, to produce quality products, a language should not be reduced solely to its three components (abstract syntax, semantics and concrete syntax).

Indeed, as we emphasized throughout this section, companies often dene their own best practices which enrich the language to t a specic context. The remaining of the paper introduces our approach for the denition and application of best language practices at the early stage of design of software architectures.

Best Practices Description Language

The language we introduce in this section, called GooMod, contains some properties needed for the description of best design practices. In this section we show how we have done to identify these properties and then we describe the abstract syntax and semantic of the GooMod language.

Identied Properties

Architectural design is a particular case of modeling activity. However, there is a rich literature on best practices for modeling activity. Thus, we made a survey on best practices in modeling activity in order to identify their characteristics and forms. Through literature we observed three types of best modeling practices:

those that are concerned only with the form (style) of produced models, those that describe the process of their design, and those that combine both. As the third type is only a combination of the rst two, we limited our study to examples covering the former types. For the rst type we found that the best practices for Agile Modeling given in [START_REF] Ambler | The Elements of UML(TM) 2.0 Style[END_REF] are good examples. In [START_REF] Ramsin | Process-centered review of object oriented software development methodologies[END_REF], Ramsin and Paige give a detailed review of object-oriented software development methods. From this review we extracted properties concerning the process aspect of BP. For the sake of brevity, we can't go further on this study in this paper. But interested reader may found more detail on the dedicated web page 5 . 5 http://www-valoria.univ-ubs.fr/SE/AMGP Thus, we have identied the following properties:

Identication of the context: to identify the context of a BP, the language must be able to check the state of the model in order to determine whether it is a valid candidate for the BP or not.

Goal checking: to check that a BP has been correctly applied on a model, we must be able to check that the status of the latter conforms to the objective targeted by the BP. On the BP description language level, this property highlights the same need as the one before.

Description of collaborations: we have seen that some BP cannot be checked automatically. Even if the system alone achieves some parts of the checking, it would need the designer's opinion in order to make a decision. In case of alternative paths, sometimes the system is in a situation where it cannot determine the right path automatically. Thus, a BP description language should allow interactions with the designer.

Process denition: as the process denes a sequence of steps with possible iterations, optional steps, and alternative paths, the targeted language should allow processes to be dened with such constructions.

Restriction of the design language: several best practices based on modeling methodologies suggest a gradual increase in the number of manipulated concepts (e.g., each step concerns only a subset of the modeling language's concepts). Thus, the BP description language should allow the denition of this subset for each step.

The documentation of a BP associated with a design language requires a description that is independent of any tool; indeed, a BP is specic only to the language. It describes a particular use of its concepts. It should not assume modes of interaction (buttons, menus, etc.) used by an editor in order to provide access to these concepts. Therefore, a BP must be described in a way that can be qualied as a Platform Independent Model (PIM) in Model-Driven Engineering (MDE) terminology (see next section). Ignoring this rule leads QAM to re-document the BP at each new version or tool change. The GooMod language contains all properties described above and oers a way to document the BP independently of any editor. To introduce the GooMod language we will present its abstract syntax then its semantic. In the next section we will present an example of use of this language.

Abstract syntax of the GooMod Language

The abstract syntax of the GooMod language is given in Fig. 2. The process part of a BP is described as a weakly-connected directed graph. In this graph, each vertex represents a coherent modeling activity that we call a step. Arcs (identied by Bind in our meta-model) connect pairs of vertices. Loops (arcs whose head and tail coincide) are allowed, but not multi-arcs (arcs with the same tail and same head).

A step is associated with four elements: its context, its associated design style, the set of language concepts usable during its execution, and a set of The context is a rst-order formula evaluated on the abstract syntax graph of the input model before the beginning of the step. We call this formula a pre-condition. The design style is a rst-order formula that is evaluated on the abstract syntax graph of the current model in order to allow designer to exit from the step. We call this formula a post-condition. The set of the usable language concepts is a subset of the non-abstract meta-class of the abstract syntax (described in a MOF Model) of the targeted design language.

Because some BP require the establishment of a collaboration between the system and the designer, we have included the ability to integrate some actions at the beginning (entry ) and/or at the end (exit ) of a step. The possible actions are: output a message, an input of a value, and the assignment of a value to a local variable. Indeed, at each step it is sometimes necessary to have additional information on the model that only the designer can provide (goal of Input action). Conversely, it is sometimes useful to provide designers information that they can not deduce easily from the visible aspect of the model, but the system can calculate (goal of Output action). This concerns introspection operations that can be achieved with MOF operators at pre-and post-conditions level.

Hence, the usefulness of variables associated with steps to hold results. Thus, actions allow interaction with the designer using messages composed of strings and calculated values.

Steps are also dened by two boolean properties: isInitial and IsFinal. At least one step is marked as initial and one as nal in a graph. Finally, an arc can be marked as optional, meaning that its head step is optional.

Semantic of the GooMod Language

Semantically the graph of a BP is a behavior model composed of a nite number of states, transitions between those states, and some Entry /Exit actions.

Thus, a BP is described as a nite and deterministic state machine with states corresponding to the steps of the BP's process.

At each step, the elements which constitute it are used as follows:

1. Before entering the step, the pre-conditions are checked to ensure that the current model is in a valid state compared with the given step. Failure implies that the step is not yet allowed;

2. If the checking succeeds, then before starting model edits a list of actions (Entry Action ), possibly empty, is launched. These actions initialize the environment associated with the step. This may correspond to the initializing of some local variables or simply interactions with the designer;

3. A given step can use only its associated language concepts. In fact, each concept is associated with use type (create, delete or update).

4. When the designer indicates that the work related to the step is completed, a list of actions (Exit Action ) will be launched to prepare the step's environment to this end. With these actions the system interacts with the designer to gain information that it can not extract from the model's state; the choice is left to the designer. A Bind can also be dened as optional. In this case, its tail step becomes optional through the transition it denes. Thus, the possible transitions of the tail step are added to those of the optional step, and so on.

Implementation of GooMod

In order to implement the GooMod language, we developed a complete platform for the management of BP, starting from their denition at the platform independent model (PIM) level up to their enactment at the platform specic model (PSM) level. Figure 3 illustrates the platform and its PIM-PSM separation. This section will describe both levels and their associated tools.

PIM level: Modeling BP

The PIM level of the GooMod language allows description of BP independently of the used design tool. This level is implemented thanks to the BP Denition tool (see top of Fig. 3). This tool is designed for QAM in charge of the denition of BP

PSM level: BP enactment

The PSM level aims to attach the denition which is done at the PIM level with a specic design tool. For that, our platform is composed of two parts:

BP Activation Tool: that aims to link a BP model dened with the BP Denition tool to a target design tool. It controls the enforcement of the BP process.

Targeted Design Tool: which is the end-user design tool where the BP will be performed. This tool is not intended to be modied or altered directly, but will be controlled by an external plugin, which in our case is the BP Activation Tool.

A targeted design tool can be, for instance, the AlCoWeb-Builder tool (see bottom-left of Fig. 3), which allows Alkante's designers to model the architecture 6 See Eclipse Modeling Project (http://www.eclipse.org/modeling) of their Web applications. However, our approach is not limited to this design tool. Indeed, the BP Activation tool has been designed to interact with any Eclipse GMF-generated editors. If the rst feature of BP Activation is to enact a process and check the elaboration of models, the second feature consists of controlling some parts of the targeted design tool. At each step of modeling, only the editable concepts of the current step are active. Right now, a technical solution has been used, based on the extension capabilities of the GMF framework.

During a given step, we dynamically activate/deactivate GMF creation tools according to the editable concepts allowed for this step. With this approach, we are able to control any GMF editor within the Eclipse platform. To tackle the problem of how to interact with other design tools, we plan to elaborate a mapping meta-model so that QAM could map editable concepts with the creation features (buttons, actions, items) of the design tool.

5

Case Study: Alkante's BP

In the following we present how to dene the BP presented in section 2 and how to apply them during a design process.

Formal Description of BP

The GooMod language allows to represent the dierent steps of this BP in the form of a process. The steps are described with the help of the BP Denition tool as depicted in Fig 4. The process denes an iteration that allows to create multiple pages and their content. Indeed, once a script has been added, the designer will either be able to continue through the process or to iterate by adding new pages. The dashed arrow between Add Form and Add HTML Controls represents an optional transition, thus making the latter step optional. This indicates that adding HTML controls to forms is not necessary to produce a valid Web application in this specic context.

The QAM in charge of the denition of this BP is able to detail each step of the process by adding some rules that need to be checked to ensure the quality of the nal architecture. For each step, the QAM can dene both preand post-conditions that will ensure that models will be well-constructed. Those constraints are given using the OCL language. Besides dening constraints, the QAM can add entry and exit actions that will allow the designer to collaborate with the system by means of inputs and/or outputs. Those actions are described using a script-like syntax, where it is possible to declare variables and input/output operations. In addition, each step comes with a list of editable concepts that will be used to follow the dened process. In the Alkante's BP, each step is associated with a list of meta-classes of the AlCoWeb language: Component and Port for each step except the last one, and the meta-class Connector for the last step (Connect Components ), thus allowing to connect components with each other.

For example, here is a complete description of the step Add Form : The pre-condition checks that before entering the step, the model contains at least one page. The entry action is used to inform the designer about the constraint related to this step (at least one form per page) and recommendation about graphical guidelines. The syntax used to describe editable concepts is given in the form of two strings: the rst is the name of the concept, the second is composed of the rst letters of the authorized behaviors. In our case, cud means create, update and delete. In the above example, the exit action is used to ask the designer to check whether the graphical guidelines are respected. The post-condition is used to check that the model contains at least one form per page and that the graphical guidelines were respected. In the BP Denition tool, all the rules listed above are editable using advanced editors and content assistants, so that designers don't have to manipulate the syntax given in this example. In the company, the GooMod platform is used dierently depending on skills and experience of developers. Novice developers systematically use the platform, whereas experts prefer to make verications at key steps of the design process. Indeed, novices are not fully aware of all the practices that have to be respected to produce a quality architecture, therefore they prefer to be guided through the whole design process. This reinforces our idea that a tool must be exible enough to adapt to the most users. The GooMod platform has been designed accordingly.

The reader may have other examples of use of the GooMod platform through screencasts at http://www-valoria.univ-ubs.fr/SE/goomod. [START_REF] Bass | Software architecture in practice[END_REF] Related Work

In business, best practices management is a particular case of Knowledge Management. This domain aims to identify, gather and capitalize on all used knowledge (including BP) to improve companies performance [START_REF] Stewart | The Wealth of Knowledge: Intellectual Capital and the Twenty-rst Century Organization[END_REF]. Thus, in the domain of BP for software development, there are three types of works: those interested in BP archiving, those interested in their modeling, and those who seek their implementation directly in the development tools.

Several works suggest introducing processes and tools that facilitate storage, sharing, and dissemination of BP within companies (e.g. [START_REF] Fragidis | From repositories of best practices to networks of best practices[END_REF], [START_REF] Zhu | An infrastructure for indexing and organizing best practices[END_REF]). They advocate in particular the use of real repositories allowing various forms of consultation, thus facilitating research and discovery of BPs. However, the BP referred to by these systems are documented and available only through textual and informal. It is therefore impossible to make them productive in order to control the use within CASE tools. To our knowledge, there is no other work on the denition of rigorous languages for documenting BPs. However this eld can benet from works concerned with method engineering ( [START_REF] Henderson-Sellers | Method engineering for oo systems development[END_REF], [START_REF] Gonzalez-Perez | Modelling software development methodologies: A conceptual foundation[END_REF]) and software development process ( [START_REF]OMG: Software Process Engineering Meta-Model, version 2.0 (SPEM2.0)[END_REF]). Indeed, a BP is a particular form of development method.

It imposes a way to run an activity, a process, and also imposes a number of constraints on the proper use of language concepts. Language engineering and its denition tools are therefore very useful.

With CASE tools, several works suggest encouraging, even requiring, the respect of certain BP. The domain that had produced good results in recent years is the one that focuses on the automation of BP concerning detection and correction of inconsistencies. These include, in particular, the work presented in [START_REF] Biehl | Automated architecture consistency checking for model driven software development[END_REF], [START_REF] Egyed | Uml/analyzer: A tool for the instant consistency checking of uml models[END_REF], [START_REF] Hessellund | Guided development with multiple domain-specic languages[END_REF] and [START_REF] Blanc | Detecting model inconsistency through operation-based model construction[END_REF]. They propose adding extensions to modeling tools, such as Eclipse or Rational, that are able to intercept the actions of designers and inspect the information system of the tools in order to detect the occurrence of certain types of inconsistency. The inconsistencies treated by these works are various, but they remain on the analysis of syntactical consistency of models expressed in one or more languages, which is already quite complex. Sometimes they address the problem of what they call methodological inconsistencies; i.e., the detection of non-compliance with guidelines relating to how the language should be used. But it involves BP with a much smaller granularity than those we are dealing with.

In the domain of software architectural modeling, Acme has been proposed as a generic ADL that provides an extensible infrastructure for describing, generating and analysing software architectures descriptions [START_REF] Garlan | Acme: architectural description of componentbased systems[END_REF]. This language is supported by the AcmeStudio tool [START_REF] Schmerl | Acmestudio: Supporting style-centered architecture development[END_REF], a graphical editing environment for software architecture design implemented as an Eclipse Plug-in. AcmeStudio oers the possibility to dene rules (invariants and heuristics) to check whether an architectural model is well formed. However, rules are to be dened directly at the design stage and are embedded in the architectural model. This limits the portability of the solution to another tool and the expressiveness of BP. In our approach, we prefer the denition of such rules to be at the PIM level, so that they can be reused and remain independent of any tool. The GooMod platform can be easily adapted to work with AcmeStudio, since this tool is an Eclipsebased graphical editor. In this way, it could propose features not available in AcmeStudio: support for a process representation of the design activity, better understanding of the ADL through the manipulation of only valuable concepts at each design steps, and ways to collaborate dynamically with designers.

conclusion

To produce softwares with high quality, a company must rst ensure that their architecture is of high quality. To achieve a desired level of quality the use of an ADL alone, as elegant as it is, is not enough. It should be used with best practices to get good solutions depending on the context of use. Through the use of best practices, designers avoid reproducing well-known errors and follow a proven process. But the quality has a cost related to two aspects: the capitalization of these best practices and roll-backs in case of non compliance with them.

With our approach, quality assurance manager are able to dene, in a formal description, their own design practices based on books, standards and/or their own gained experience. Since these descriptions are formal, they become productive in tools. They can be automatically applied by designers in order to produce high quality architectures. Thus, we provide not only a way to capitalize best practices, but also a means to check their compliance throughout the design process to avoid costly roll-backs.

Our approach provides to architects, directly in editing tools, a collection of BPs. This automation relieves the architects of much of manual verications.

Consequently, they do not hesitate to activate them when needed. They can also choose the BPs to use, depending on the given context, their own skills and type of the project.

As a continuation of this work, we plan to provide a best practice management tool that allows the quality assurance manager to optimize BPs use. In addition of dening BPs, this tool should help to involve them in projects (process + human) with management of the access rights and the temporary permissions of violation. Finally, it must allow the generalization of individual BP to make them usable by all designers. This last point will enable the company to go up from the level of individual know-how to the level of collective know-how.

Fig.

  Fig. GooMod Meta-model

5 .

 5 Before leaving the step, the post-conditions are checked to ensure that the current model is in a valid state according to the BP rules. Leaving a step, several transitions are sometimes possible. These transitions are dened by the Binds whose tail is this step. A transition is possible only if the pre-condition of the head step of the concerned Bind is veried by the current state of the model. If several next steps are possible, this means that

Fig. 3 .

 3 Fig. 3. GooMod platform general architecture

Fig. 4 .

 4 Fig. 4. Process part of Alkante's BP for building Web applications architectural models

  Pre description : at least one page must be present context : Component inv : Component . allInstances () -> select (c: Component | c. stereotype = ' AlkHtmlPage ')-> notEmpty () Entry output (" You have to create at least one form per page . ") output (" Make sure to respect the graphical guidelines ." ) Concepts [{ " Component " ," cud "}, {" Port " ," cud " }] Exit input ( $response , boolean , " Did you respect the graphical guidelines ? ") Post description : each form must be contained in a parent page context : Component inv : Component . allInstances () -> select (c: Component | c. stereotype = ' AlkHtmlForm ')-> notEmpty () and Component . allInstances () -> select (c: Component | c. stereotype = ' AlkHtmlForm '). owner . stereotype = ' AlkHtmlPage ' and Component . allInstances () -> select (c: Component | c. stereotype = ' AlkHtmlPage ')-> forAll ( page | page . ownedForms -> size () >= 1) and OclQuery_graphicalCheck () = true

Fig. 5 .

 5 Fig. 5. Applying best practices in AlCoWeb-Builder 5.2 BP in Action When developers starts designing architecture models with AlCoWeb-Builder, they rst load the GooMod model dened by the QAM, and then launch the controlled editing process. The bottom of Fig. 5 shows the current state of the BP Activation tool: the current design step is Add Script (on the left), allowed editable concepts for this steps are Component and Port (in the middle), and the right part shows the next available steps. As we can see, the BP indicates that we have the choice to go back to the Add Page step, or to go ahead to the last step of the process to nish the design of the Web application.