Riad Belkhatir
email: riad.belkhatir@univ-nantes.fr

Mourad Oussalah
email: mourad.oussalah@univ-nantes.fr

Arnaud Viguier
email: arnaud.viguier@beotic.com

A model introducing SOAs quality attributes decomposition

Keywords: SOA, factor, criterion, metric I

Recently, service oriented architecture (SOA) has been popularized with the emergence of standards like Web services. Nevertheless, the shift to this architectural paradigm could potentially involve significant risks including projects abandonments. With this in mind, the question of evaluating SOA quality arose. The appearance of methods like ATAM or SAAM propelled software architecture evaluation to a standard stage for any paradigm. However, there still are a number of concerns that have been raised with these methods; in particular their cost in terms of time and money, essentially because of the hand-operated nature of the evaluations conducted. The model proposed in this paper for evaluating SOAs takes as a starting point the McCall model; it allows the whole architecture to be decomposed in three types of quality attributes (factor, criterion and metric).

INTRODUCTION

Architectural paradigms are design patterns for the structure and the interconnection between software systems [START_REF] Alencar | A formal architectural design patterns-based approach to software understanding[END_REF]. Their evolution is generally linked to the evolution of the technology.

An architectural paradigm defines groups of systems in terms of:  Model of structure.

 Component and connector vocabularies.

 Rules or constraints on relations between systems [START_REF] Garlan | An introduction to software architecture[END_REF].

We can distinguish a few architectural paradigms for distributed systems, and, among the most noteworthy ones, three have contributed to the evolution of the concerns. These are chronologically, object oriented architectures (OOA), component based architectures (CBA) and service oriented architectures (SOA).

First developers were quickly aware of code repetitions in applications and sought to define mechanisms limiting these repetitions. OOA is focused on this concern and its development is one of the achievements of this research. OOA provides great control of the reusability (reusing a system the same way or through a certain number of modifications) which paved the way to applications more and more complex and consequently to the identification of new limits in terms of granularity. These limits have led to the shift of the concerns towards the composability (combining in a sure way its architectural elements in order to build new systems or composite architectural elements). Correlatively, the software engineering community developed and introduced CBA to overcome this new challenge and thus, the CBA reinforces control of the composability and clearly formalizes the associated processes. By extension, this formalization establishes the base necessary to automation possibilities. At the same time, a part of the software community took the research in a new direction: the dynamism concern (developing applications able to adapt in a dynamic, automatic and autonomous ways their behaviors to answer the changing needs of requirements and contexts as well as possibilities of errors) as the predominant aspect. In short, SOA has been developed on the basis of the experience gained by objects and components, with a focalization from the outset on ways of improving the dynamism.

Service oriented architecture is a popular architectural paradigm aiming to model and to design distributed systems [START_REF] Kim | Modeling of distributes systems with SOA and MDA[END_REF]. SOA solutions were created to satisfy commercial objectives. This refers to a successful integration of existing systems, the creation of innovating services for customers and cost cutting while remaining competitive. For the purpose of making a system robust, it is necessary that its architecture can meet the functional requirements ("what a system is supposed to do"; defining specific behaviors or functions) and the nonfunctional ones ("what a system is supposed to be"; in other words, the quality attributes) [START_REF] Lero | Quality attributes and service oriented architectures[END_REF]. Furthermore, developing an SOA involves many risks, so much the complexity of this technology is notable (particularly for services orchestration). First and foremost among these, is the risk of not being able to answer favorably to expectations in terms of quality of services because quality attributes directly derive from business objectives. Multi-million dollar projects, undertaken by major enterprises (Ford, GSA) failed and were abandoned. As these risks are distributed through all the services, the question of evaluating SOA has recently arisen. It is essential to carry out the evaluation of the architecture relatively early in the software lifecycle to save time and money [START_REF] Bianco | Evaluating a service oriented architecture[END_REF]. This is to identify and correct remaining errors that might have occurred after the software design stage and, implicitly, to reduce subsequent risks. Lots of tools have been created to evaluate SOAs but none of them clearly demonstrated its effectiveness [START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF]. The model presented in this paper allows evaluating SOAs by combining the computerized approach and the human intervention. We first relate in the section 2 the state of the art and we present the model in the section 3. We relate the experimentation led by the lab team in the section 4 and we conclude the paper with a discussion comparing the past works and our model in the last section.

II. STATE OF THE ART

A. Related works on SOA Evaluation

There is something far more important with the SOA evaluation as it is the bond between business objectives and the system, insofar as evaluation makes it possible to assess quality attributes of services composing the system [START_REF] Lero | Quality attributes and service oriented architectures[END_REF].

The evaluation relates to:  Qualitative and quantitative approaches.

 Load prediction associated with evolutions.

 Theoretical limits of a given architecture.

From this perspective, tools and existing approaches have shown their limitations for SOA [START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF]. We are currently attending the development of a new generation of tools developed by industrialists in a hand-operated way. The scale of the task has brought the academic world to tackle these issues and to try to develop a more formal and generic approach than different existing methods (ATAM, SAAM [START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF]) to evaluate SOAs.

B. Evaluation Results

In concrete terms, SOA evaluations product a report which form and content vary depending on the method used. But, in general terms, the evaluation generates textual information and answers two types of questions [START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF].

1) Is the architecture adapted to the system for which it has been conceived?

2) Is there any other architecture more adapted to the system in question? _____ 1) It could be said that the architecture is adapted if it favorably responds to the three following points: a) The system is predictable and could answer to the quality requirements and to the security constraints of the specification b) Not all the quality properties of the system result directly from the architecture but a lot do; and for those that do, the architecture is deemed suitable if it makes it possible to instantiate the model taking into account these properties. c) The system could be established using the current resources: the staff, the budget, and the given time before the delivery. In other terms, the architecture is buildable.

This definition will open the way for all future systems and has obviously major consequences. If the sponsor of a system is not able to tell us which are the quality attributes to manage first, well, any architecture will give us the answer [START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF].

2) A part of SOA evaluation consists in capturing the quality attributes the architecture must handle and to prioritize the control of these attributes. If the list of the quality attributes (each of which is related to specific business objectives) is suitable in the sense that at least all the business objectives are indirectly considered, then, we can keep working with the same architecture. Otherwise, it is time to restart from the beginning and to work with a new architecture, more suitable for the system.

C. Measuring the Quality.

It has been suggested that software production is out of control because we cannot quantitatively measure it. As a matter of fact, Tom DeMarco (1986) stated that "you cannot control what you cannot measure" [START_REF] Demarco | Controlling software projects: management, measurement estimates[END_REF]. The measurement activity must have clear objectives and a whole set of sectors need to be measured separately to ensure the right management of the software.

1) McCall model

One of the models that have been published is the McCall model in 1977 decomposing quality attributes in three stages. This model led to the IEEE standard: ISO/IEC 9126. A certain number of attributes, called external (applicable to running software), are considered as key attributes for quality. We call them quality factors [START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF]. These attributes are decomposed in lower level attributes, the internal attributes (which do not rely on software execution), called quality criteria and each criterion is associated to a set of attributes directly measurable and which are called quality metrics.

D. From past works to our model.

Current methods of evaluation stop the quality attributes decomposition at the "quality factors step" and remain too vague when it comes to giving accurate measures to quality. These methods are not precise because they cannot go further in the decomposition and consequently they cannot be automated to the point of defining a finite value for each attribute. Our work differs from those existing insofar as we wish to obtain a precise quantitative measurement for each quality factor with our model.

III. THE MODEL PROPOSED

A. The model in more details.

The main idea of the process is to evaluate in three steps the whole architecture from every metric to the set of quality factors obtained after having previously identified the business objectives. Our work is based on the architect point of view and the attributes selected are the ones considered as the most relevant among all existing. The process consists in three principal stages corresponding each to a decomposition step of our quality attributes.

1)

We first identified relevant quality factors for our architecture:

a) the CBA is defined with reusability and composability [START_REF] Crnkovic | Component-based development process and component lifecycle[END_REF]. Basing on previous analysis, we define the SOA with the reusability, the composability and the dynamism. Moreover, there exist a hierarchical ranking propelling "dynamism" on top of SOA concerns, and this is precisely why we chose to especially focus deeply on this quality factor.

2) Then, we isolate the quality criteria defining them: a) We concentrated our work on technical criteria because we adopted the point of view of an architect that is itself a technical stakeholder. In this light, we identified six criteria common to each of our three factors. These technical criteria gather elements having significant impacts on global quality, from the development process to the system produced: the loose coupling (potential of dependences reduction between services), the explicit architecture (

paradigm ability to define clear architectural application views), the expressive power (potential of paradigm expression in terms of creation capacity and optionalities), the communication abstractions (paradigm capacity to abstract services functions communications), the upgradability (paradigm ability to make evolve its services), and the owner's responsibility (corresponds to the responsibilities sharing out between services providers and consumers).

3) And finally we define quality metrics composing each criterion in order to quantify them numerically: a) Our previous work allowed to conclude that the "loose coupling" criterion is of biggest importance for the quality factor "dynamism" [START_REF] Hock-Koon | Contribution à la compréhension et à la modélisation de la composition et du couplage faible de services dans les architectures orientées services[END_REF]. We found three quality metrics for the latter which must be considered for the last stage of our model (the semantic coupling: {high, low or non-predominant} based on the high-level description of a service defined by the architect, the syntactic coupling: {high, low} measures dependencies in terms of realization between abstract services and concrete services and the physical coupling: {,  and  with 0≤≤≤} focusing on the implementation of the service). These metrics shall make it possible to identify physical dependencies between concrete services.

B. Coefficients

Coefficients assigned to the factors will depend on the company needs. Our works led us to conclude that for SOA and the three factors we worked with, we would allocate a coefficient of '3' for the "dynamism" whereas we would affect the value '2' for the "reusability" and the "composability". With regards to the second step, our works led to list the six technical quality criteria chosen under three distinct levels of acceptance, α, β and γ at which we assign respectively the values '3, 2 and 1'; We allocated the "loose coupling", the "upgradability" and the "communication abstraction" with the value '3'. The coefficient '2' goes for the "owner's responsibility" and "explicit architecture" criteria and '1' for the "expressive power". And finally, the three metrics studied may be all assigned to the value '1' meaning that they are equally important for calculating the global coupling of SOAs. These coefficients will be used as a basis for the following section. They have been affected to quality attributes as an example; however, these latter have been chosen according to the principle of proportionality validated by the lab-team. We can select other impact coefficients providing that we keep the same proportionality between the quality-attributes considered.

IV. EXPERIMENTATION

For the experimentation, we tempted to quantitatively measure the key quality attributes discussed in the previous sections of this paper; notably, the quality factor "dynamism", the "loose coupling" criteria and the "physical, syntactic and semantic coupling" metrics. That being said, it is important to note that the SOAQE method must be reproduced for every quality factor identified after having analyzed the objectives of the company and the set of criteria and metrics belonging to that quality factor. Taking as a starting point an existing formula of the field of "Preliminary analysis of risks" (see formula 1.1) [START_REF] Mortureux | Preliminary risk analysis[END_REF] our works led to the identification of a mathematical formula (see formula 1.2) combining the three couplings studied: semantic, syntactic and physical.

NB: The simplified formula (see formula 1.1) usually used in the automotive industry, makes it possible to measure the default risk of a car component A is the Criticality of the car component, B is the Probability of occurrence of a failure on this component and C is the Probability of non-detection of this failure.

We associate this concept of risk with our vision of the coupling. Correlatively, the quintessence of the coupling is the expression of the dependences which can exist between two elements and the principle of dependence defines that one element cannot be used without the other. Reducing the risk that the role defined by a service cannot be assured anymore is decreasing the dependence of the application in relation to this service and thus reducing its coupling. The calculation of this risk takes into account all the characteristics influencing the coupling by redefining the three variables A, B and C according to the semantic, syntactic and physical couplings. The global coupling corresponds to the sum of the three couplings calculated individually beforehand. The lower this result is, the more the coupling is weak.

NB: The criticality A[(a),(b),(c)

] is affiliated to the semantic coupling. 'a' if the service is only associated to non predominant couplings, 'b' for non predominants and low couplings and 'c' for non predominants, low and high couplings, while 'Ps' is the probability of failure of a service. This generic coupling formula can directly be used to quantify the quality of the architecture by weighting up each of the attributes concerned by means of the coefficients isolated after having organized the attributes according to their importance. Indeed, as we already specified in section 2, we cannot automate this operation and define continuously the same coefficients for all the architectures considered because this operation is specific to the business objectives of the company. By applying to known quality attributes the coefficients determined in the section III.B, we obtain the following tree: Thus, according to the previous figure 2, we can establish that the quantitative measure of the quality of an SOA corresponds to the sum of the quality factors dynamism, reusability and composability, all three affected by their respective coefficients:

The following formula allows calculating the whole quality of an SOA.

NB: the lower the loose coupling result is, the more the coupling is weak. Conversely, the higher the architecture quality result is, the more the quality is good; the result of each criterion is expressed in percentage, this is why we subtract to 1 the result found.

For any architecture considered, we are able to determine a finite value for the loose coupling criteria, the remaining work consists in defining a way to calculate the five others criteria in order to isolate a finite value for the quality.

V. DISCUSSION

Because SOA implies the connectivity between several systems, commercial entities and technologies: some compromises regarding the architecture must be undertaken, and this, much more than for systems with a single application where technical difficulties prevail. Forasmuch as the decisions about SOA tend to be pervasive and, consequently, have a significant impact on the company; setting an evaluation of the architecture early in the life of the software is particularly crucial. During software architecture evaluations, we weigh the relevance of each problematic associated to the design after having evaluated the importance of each quality attribute requirement. The results obtained when evaluating software architectures with existing methods (ATAM, SAAM) are often very different and none of these latter carries out it accurately (for example, SAAM does not provide any clear quality metric for the architectural attributes analyzed [START_REF] Ionita | Scenario-based software architecture evaluation methods: an overview[END_REF]). We know the causes of this problem: most methods of analysis and automatic quality evaluation of software systems are carried out from the source code; whereas, with regard to evaluation cases of architectural models, the analysis is conducted based on the code generated from the model. From this code, there exist calculated metrics, more or less complex, associated with algorithms, methods, objects or relations between objects. From an architectural point of view, these techniques can be indicated of low level, and can be found out of step with projects based on new complex architectures. The finality of our work is to design a conceptual framework and, in fine, a semi-automated prototype called SOAQE (taking as a starting point, past methods such as ATAM or SAAM) which could quantify with an accurate value the quality of the whole service oriented architecture.

Figure 1 :

 1 Figure 1: Defaut risk of a car component (1.1) and global coupling of an architecture (1.2) formulas.

Figure 2 :

 2 Figure 2: SOA attributes tree weighted with means of coefficients


Riad Belkhatir
email: riad.belkhatir@univ-nantes.fr

Mourad Oussalah
email: mourad.oussalah@univ-nantes.fr

Arnaud Viguier
email: arnaud.viguier@beotic.com

SOAQE Service Oriented Architecture Quality Evaluation

Keywords: SOA, Quality, Evaluation, Attributes

This paper presents a semi-automated method for evaluating SOAs called SOAQE, correcting defects observed so far with existing methods such as lacks of pertinence and accuracy for evaluation results. SOAQE takes as a starting point the McCall model, describing software quality, which led to an international standard for the evaluation of software quality (ISO/IEC 2001). This model is organized around three types of quality attributes (factors, criteria and metrics). The SOAQE method consists in decomposing the whole architecture and evaluating it according to the McCall model, i.e. a list of quality factors arising from business needs grouping criteria composed by metrics. Our experimentations led us to quantify numerically a first determining factor for SOAs, the 'dynamism' and some attributes of its structure: namely the 'loose coupling' criterion and its constituent metrics ('physical, semantic and syntactic').

INTRODUCTION

We can distinguish a few architectural paradigms for distributed systems, and, among the most noteworthy ones, three have contributed to the evolution of the concerns. These are chronologically, object oriented architectures (OOA), component based architectures (CBA) and service oriented architectures (SOA).

First developers were quickly aware of code repetitions in applications and sought to define mechanisms limiting these repetitions. OOA is focused on this concern and its development is one of the achievements of this research. OOA provides great control of the reusability (reusing a system the same way or through a certain number of modifications) which paved the way to applications more and more complex and consequently to the identification of new limits in terms of granularity. These limits have led to the shift of the concerns towards the composability (combining in a sure way its architectural elements in order to build new systems or composite architectural elements). Correlatively, the software engineering community developed and introduced CBA to overcome this new challenge and thus, the CBA reinforces control of the composability and clearly formalizes the associated processes.

By extension, this

formalization establishes the base necessary to automation possibilities. At the same time, a part of the software community took the research in a new direction: the dynamism concern (developing applications able to adapt in a dynamic, automatic and autonomous ways their behaviors to answer the changing needs of requirements and contexts as well as possibilities of errors) as the predominant aspect.

In short, SOA has been developed on the basis of the experience gained by objects and components, with a focalization from the outset on ways of improving the dynamism.

The SOAQE method presented in the present paper allows evaluating SOA by combining the computerized approach and the human intervention to eliminate lacks identified with past methods such as ATAM, SAAM or ARID (Clements,Kazman and Kein, 2001). The main idea resides in automating the process to avoid time-wasting evaluations. The process consists in three principal stages detailed later in this paper. In the current paper, we first relate in the section 2 the interests of the evaluation, we analyze the existing works and we present the SOAQE method in the section 3; and finally we relate the experimentation which has been done by the lab team in the section 4. We conclude this paper with a conclusion about the perspectives of our work.

MEASURING THE QUALITY

The scientific community utilizes models of quality introducing what we call the software attributes decomposition. 2001). A certain number of attributes, called external (applicable to running software), are considered as key attributes for quality. We call them quality factors (Clements,Kazman and Kein, 2001). These attributes are decomposed in lower level attributes, the internal attributes (which do not rely on software execution), called quality criteria and each criterion is associated to a set of attributes directly measurable and which are called quality metrics.

Mc Call model

Lack of precision

Current methods of evaluation stop the quality attributes decomposition at the "quality factors step" and remain too vague when it comes to giving accurate measures to quality. These methods are not precise because they cannot go further in the decomposition and consequently they cannot be automated to the point of defining a finite value for each attribute. They lead inevitably to the establishment of a brainstorming between stakeholders (see section 3) for the purpose of the institution of a utility tree (SEI, 2010). Because stakeholders do not have tools to quantitatively measure each quality factor chosen, they shall set up scenarios aiming to respectively solicit separately each criterion, and factor. An approximated evaluation of the architecture is then realized after having studied the system behavior while carrying out the scenarios set.

SOAQE

It is precisely where our work differs from those existing insofar as we wish to obtain a precise quantitative measurement for each quality factor with the SOAQE method. We especially aim to automate the process in order to avoid hand-operated evaluations pushing to solicit stakeholders for the whole evaluation.

Principle of the method

The process consists in three principal stages corresponding each to a decomposition step of our quality attributes.We first identify relevant quality factors for our architecture.Then we isolate the quality criteria defining them.And finally we define quality metrics composing each criterion in order to quantify them numerically.

Steps in more detail

The main idea of the SOAQE process is to evaluate in three steps the whole architecture from every metric to the set of quality factors obtained after having previously identified the business objectives. Our work is based on the architect point of view and the attributes selected are the ones considered as the most relevant among all existing.

Quality factors

The CBA is defined with reusability and composability [START_REF] Crnkovic | Component-based development process and component lifecycle[END_REF]. Basing on previous analysis, we define the SOA with the Reusability, the Composability and the Dynamism.These three attributes, that we identified as quality factors for SOA represent the qualitative quintessence which has directed the definition of the object, component and service paradigms.

The first step of the SOAQE method consists in choosing a first quality factor to study in depth and there exist a lot which could come out after the analysis of the business objectives. But we have naturally chosen to work on those identified as the qualitative quintessence for SOA. These three quality attributes (dynamism, composability and reusability) define each of our three paradigms to varying degrees. Moreover, there exist a hierarchical ranking propelling "dynamism" on top of SOA concerns, and this is precisely why we chose to especially focus deeply on this quality factor. We may record that each of the two others attributes is of major importance for the three paradigms considered (object, component or service oriented architectures).

Quality criteria

With regards to our work and after having identified the determining factor quality for SOA (i.e. the dynamism), we were interested in the second step of the SOAQE method, namely, discovering the criteria defining the factor on which we have gone through.

Further down the road, any factor is composed by a set of criteria that could be looked at as part of our work. These criteria belong to different families of attributes and a few of them are common to the three quality factors chosen for our paper. But we deliberately concentrated our work on technical criteria of each of the quality factors studied because we adopted the point of view of an architect that is itself a technical stakeholder. In this light, we identified six criteria common to each of our three factors. These technical criteria gather elements having significant impacts on global quality, from the development process to the system produced: the loose coupling (potential of dependences reduction between services), the explicit architecture (paradigm ability to define clear architectural application views), the expressive power (potential of paradigm expression in terms of creation capacity and optionalities), the communication abstractions (paradigm capacity to abstract services functions communications), the upgradability (paradigm ability to make evolve its services), and the owner's responsibility (corresponds to the responsibilities sharing out between services providers and consumers). Each of these quality criteria is given varying degrees of consideration according to the quality factor in question. Our previous works (Hock-Koon, 2011) allowed organizing hierarchically (under three distinct levels) these quality criteria for each of the three quality factors (dynamism, reusability and composability).

Consequently, we obtain the triptych of the figure 2 while considering all paradigms. While focusing on the dynamism, our previous work (Hock-Koon, 2011) allowed to conclude that the "loose coupling" criterion is of biggest importance for this factor (see figure 2), this is why we chose to concentrate in depth, on it; whereas, the criterion "expressive power" is of less importance.

Quality metrics

The coupling is relatively well known by the community, and thus, our lab team members decided to look into the matter (Hock-Koon, 2011). We found three quality metrics for the latter which must be considered for the third step of the SOAQE method (the semantic coupling: {high, low or non-predominant} based on the high-level description of a service defined by the architect, the syntactic coupling: {high, low} measures dependencies in terms of realization between abstract services and concrete services and the physical coupling: {,  and  with 0≤≤≤} focusing on the implementation of the service). This implementation corresponds to a particular instance of the service where a choice has been made concerning concrete services to use. A unique solution has been chosen to fulfill each of the needs expressed by abstract services. It reuses existing researches [START_REF] Perepletchikov | Coupling metrics for predicting maintainability in service-oriented designs[END_REF] and it is based on measurements such as methods calls, messages exchanged, the number of linked services, commune objects and so forth. These metrics shall make it possible to identify physical dependencies between concrete services.

EXPERIMENTATION

For the experimentation, we tempted to quantitatively measure the key quality attributes discussed in the previous sections of this paper; notably, the quality factor "dynamism", the "loose coupling" criteria and the "physical, syntactic and semantic coupling" metrics. That being said, it is important to note that the SOAQE method must be reproduced for every quality factor identified after having analyzed the objectives of the company and the set of criteria and metrics belonging to that quality factor.

Loose coupling

Taking as a starting point an existing formula of the field of "Preliminary analysis of risks" (see formula 3.1) [START_REF] Mortureux | Preliminary risk analysis[END_REF] our works led to the identification of a mathematical formula (see formula 3.2) combining the three couplings studied: semantic, syntactic and physical.

NB: The simplified formula (see formula 3.1) usually used in the automotive industry, makes it possible to measure the default risk of a car component A is the Criticality of the car component, B is the Probability of occurrence of a failure on this component and C is the Probability of non-detection of this failure.

We associate this concept of risk with our vision of the coupling. Correlatively, the quintessence of the coupling is the expression of the dependences which can exist between two elements and the principle of dependence defines that one element cannot be used without the other. Reducing the risk that the role defined by a service cannot be assured anymore is decreasing the dependence of the application in relation to this service and thus reducing its coupling. The calculation of this risk takes into account all the characteristics influencing the coupling by redefining the three variables A, B and C according to the semantic, syntactic and physical couplings. The global coupling corresponds to the sum of the three couplings calculated individually beforehand. The lower this result is, the more the coupling is weak.

NB: The criticality A[(a),(b),(c)] is affiliated to the semantic coupling. 'a' if the service is only associated to non predominant couplings, 'b' for non predominants and low couplings and 'c' for non predominants, low and high couplings, while 'Ps' is the probability of failure of a service.

CONCLUSION

The finality of our work is to design a conceptual framework and, in fine, a semi-automated prototype (based on past methods, such as ATAM or SAAM) which could quantify with an accurate value the quality of the whole service oriented architecture. Another pursued goal consists in bringing to the customer "less abstract" documents than those proposed today. The quality concept remaining a relative one, we will target the sectors requiring a special attention by directly addressing the various development lab teams charged with the relevant functions.

  One of the models that have been published is the McCall model in 1977 (see figure 1) decomposing quality attributes in three stages. This model led to the IEEE standard: ISO/IEC 9126 (ISO/IEC 9126-1,

Figure 1 :

 1 Figure 1: Mc Call model applied to the "Maintainability".

Figure 2 :

 2 Figure 2: Expression of reusability, composability and dynamism perspectives.


Riad Belkhatir
email: riad.belkhatir@univ-nantes.fr

Mourad Oussalah
email: mourad.oussalah@univ-nantes.fr

Arnaud Viguier
email: arnaud.viguier@beotic.com

AN INDUSTRIAL CASE STUDY ON SOA QUALITY EVALUATION

Keywords: Software architecture paradigms, Service oriented architecture, Quality attributes

During these last years, Service Oriented Architecture (SOA) has known a meteoric rise and more and more companies are lured by this technology and its strengths (reusability, costs benefits and productivity increase) because of an improved control of the business expectations. This technology could bring a lot of benefits but there may also appear some major complications while disrupting the company organization to adopt it. First and foremost among these, is the risk of not being able to answer favourably to expectations in terms of quality of services. As these risks are distributed through all the services, the question of evaluating SOA has recently arisen. In this light, before adopting SOA, it is fundamental to evaluate the quality of the architecture to set up. This paper presents a tool enabling the assessment of a software oriented architecture based on a model called SOAQE allowing architecture decomposition with the aim of evaluating it easier. The SOAQE model, validated by the software engineering community, served as a basis for the elaboration of this new generation of tools returning results under textual and graphical forms for a better understanding of data.

INTRODUCTION

Recently, more and more companies focus on SOA solutions for developing their architecture. However, because of the complex nature of the financial issues that this technology involves, there exists a real need in assessing the coherence of the project and the quality of the architecture chosen. This would essentially allow:

(i) Controlling different costs.

(ii) Bringing much more credibility to the project.

(iii) Distinguishing itself from the competition.

(iv) Leading to certifications (standards).

(v) Preventing any future significant potential threat including project failures that such evolution could potentially lead to.

Moreover, increases in terms of software size make the development more complex to handle, and this same complexity makes any form of predictability or estimation (cost and quality) extremely difficult. There exists a need to first build a predictive model of quality. We propose in this article a new semi-automated method for evaluating SOAs, called SOAQE (for Service Oriented Architecture Quality Evaluation). This method considerably overcame shortcomings observed so far such as lacks of pertinence and accuracy. The McCall model, which describes software quality and led to the international standard for the evaluation of software quality, the ISO/IEC 9126-1:2001 [START_REF] Carvallo | Extending the ISO/IEC 9126-1 Quality Model with Non-Technical Factors for COTS Components Selection[END_REF] (which has recently been updated to the SQuaRE standard ISO/IEC 25010:2011 [START_REF] Suryn | ISO/IEC SQuaRE: The second generation of standards for software product quality[END_REF]) serves as a basis for our work. Correlatively, we work with a model that can be defined by a set of views and each view is divided in several factors, criteria and metrics. Our experimentations led us to implement a tool called the SOAQE tool (Flex Client/Java Server application), which, based on the SOAQE model, allows quantifying numerically the quality of the architectural point of view branch and all the attributes of its structure. We deal with some state of the art works in the next section then we present the case study from the BeOtic company in Section 3. Section 4 introduces the SOAQE tool which supports our model and Section 5 is devoted to the discussion. Finally, section 6 concludes this paper.

STATE OF THE ARTS WORKS

The software engineering community first developed methods such as GQM (Goal/Question/Metrics) [START_REF] Basili | The Goal Question Metric Approach[END_REF] consisting in a few steps:

1. Define goal of measurement 2. Devise suitable set of questions 3. Associate metric with every question.

The limits of such methods appeared quickly: the fact that the process cannot be automated because the different goals of measurement and the questions/metrics resulting from these goals are exclusively set by stakeholders (human intervention) distorts results because stakeholders are not able to cover all the possible requirements to evaluate the quality.

We have then seen emerge very similar methods like ATAM or SAAM [START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF] which propelled software architecture evaluation to a standard stage for any paradigm. However, several major concerns have been raised with these methods [START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF]; in particular their cost in terms of time (a lot of steps to perform the whole process) and money because of the hand operated nature of the evaluations conducted. And again, the major lack concerned the results of the evaluations supported with these methods: lots of deficiencies concerning the requirements of the architecture because the process is still not automated. The scale of the task has brought the academic world to tackle these issues and to try to develop a more formal and generic approach than different existing methods to evaluate SOAs [START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF]. New efforts to evaluate SOA are being undertaken in different aspects using different tools and methods like [START_REF] Magott | Evaluation of SOA security metricsusing attack graphs[END_REF] in which they applied attack graphs for SOA security metrics. But the majority of these kinds of researches are just a proposal or they are about some certain aspects of evaluation or using different techniques [START_REF] Cotroneo | Improving Dependability of Service Oriented Architectures for Pervasive Computing[END_REF] From a global perspective, current methods of evaluation are too vague when it comes to giving accurate measures to quality. Our work differs from those existing insofar as we wish to obtain a precise quantitative measurement for each quality factor with our model.

CASE STUDY

This section describes an extract of a case study of an existing BeOtic's project (http://www.beotic.com/). This case study has not a purpose of validating our method that we already explained in details in a past paper [START_REF] Belkhatir | A Model Introducing SOAs Quality Attributes Decomposition[END_REF] but illustrating it.

Requirements

For our case study, we collected data from an existing project of the BeOtic Company. These confidential data include code from the service oriented architecture of one of the clients of the company. More exactly, the company implemented its own tool called BeoMetric for collecting metrics from the code (LOC, CR, CCN...); functioning as JMetric (http://sourceforge.net/projects/jmetric) and we had the chance to gather XML files regrouping the values of the metrics considered for each method, class and package of the client project.

Method Use

One of our past works [START_REF] Belkhatir | A Model Introducing SOAs Quality Attributes Decomposition[END_REF] is dedicated to the realisation of the SOAQE model. In [START_REF] Belkhatir | A Model Introducing SOAs Quality Attributes Decomposition[END_REF], we consider that the architectural point of view of an SOA is composed by three main factors (dynamism, reusability and composability) affected by different coefficients according to their importance for SOA (see figure 1). Our first work prompted us to study closely the loose coupling criterion for which we defined its constituent metrics.

The aggregation of the values of these metrics allows obtaining a finite value for the loose coupling criterion (see figure 3). Therefore, we wish to incorporate to the SOAQE model, the metrics obtained after applying the BeoMetric module to the submitted architecture in order to get a final mark for the quality of the architecture.

The current state of our research works allows us to work exclusively on the path indicated with a blue circle on figure 3 (the loose coupling criterion).

Figure 3: SOA attributes tree weighted with means of coefficients

THE SOAQE TOOL

In this section, we present SOAQE Tool (Service Oriented Architecture Quality Evaluation Tool), a tool that supports our method.

Technical architecture

This prototype has been built in cooperation with the BeOtic company to be used as a service for its customers. The application takes as input XML files where are stocked the values of twenty-six metrics for each method, class and package of the architecture submitted. All these values are then stocked in a SQL database to facilitate data retrieving for the application. The server has been built using Java and the server and the database communicate together via the DAO technology. The client of the application has been implemented using Flex and communicates with the server using Blaze DS. Figure 4 describes the architecture of the SOAQE tool.

General Organization

The first step of the application consists in displaying in a data grid the set of metric values retrieved from the SQL database. According to the user's choice, these values can be displayed for the classes or the packages of the source code. This is to allow the user to compare the metrics desired for the evaluation before launching it. As show in figure 5, we implemented for the application a cube stack for the visualization of the results and improved ergonomics. In this light, the user can see, in addition to the data grid, the behavior of the metric values with the help of a scatter plot composed by three axes corresponding to the classes or packages that the user chooses for the comparison. We also implemented another module where, this time, the user can visualize the evolution of the metric values for each class in the architecture through colored curves (see figure 6). Before launching the evaluation of the architecture submitted, the user can set the tree view of the part of the architecture being evaluated (organised under points of view, factors, criteria and the metrics which has been displayed from the database in the previous phase). The structure of the arborescence is set with a panel under the form of a data grid where is first displayed a default tree corresponding to the most complete declination of the architecture for the architecture point of view we concluded in a past work [START_REF] Belkhatir | A Model Introducing SOAs Quality Attributes Decomposition[END_REF]. Nevertheless, we offered the possibility to the user to be totally free with his evaluation; this is why it is still possible:

(i) To modify the attributes selected in the default arborescence. (Because the graphics rendering of the results is not only textual, the BeOtic company asked us to not disclose any overview of the graphics rendering to avoid any potential leaks.)

DISCUSSION

Our proposition offers a new way of evaluating the quality of a service oriented architecture since the process is semi-automated and allows save time and money contrary to all existing works trying to evaluate the quality of an SOA [START_REF] Basili | The Goal Question Metric Approach[END_REF][START_REF] Clements | Evaluating Software Architectures: Methods and case studied[END_REF][START_REF] Magott | Evaluation of SOA security metricsusing attack graphs[END_REF][START_REF] Cotroneo | Improving Dependability of Service Oriented Architectures for Pervasive Computing[END_REF]. The model in which the tool is based has always been validated by the software engineering community [START_REF] Belkhatir | A Model Introducing SOAs Quality Attributes Decomposition[END_REF] and allows obtaining real, accurate and immediate results for the quality evaluation of the SOA. This tool has been implemented to avoid major project fails. Indeed, we can now know if it makes sens to swing towards SOA technology for the company involved and this is exactly where the BeOtic company has an interest in the project because the company is specialised in IT auditing and software distribution. Nevertheless, we worked on this project as architects and the work for the architectural point of view is not finished as there still are criteria which have not been decomposed in aggregations of metrics. So even if the tool works well and the results obtained are correct, it is still possible to bring new elements to the current work. This is why we chose to let the user free to modify the default arborescence proposed for new research results which are going to be revealed with future works. We first designed a work rather restricted but when the prototype considerably evolved, we added new functionalities to have the most configurable tool possible for the user.

CONCLUSION

In this paper, we present a model, the SOAQE model that allows splitting and evaluating the quality of a service oriented architecture. The method is based on two main steps:

(i) The division of the architecture into four levels of attributes (points of view, factors, criteria and metrics). (ii) The calculation of the quality mark.

The SOAQE tool has been implemented according to the SOAQE model [START_REF] Belkhatir | A Model Introducing SOAs Quality Attributes Decomposition[END_REF] in order to allow evaluating any SOA considered according to our method.

Further step concerns the deep study of new criteria for the architectural point of view. Correlatively, to obtain a model and a tool which can evaluate in a complete way the quality of any SOA, it is essential to be able to split the whole architecture in a combination of several attributes.

Another part of the perspectives concerns research on new points of views, we already started a bit with the business one.

Figure 1 :

 1 Figure 1: SOA interest pointsAnd each of these factors is composed by the same six criteria (Loose coupling, upgradability, communication abstraction, owner's responsibility, explicit architecture and expressive power) to which we allocate a different weight according to the factor considered (see figure2).

Figure 2 :

 2 Figure 2: Expression of reusability, composability and dynamism perspectives.

Figure 4 :

 4 Figure 4 : Architecture of the SOAQE tool.

Figure 5 :

 5 Figure 5 : Graphical visualisation of the metric values

Figure 6 :

 6 Figure 6: Curves module of the SOAQE tool.

  (ii) To add new attributes. (iii) To delete existing attributes It has been concluded in past works that only factors and criteria must have corresponding weights because the latter have not the same importance according to the point of view considered. The figure 7 is an overview of this control panel.

Figure 7 :

 7 Figure 7: Control PanelBy clicking on the save button, the new arborescence the user created is directly stocked in the SQL database for the next step of the application: the evaluation. Correlatively, the panel closes and a new "Launching the evaluation" button appears. This new operation consists in obtaining a finite value for the quality of the architecture submitted. (Because the graphics rendering of the results is not only textual, the BeOtic company asked us to not disclose any overview of the graphics rendering to avoid any potential leaks.)