El Mehdi Boujamaa

Boris Alandry

Souha Hacine

Laurent Latorre

Frederick Mailly

Pascal Nouet
email: nouet@lirmm.fr

A Low Power Interface Circuit for Resistive Sensors with Digital Offset Compensation

This paper presents an innovative conditioning and read-out interface for resistive MEMS sensors. The proposed structure includes a digital offset compensation for robustness to process and temperature variations. Simulation results demonstrate an impressive resolution to power consumption ratio and a good immunity to environmental parameters. Experimental results finally demonstrate the efficiency of this promising read-out architecture.

I. INTRODUCTION

Since resistive sensors exist, the Wheatstone bridge has been the most commonly used conditioning and read-out architecture [START_REF] Hébrard | A chopper Stabilized Biasing Circuit Suitable for Cascaded Wheatstone-Bridge-Like Sensors[END_REF]. Even with the development of MEMS in the last decade, the Wheatstone bridge remains the preferred solution to transpose a physical magnitude into the electrical domain as soon as a resistive transduction method is used. The Wheatstone bridge introduces a major issue for lowpower sensors, the dependence of resolution to power consumption [START_REF] Thanachayanont | Low-Voltage Current-sensing CMOS Interface Circuit for Piezo-Resistive Pressure Sensor[END_REF]. On the one hand, the smaller the resistance, the higher the current in the bridge is. On the other hand, the higher the resistance, the higher the noise floor is. Moreover, the output signal is directly proportional to the supply voltage. Finally, power consumption is the price to pay for high resolution in a Wheatstone bridge.

Low-power requirements, in mobile applications, are probably one of the main reasons to explain why capacitive transduction has been preferred for many MEMS [START_REF] Claes | Low-power interfacing for piezoresistive sensors[END_REF]. Indeed, even if the fabrication process is often more complex than for resistive sensors, the power consumption of capacitive transduction is far below the one of resistor-based sensors.

In order to extend the potential application of resistive MEMS, a power-efficient interface circuit is required. In this paper, we first study the limitations introduced by the Wheatstone bridge to the intrinsic performance of a bare resistive sensor. We, then, introduce the principle of the proposed "active bridge" as an efficient alternative that allows power consumption savings and optimum resolution. We also present a possible implementation of this low-power interface with an offset cancelation scheme to increase sensor robustness to temperature and process scatterings. Finally, experimental results on a demonstrator illustrate the versatility of the proposed solution.

II. PRINCIPLE OF THE "ACTIVE BRIDGE"

A. Wheatstone bridge versus bare sensor

Let us first consider a bare resistive sensor with two possible conditioning schemes: i) placing it in a Wheatstone bridge or, ii) biasing it with a current generator (Fig. 1). To compare the resolution of both solutions, one can study the signal to noise ratio (SNR). For simplicity, voltage ratios are used in this paper. First, resolution for the Wheatstone bridge writes [START_REF] Asch | Les Capteurs en Instrumentation Industrielle[END_REF]:

BW kTR 4 1 4 V R R SNR CC Wheat Δ = , ( 1
)
where k is the Boltzmann constant and BW the considered bandwidth. As previously mentioned, the resolution increases with the supply voltage and decreases with the resistance (even if ΔR/R is independent of R). If we now consider the direct biasing of the gauge with an ideal current source (I SA ), it comes:

BW kTR 4 I R R R SNR SA SA SA SA SA SA × Δ = . (2)
Now, the resolution increases with the resistance and, for the same gauge (ΔR/R=ΔR SA /R SA ), a better resolution is achieved if R SA ×I SA >V CC /4 [START_REF] Claes | A 40uA/Channel Compensated 18-Channel Strain Gauge Measurement System for Stress Monitoring in Dental Implants[END_REF]. In order to compare deeply both resolutions, we substitute R SA , in [START_REF] Thanachayanont | Low-Voltage Current-sensing CMOS Interface Circuit for Piezo-Resistive Pressure Sensor[END_REF], by the ratio V SA /I SA . Similarly, V CC /I substitutes R in (1), I being the total current in the bridge. Finally, the ratio of SNR SA to SNR Wheat writes:

I I V V 4 SNR SNR SA CC SA Wheat SA = . ( 3
)
From (3), it is obvious that the stand-alone resistance configuration can produce significant performance improvements. Assuming V SA =V CC /2 and the same current consumption, the stand-alone resistor resolution (i.e. SNR) 978-1-4244-5309-2/10/$26.00 ©2010 IEEE Figure 4. SNR of the active bridge compared to both "ideal" and standard solutions as a function of the current consumption.

I LOAD R BRIDGE v OUT T 1 V CC g m .v GS R LOAD R BRIDGE ΔR.I LOAD r 0 v OUT v GS

ACTIVE BRIDGE (N-MOS CHARGE)

TOTAL BIASING CURRENT (A)

STAND ALONE RESISTANCE SNR (V/V) (BW=20KHZ-25KHZ) WHEATSTONE BRIDGE +LNA ACTIVE BRIDGE (CASCODE CHARGE)
ppm 10 R R = Δ STAND ALONE RESISTANCE STAND ALONE RESISTANCE + LNA WHEATSTONE BRIDGE SNR (V/V) (BW=20KHZ-25KHZ) WHEATSTONE BRIDGE +LNA 10 2
10 1 10 0 10 -5 10 -4 10 -3

will be 2√2 higher than the Wheatstone bridge one. For same resolutions, the stand-alone sensor will consume 8 times less current than a Wheatstone bridge.

Electrical simulations (Fig. 2) are reported for a 10 ppm relative variation of the resistance (ΔR/R) in case of a resonant sensor (20kHz < BW < 25kHz). For each biasing current, we use R = 2.R SA to keep V SA equal to V CC /2, which corresponds to the voltage drop across a resistance in the Wheatstone bridge. This simulation setup will be used along this paper in a 0.35µm CMOS technology.

Results confirm what we expected from (3), and the stand-alone resistance leads to a better resolution for a given power consumption or a lower power consumption for a given resolution. However, let us note that this intrinsic resolution is somewhat unachievable as it may correspond to a very low output signal that depends only on the supply voltage (e.g. 8.25mV/% for 3.3V). Additional amplification is thus required and increases the power consumption. For reference purposes, we assume that 200µA are necessary to amplify the intrinsic signal without notable noise degradation and two additional curves are reported (Fig. 2). As a partial conclusion, a good readout interface is then a circuit that would give rise to a SNR curve located between the standard solution one (Wheatstone bridge + LNA) and the ideal case one (Standalone resistance).

B. The "Active Bridge"

The low-power detection of a small resistance variation without noise and power degradation is the challenge that we are addressing with the active bridge. The seed idea is to compensate the dissipative behavior of resistors by using the same current to bias the resistor and to amplify the small output signal.

The proposed circuitry relies on a common gate arrangement of a MOS transistor (T 1 in Fig. 3.a). If the transistor is saturated, it will amplify a small variation of the sensing resistance through a modulation of the gate-source voltage (V GS1 ). Indeed, a small increase of R BRIDGE will induce a reduction of V GS1 and thus a far more important increase of the drain-source voltage of T 1 to keep the drain-source current constant. Therefore, a small variation of the voltage drop across the sensor translates in a larger variation of the output voltage.

In order to determine the output signal, we use a small signal analysis in which a small variation of the gauge will induce an input voltage (ΔR.I LOAD ) representing the variation of the voltage drop across the resistance. The obtained model (Fig. 3.b) leads to the following small signal output voltage:

( )

LOAD BRIDGE LOAD BRIDGE m 0 LOAD 0 LOAD m OUT I . R R R R g 1 r R r R g v Δ + + + + = , ( 4 )
where R LOAD is the output resistance of the current source I LOAD . There are different ways to implement the current source of the active bridge. The most adequate is a cascodelike current source that increases R LOAD and reduces the noise impact of the current source [START_REF] Boujamaa | An Innovative, Offset Immune, Conditioning and Read-out Circuitry for Resistive MEMS Sensors[END_REF]. Simulation results (Fig. 4) illustrate the SNR improvement due to the cascode current source (diamonds) with respect to the implementation of I LOAD with a simple N-MOS transistor. For large value of R LOAD , the intrinsic signal (ΔR.I LOAD ) may be amplified sufficiently to avoid the use (and the consumption) of an additional amplifier. As an example, if we consider R LOAD >> r 0 , a gain of several hundred could be reached thus leading to sensitivity higher than 1 V/%. At this point, we have demonstrated that the "active bridge" concept is an efficient interface for a resistive sensor. In the next section, we will study the robustness of such a device with respect to process variability and ambient temperature. + -

V CC T 1 T 2 T 3 T 4 R NI R BRIDGE R NI Comparator V REF CONTROL BLOCK R CAL R CAL R CAL CK v OUT S 0 S 1 S n R NI

III. ROBUSTNESS OF THE "ACTIVE BRIDGE"

The main interest of using a Wheatstone bridge is its immunity to environmental disturbances. This is due to its differential topology that rejects effects of global variations such as temperature or supply voltage. Due to its large sensitivity, the simple structure (Fig. 3.a) saturates as soon as a temperature variation occurs. Hence, in order to merge, the "active bridge" benefits and the Wheatstone bridge robustness, we propose to extrapolate the "active bridge" to a differential topology. One possible implementation, out of numerous variants [START_REF] Boujamaa | Circuit d'Amplification d'un Signal Représentant un variation de Résistance d'une Résistance Variable et Capteur Correspondant[END_REF], is presented in this paper (Fig. 5). This version is self-biased and does not require any reference voltage or external stages thus keeping the power consumption and the silicon cost very low.

Electrical simulations (Fig. 6) of the proposed differential architecture demonstrate that, unlike for the simple bridge, the sensitivity drift is very small. Over a wide range of temperature (160°C), the sensitivity reduces from 1.66 V/% down to 1.5 V/%. This corresponds to a change in sensitivity of less than 0.07%/°C. Another robustness issue comes when considering process-induced offset. Due to the huge sensitivity of the structure, even a very low mismatch between identically designed devices will bring the output voltage to deviate from the calculated bias point. That is the reason why openloop operation of such a device is not possible. We have then studied several offset cancelation scheme. The one presented here (Fig. 7) uses a digitally controlled feedback trimmer.

The later implements a resistance ladder to balance the differential "active bridge". A set of switches configure properly the ladder when a clock signal is applied to a digital control block featuring a voltage comparator as input stage. It is worth noting that the comparator and its reference voltage is a conceptual view and that the digital input of the control block will be designed to reduce extra power consumption.

Assuming 1% of mismatch between identically designed resistances, the value of R CAL is set one thousand times smaller than R BRIDGE (=R NI ). The number of elements in the ladder can be freely chosen with a direct impact on the output quiescent voltage resolution but with a minor impact on power consumption and size.

To validate the proposed offset cancellation scheme, we have performed Monte-Carlo simulations using both process (wafer to wafer) and mismatch (intra die) variations. In this worst case, immunity to process variation is clearly established (Fig. 8).

IV. EXPERIMENTAL RESULTS

A first demonstrator has been designed and fabricated for the conditioning and reading of a resonant earth magnetic field sensor [START_REF] Dumas | Design of a low-cost piezoresistive compass on CMOS[END_REF]. The circuit was manufactured in a 0.35µm technology from AMS and the post-process to release MEMS structures has been arranged by CMP (Fig. 9). This first prototype allowed the validation of the differential active bridge for all previously reported aspects. We also observed the ability of simulation to predict the silicon results. For this first « monolithic » demonstrator, the supply voltage was the only-possible input apart from the physical magnitude to be measured. For shortness, we report in this paper only the variation of the sensitivity as a function of the power supply voltage (Fig. 10). A similar behavior has been obtained when studying the bias current variation with supply voltage. The wide range of operation, the predictability of dependence and the efficiency of the structure are obvious.

In this prototype, a single 4kΩ strain gauge was arranged in a differential active bridge together with three reference resistors (as in Fig. 7). Under a supply voltage (V CC ) of 2V, a power consumption of about 300µW is sufficient to obtain an output signal close to 1V for a 1% variation of the resistive gauge. The same gauge in a Wheatstone bridge would deliver a 5 mV output signal with a 1mW power consumption. However, dependency of the sensitivity with the supply voltage is a real issue in terms of calibration and/or power supply rejection ratio. This point may be tackled by biasing the structure with a current rather than a voltage.

The stability with temperature and thus the variations of the sensitivity with temperature has not been yet characterized. With a second prototype not illustrated in this paper, we have also verified that an active bridge may adapt to a wide range of resistance at a price of a varying sensitivity. Indeed, when increasing the value of the gauge for a given structure, the bias current reduces and the output signal follows.

V. CONCLUSION

In this paper, we presented an innovative interface circuit suitable to all kind of resistive sensors. Based on "level 1" modeling, electrical simulations and experimental results, we illustrated several of the key features of the structure that are recalled as a conclusion:

• Robust to temperature and process variations,

• Easy to scale to any resistive sensor,

• Low-power operation,

• Maximal resolution (very small SNR degradation compared to bare sensor).

Works in progress concern the study of closed loop operation in order to adapt the digital feedback and to obtain a low-power resistive sensor interface with digital output.

Figure 1 .

 1 Figure 1. Resistive sensor conditionning and reading: in a Wheatstone bridge (left) or as a stand-alone resistor (right).

Figure 3 .

 3 Figure 3. "Active bridge" principle (a) and its small-signal model (b).

Figure 2 .

 2 Figure 2. SNR as a function of the current consumption for various conditioning and reading schemes. TOTAL BIASING CURRENT (A)

Figure 5 .Figure 6 .

 56 Figure 5. Differential architecture of the "active bridge".

Figure 8 .

 8 Figure 8. Effect of the offset cancelation structure on the bias point (output voltage, top) and on the sensitivity (bottom).

Figure 7 .

 7 Figure 7. Differential "active bridge" with offset cancelation feedback.

Figure 10 .

 10 Figure 10. Differential Active bridge sensitivity as a funtion of the supply voltage.

Figure 9 .

 9 Figure 9. Layout (a) and photograph (b) of an all-in-one earth magnetic field sensor with differential active bridge conditionning and reading.


Alessio Botta
email: a.botta@unina.it

Antonio Pescapé
email: pescape@unina.it

Giorgio Ventre
email: giorgio@unina.it

Ernst Biersack
email: ernst.biersack@eurecom.fr

Stefan Rugel
email: stefan.rugel@o2.com

Performance footprints of heavy-users in 3G networks via empirical measurement

Cellular technology is widely used for Internet access, also because most operators are now offering Mbit/s data rates at affordable prices. Many studies analyzed the performance of these networks using analytical or simulation approaches. However, due to lack of data from operational environments, very little is known about the performance of real cellular networks. In this paper, we assess the performance of the 3G network of one of the major European telecom operators, using several recent traffic traces of TCP connections to port 80 and 8080. After presenting performance statistics related to all the network users, we focus on heavy users. To assess their performance and to uncover the related causes, we introduce an investigation approach easily repeatable in the very common situation where only data traces are available, with no other information such as mapping of users to cells, network capacity, or packet payload. Analyzing both "single long-lived connections" and "multiple long-lived connections", we assess the performance of those users, providing insights on how and why performance can vary significantly over time and among different users.

I. INTRODUCTION

While cellular networks were originally used to carry voice calls only, they have progressively evolved to providing other services such as SMS, games, instant messaging, or Internet access, which is the focus of this paper. Over the last decade, the data rates achievable for Internet access via the cellular network have increased from a few tens of Kbps using GSM to about one hundred Kbps for GPRS, then several hundred Kbps with basic UMTS, and finally today, several Mbps with the High Speed Downlink Packet Access (HDSPA) that is part of the latest UMTS releases [START_REF] Halepovic | Wireless data traffic: a decade of change[END_REF]. Recently, many cell phone operators have proposed flat fee subscription models that allow to transfer tens of Gigabits per month. As a result, Internet access through cellular networks is nowadays very common.

Despite this growth, while there exist theoretical and simulation studies of the performance of cellular networks, very little is known about the real performance of operational cellular networks. In this paper, we perform a deep experimental campaign, aimed at understanding the performance of the users of the cellular network of one of the major European operators, using technologies that range from GSM to HSDPA. In our 0 The research leading to these results has received partial funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n. 224263-OneLab2 and from the project LATINO of the FARO programme financed by the Compagnia di San Paolo and by the Polo delle Scienze e delle Tecnologie of the University of Napoli Federico II. case, the only available input for the analysis are recentlycollected packet traces (headers only for privacy reasons) of TCP connections to port 80 and 8080, with no additional information such as mapping of users to cells or to technology (GPRS, UMTS, ...), information about the load of a cell, etc. We also do not know which applications the users are running. However, our situation is quite common as (i) it is very difficult to collect all this additional information and (ii) even if possible, this may violate the privacy to individual users. To cope with such situations, we develop an approach that is able to spot the performance of such users and to uncover its cause, using only packet headers. In contrast with other approaches in literature [START_REF] Siekkinen | A root cause analysis toolkit for TCP[END_REF], ours does not rely on the estimation of the path capacity, being able to work also on cellular networks where accurate capacity estimations are difficult. In agreement with the literature [START_REF] Estan | New directions in traffic measurement and accounting: Focusing on the elephants, ignoring the mice[END_REF], our approach focuses on the "heavy users", and it provides precise indications about which TCP connections to analyze, how to analyze a TCP connection, and finally which metrics to use in the analysis. Before focusing on heavy users, we provide insights on global statistics, regarding all the users of the network. Then, we focus on individual long lived TCP connections and, in particular, these parts of a connection where the application always provides sufficient data to the TCP sender: we study the performance of the so called Bulk Transfer Periods or BTPs for short [START_REF] Siekkinen | A root cause analysis toolkit for TCP[END_REF]. This analysis provides interesting insights about the performance of a first class of heavy users, for which the performance are dominated by the network conditions. We finally look at all the connections of a client and its aggregate performance in terms of throughput, loss rate, and number of parallel connections, in order to understand the effect of multiple simultaneous connections of the same user. Such analysis allows to understand the performance of another class of heavy users, for which the performance are dominated by the interference between concurrent connections.

The approach proposed in this paper is easily repeatable in other real network scenarios. Applying it to packet traces recently collected on a cellular network provides a snapshot on the performance of heavy users in those scenarios and on the cause of such performance.

II. RELATED WORK

The scientific literature on cellular networks is very broad and covers diverse aspects. In the following we only discuss work that is relevant or related to our paper. Already the introduction of GPRS, the first standard based on packet switching, give raise to a number of studies: A representative example is [START_REF] Benko | A large-scale, passive analysis of end-to-end TCP performance over GPRS[END_REF], that presents a large-scale analysis of the performance of TCP on such network. The authors performed an extensive measurement campaign over different networks and obtained results in terms of available data rate, RTT, and loss. In this paper we also consider more recent access technologies such as UMTS. UMTS has been already studied in literature using theory, simulation, and experimental approaches [START_REF] Botta | Quality of service statistics over heterogeneous networks: Analysis and applications[END_REF]. In [START_REF] Assaad | TCP Performance over UMTS-HSDPA Systems[END_REF], a detailed analysis of the nominal performance of such networks is presented. The results are directly derived from the standards, with no information related to real deployments. On the other hand, the works [START_REF] Cano-García | Experimental Analysis and Characterization of Packet Delay in UMTS Networks[END_REF], [START_REF] Vacirca | Large-Scale RTT Measurements from an Operational UMTS/GPRS Network[END_REF] analyze real cellular networks using passive and active measurement approaches respectively. The performance indicators reported in [START_REF] Vacirca | Large-Scale RTT Measurements from an Operational UMTS/GPRS Network[END_REF] are aggregated over the entire UMTS network, which does not allow to determine what performance a single user experiences in a such heterogeneous scenario. On the other hand, the work in [START_REF] Cano-García | Experimental Analysis and Characterization of Packet Delay in UMTS Networks[END_REF] is mainly aimed at modeling the UMTS network in terms of delay behavior. With respect to both these papers, we also present results related to HSDPA, which has been studied in some recent papers [START_REF] Ishii | Experiments on HSDPA Throughput Performance in W-CDMA Systems[END_REF], [START_REF] Jurvansuu | HSDPA Performance in Live Networks[END_REF]. The former work presents experiments conducted on different testbeds, in order to infer the throughput of HSDPA in different configurations. The latter, instead, presents an analysis of some performance parameters conducted by using an active measurement approach on an operational network.

To the best of our knowledge, our work extends the results in literature in that: (i) it uses real traffic traces from an operational network; (ii) it is conducted on a network containing a mix of access technologies (GSM, GPRS, EDGE, UMTS, and UMTS+HSDPA), which therefore provides a unique heterogeneous network scenario; (iii) it proposes an approach easily repeatable and extensible in the very common situation in which only packet traces are available; (iv) it shows results in terms of global performance statistics and performance of "heavy-users", providing useful insights for understanding 3G networks performance, and presenting both the performance experienced by users and its causes.

III. NETWORK AND TRACES

For our study, we use packet traces collected from an operational cellular network, whose design is depicted in Fig. 1. The cellular network is organized in a hierarchical fashion and comprises different kinds of radio access technologies: GSM, GPRS, EDGE, UMTS, and UMTS+HSDPA that reflect the evolution from 2nd and 3rd generation 1 . Such network employs a Performance Enhancing Proxy [START_REF] Rugel | On the performance of optimization proxies for data services in mobile networks[END_REF] or PEP for short, which is located between the GGSN and the Internet. The PEP operates as a transparent proxy for all TCP connections on port 80 and 8080 that are established by a mobile user: it terminates the TCP connections of the mobile users and opens new connections towards the Internet, while preserving the source and destination IP address and port information. The PEP was originally deployed to improve the download performance of 2G users in case of HTTP traffic. Multiple connections improve performance in case of interactive sessions where the idle period of one session may overlap with the busy period of another session. The PEP opens multiple parallel TCP connections towards a mobile user to transmit the data coming from an HTTP server in the Internet. The PEP tries to open many parallel connections when processing an HTML page requested, in order to overcome the restrictions imposed by HTTP 1.1 to open no more than two parallel connections [START_REF] Rugel | On the performance of optimization proxies for data services in mobile networks[END_REF].

Our packet traces (see Table I for the details) are collected at both sides of the PEP, as shown in Fig. 1, we will refer to them as Cellular and Internet sides in the following. The existence of the PEP and the fact that the traces are captured at both sides of the PEP facilitate the analysis because we can compute metrics such as loss rate or throughput separately for the cellular network and the Internet. However, the PEP is only receiving traffic of TCP connections destined towards port 80 or 8080, which means that we miss some traffic. We could confirm with the network operator that the vast majority of the traffic is indeed destined to these two ports: in another trace from the same network operator that was not captured at the PEP, 82% of total Bytes and 87% of total connections were destined towards port 80 or 8080. It is important to note that in all the available traces we found that a small quantity of connections (i.e. 10%) are responsible for the most part of the traffic (i.e. 90%). Therefore, when in the following sections we concentrate on heavy users, we are actually analyzing the most part of the traffic in the trace.

IV. GLOBAL STATISTICS

Table II reports some important statistics related to the trace Cellular1. Similar considerations apply for the other cellular trace. Firstly, we observe that the ratio between the number of packets sent and received by the mobile stations is about 10%, while the same ratio in Bytes is about 5%. Moreover, we notice that, in the downlink direction (i.e. from the Internet to the mobile stations) the largest connection is responsible for about 250 MBytes of traffic, the 7.5% of the total. While, in the uplink direction, the largest connection is responsible for about 7 MBytes, the 4.4% of the total. The top plot of Fig. 2 shows the cumulative distribution function (CDF) of the number of bytes per connection, in both the uplink and downlink directions. We can see that, in both cases, a small number of users is responsible for the most part of the traffic, i.e. the distributions are left skewed. Moreover, we observe that most of the connections in the uplink directions generate between 0.5 and 10 KBytes. While much more variation is observed in the other direction. In Table II we also report the average RTT and the total number of retransmissions. The value of the former parameter is 683 ms, which is very high compared to the Internet [START_REF] Jiang | Passive estimation of tcp round-trip times[END_REF]. Indeed, in the bottom plot of Fig. 2 we report the CDF of the average RTT per connection for both the traces Cellular1 and Internet1. As we can see, on the cellular side, the values range from 50ms to 5s, with 50% of the connections having an average RTT value larger than 400ms. While on the Internet side, 80% of the connections have an average RTT lower than 100ms. This indicates that (i) on average RTT are very high, and (ii) there is a high level of heterogeneity in the user performance. This means that looking only at aggregate statistics does not allow to derive any strong conclusion about the performance of the users.

As for the retransmissions, summing the values of the last two rows of Table II (i.e. those due to timeout expiration and fast retransmit mechanism) we obtain that about the 2.7% of packets from servers to clients are retransmitted. Again, this value is much higher than that on a typical Internet link [START_REF] Sommers | Improving accuracy in end-to-end packet loss measurement[END_REF], [START_REF] Wang | Queen: Estimating Packet Loss Rate between Arbitrary Internet Hosts[END_REF]. Moreover, we observe that there are much more retransmissions due to timeout expiration than due to fast retransmit.Such high number of retransmissions, together with the high RTT value, can cause very poor TCP performance. However, this behavior is not common to all the users (i.e. there is a lot of variation), and some of them are able to achieve very high performance. Recall that, like in most of the cellular networks currently deployed, we are observing a mix of different cellular technologies (GSM, GPRS, EDGE, UMTS, and UMTS+HSDPA). This means that, when analyzing the performance of modern cellular networks, we have to be very careful in selecting homogeneous sets of users (e.g. UMTS users) before making any conclusion about the real performance of a certain technology. In Fig. 3 we can observe the scatter plot of throughput and retransmissions of the connections from trace Cellular1 that transfer more than 100 data packets. In such figure we also highlight the connections with more than 300 data packets (represented with a solid circle). Moreover, we report with different colors the connections whose throughputs fall in different ranges. The rightmost group is related to the connections achieving a throughput >384Kbps, which are using the HSDPA. The connections in the other group can be using all the access technologies. As we can see, they experiment a very small number of retransmissions, and they usually transfer more than 300 data packets. This can be an indication of a behavior that has also been observed on the Internet: the more bandwidth is available to the users, the more they download from the network [START_REF] Zhang | On the characteristics and origins of internet flow rates[END_REF]. The connections from the other group are instead characterized by a lower throughput, higher retransmissions, and smaller number of packets (i.e. more circles are not solid). It is also worth underlining that, while in Fig. 3 we observe a maximum throughput of less than 2 Mbps, some users are able to get more than that by using multiple connections, as shown in the following. Finally, similarly to what observed from previous figures, Fig. 3 shows a high heterogeneous scenario. In such situation is very difficult to understand why some users are experimenting very high losses and others are not. To answer this question, we have to focus on the traffic of individual users, as shown in the following section.

Summarizing, from the global analysis we (i) can derive the order of magnitude of relevant parameters, and we have learned that: (ii) current cellular networks are characterized by a high degree of heterogeneity in terms performance; (iii) the average values of some performance indicators such as throughput, RTT, and retransmissions can easily be one order of magnitude higher than those observed on the Internet.

V. AN APPROACH FOR ANALYZING THE PERFORMANCE OF HEAVY-USERS

Our approach defines (i) how to select the TCP connections to analyze; (ii) how to analyze the selected TCP connections; and finally (iii) which metrics to use in the analysis. The approach requires only packet headers -the only information typically available to the researcher -and provides information about the performance of heavy users, and the related cause. It can therefore be easily utilized by other researchers in similar situations.

A. Which connections to analyze?

We concentrate on "heavy users" and we look at their "downstream" (towards the end-user) traffic captured at the cellular side. In this way, we analyze the most part of the traffic (see Section III), consistently to other approaches in literature [START_REF] Estan | New directions in traffic measurement and accounting: Focusing on the elephants, ignoring the mice[END_REF]. We only look at long TCP connections and exclude short connections whose performance metrics tend to be influenced by the dynamics of TCP slow start and they are therefore difficult to understand.We proceed in two steps:

• Among the heavy users are some who download most of the data in a single long lived connection. We refer to users with this profile as HU-one, for heavy users with non-parallel connections. We compute the throughput and loss rate for such long lived connections. Any performance problem observed would be due to the state of network (congestion) since we have only one connection.

• We then look at another set of heavy users that have a large number of long TCP connections. We refer to users with this profile as HU-many, for heavy user with many parallel connections. Also for them, we first analyze every connection in isolation. But in contrast with the previous ones, we then look at the evolution of the different performance metrics over time for each end user, in order to be able to check for "interference" among the different connections of the same end user, and to understand its impact on the performance metrics considered.

B. How to analyze a TCP connection?

From previous research [START_REF] Siekkinen | A root cause analysis toolkit for TCP[END_REF] we know that an application may not always have data to send, which means that in the lifetime of a TCP connection, periods of data transfer may alternate with periods of idleness. If we want to learn something about the performance experienced by the users, we should focus on the periods of data transfer, referred to as Bulk Transfer Periods (BTPs) and ignore the idle periods referred to as Application Limited Periods (ALPs) . In our analysis we first partition each TCP connection in ALPs and BTPs, and compute in a first step the metrics of interest only for the BTPs. In a second step, and for some users only, we also look at all their connections in order to check for possible self-inflicted interference. As shown in Fig. 4, a BTP can be seen as a sequence of packets whose size is usually equal to the Maximum Segment Size (MSS) and whose inter-packet time is usually shorter than the RTT. Note that the BTPs contain a major part of the total traffic: In our trace, all the BTPs account for about 67% of all Bytes, but only about the 1% of all connections have a BTP, since a BTP comprises at least 100 packets.

C. Which metrics to analyze?

To evaluate the performance and state of the network, we use the following metrics2 :

• Retransmission score is calculated by using the Sequence Number field (SeqNum) from the TCP header and the Identification field (ID) from the IP header: a packet is considered to be a retransmission if its ending sequence number (i.e. SeqNum plus payload size) is smaller than the current maximum, while its ID is larger than the current maximum. The retransmission score represents the ratio between the amount of retransmitted bytes and the total amount of transmitted bytes and measures the loss experienced by a connection3 .

• Throughput is simply calculated by dividing the total amount of bytes transmitted in a given interval by the duration of the interval.

• Number of parallel connections: we first compute the starting and ending time of each connection and then count the number of connections that overlap in each time interval.

VI. STATISTICS OF HEAVY-USERS

A. HU-one users

As we have found in our traces more users with the same profile, here -for space reasons and without affecting the generalization -we focus on three HU-one users. Looking at Table III, we can see that within a single connection, these users are transmitting huge amounts of data in the order of tens to hundreds of Megabytes. We have performed a reverse DNS lookup on the IP addresses of the three servers that are at the origin of the data transfers and found that in two cases the server is part of a Content Distribution Network or a streaming service and in the third case it is part of Social Network site. In all three cases, we ascribe the data transfer to streaming applications. The two most important parameters are throughput and retransmission score:

• Throughput: Pink is able to achieve with a single TCP connection more than 1 Mbit/s throughput, which is only possible with HSDPA; the other two users achieve a much lower throughput of 100 and 370 Kbit/sec respectively;

• Retransmission score: Both, pink and aqua have very low retransmission scores (less then 1%) meaning that they obtain a very good service from the network. For silver the retransmission score is one order of magnitude larger (around 5%) which is considerable. Since silver has no other connections, the loss seen by this user can only be caused by the state of the network that is most likely congested somewhere. For HU-one user we have seen how the performance are influenced by the network. In the next section we will see how the performance of HU-many users are self-influenced.

B. HU-many users

We now look at users that have many BTPs and also have often many connections open and active simultaneously. The analysis of the performance of such users is complicated by the presence of the parallel connections, and we will have to deepen the observation level different times in order to identify the cause of these performance. Table IV contains information about the BTPs of three HU-many users. We have found and analysed a much larger set of HU-many users. However, for space reasons we limit the presentation to the top three. If we compare the results for the three users, we find some interesting features:

• Maximum throughput: both, Red and Yellow, can achieve a throughput of several Mbit/sec, which is only offered by HSDPA; on the other hand, Green never achieves more than a few hundred Kbit/s. • Maximum retransmission score: Red and Green both see loss rates that can be as high as 17% -20%, while Yellow experiences consistently low loss rates that never surpass 2.5%

• Minimum retransmission score: all three clients have BTPs that do not experience any packet loss.

From the results depicted in Table IV we can conclude that there is quite some variation with respect to the different performance metrics, and also the maximum retransmission scores of the HU-many users are much higher than of the HU-one users. However, we are not able to draw any conclusion on the origin of that variation and the cause of the high retransmission scores. We need to look at bit closer and study in more detail the performance metrics computed for the different BTPs. Fig. 5 shows the throughput and retransmission scores achieved by each individual BTP of the three users. For each BTP, we plot the average value of the metric of interest for the period of duration of that BTP. This is to understand the similarities and differences between the BTPs of the same users, also in relation to the time during which the BTPs occur. We observe that:

• Throughput: for Yellow and Red, the BTPs of the same user achieve very different throughputs. On the other hand, Green sees quite uniform throughput performance.

• Retransmission score: for Green, the variance in the retransmission scores is the largest and there are many BTPs that experience high loss, whereas for Red there are only a few BTPs with high loss rates; most of the BTPs of Red as well as all BTPs of Yellow experience very little or no loss. Persistently high loss rates, as in the case of Green, indicate a performance problem that we will investigate further below.

• Number of parallel BTPs: all three users have many parallel connections active at the same time. In 2005, Vacirca et al. [START_REF] Vacirca | Large-Scale RTT Measurements from an Operational UMTS/GPRS Network[END_REF] excluded p2p traffic from their analysis because of the use of several parallel connections, which are likely to induce self-congestion. Parallel connections can either be due to the end-user behavior or to the PEP that opens multiple parallel connections to improve download performance: we checked for Green the evolution of the number of connections at the Internet side and saw that it closely follows the one at the cellular side, which means that it is the end-user behavior and not the PEP that determines the number of connections. To further investigate if there is a causal relationship between the high retransmission score and the number of parallel connections, we need to look at (i) the variation of the performance parameters over time and (ii) the total traffic received by a mobile station aggregated over all connections, which includes ALPs and short connections. For space reasons, we focus on Green, for which we depict the aggregated throughput, retransmission score, and number of parallel connections in Fig. 6. All these values are computed for non-overlapping intervals of 30 sec. We tried different values and found that 30 sec is a good compromise that preserves enough detail of the temporal evolution. We see that:

• Even with several simultaneous connections, the aggregate throughput stays below 400 Kbit/s. We suspect that the limit is given by the capacity of the wireless access, which seems to be a RS-99 access with a nominal capacity of 384 Kbit/sec.

• In the interval between 750 sec and 1750 sec, the aggregate throughput is quite stable, while the number of parallel connections and the loss rate vary a lot; It is interesting to note that at time 1250 sec (evidenced in Fig. 6) both, the number of parallel connections and the retransmission score drop sharply, whereas the aggregated throughput stays the same. This observation can be interpreted as follows: (i) for Green, to use all the available capacity, it is not necessary to have tens of parallel connections, in fact (ii) too many parallel connections are harmful, competing for the limited transmission bandwidth and inflicting loss on each other.

VII. CONCLUSION

Cellular networks have experienced tremendous growth in recent years. With the advent of 3G and smart phones, data transmission over cellular networks has increased dramatically. We proposed an approach, able to work in a blind fashion (i.e. working with no other information apart from the packet headers), using a cellular data trace to assess the performance of users and identify its causes. After providing global performance statistics, according to the literature [START_REF] Estan | New directions in traffic measurement and accounting: Focusing on the elephants, ignoring the mice[END_REF], our approach focuses on heavy users, starting with HU-one users followed by HU-many users. For HU-one users, indicators such as retransmission score of Bulk Transfer Periods allow to assess the performance and quickly spot the causes. For HU-many users, we have to look at the time behaviour of throughput, retransmission score, and number of connections, in order to understand the causes of the performance.

We found that (i) heavy users transmit tens of Mbytes of data in a single session; (ii) the throughput achieved can vary by more than one order of magnitude depending on the access technology; (iii) while most users experience very low loss rates, some users experience high loss rates in the order of 10%; (iv) the cause of a high loss rate is, in some cases, a resource shortage inside the cellular core network (e.g. silver user), and, in other cases, a congestion at the access (e.g. green user) induced by user behaviour.

If details on the topology of the cellular network are also known, our work may be extended to locate the congested part of the network: (i) identify all HU-one users and compute the retransmission score for each user; (ii) partition the HU-one users into two classes according to whether their retransmission score is above or below a threshold that needs to be set; (iii) assign each HU-one user to the cell it has been connected to and (iv) identify which parts of the network the packets have traversed, first identifying the parts of the cellular network that work fine and then ones that are overloaded.

Fig. 1 .

 1 Fig. 1. Schema of the network.

Fig. 2 .

 2 Fig. 2. CDF of connection volume (top) and RTT (bottom).

Fig. 3 .

 3 Fig. 3. Throughput and retransmissions.

Fig. 4 .

 4 Fig. 4. Partitioning into BTPs and ALPs.

Fig. 5 .

 5 Fig. 5. Throughput and Retransmission scores vs. Time of all BTPs.

Fig. 6 .

 6 Fig. 6. Performance of Green.

TABLE I CHARACTERISTICS

 I OF THE ANALYZED TRACES.

	Trace	Date and time	Duration	Packets	Bytes	Cnxs
	Cellular1	2008-12-11 20:31	00:59:56	5Mega	4Giga	187,034
	Internet1	2008-12-11 20:31	01:00:07	6Mega	4Giga	226,814
	Cellular2	2008-12-11 20:31	01:00:22	5Mega	4Giga	178,292
	Internet2	2008-12-11 20:31	01:00:21	6Mega	4Giga	223,175

TABLE II CELLULAR1

 II : GLOBAL STATISTICS. Bytes in payload from servers to clients 3.30 * 10 9 Bytes in payload from clients to servers 1.68 * 10 8 Data packets from servers to clients 2.62 * 10 6 Data packets from clients to servers 2.55 * 10 5 Max bytes/connection from servers to clients 2.49 * 10 8 Max bytes/connection from clients to servers 7.42 * 10 6

	Max pkts/connection from servers to clients	1.83 * 10 5
	Max pkts/connection from clients to servers	5.17 * 10 3
	Average RTT	683 ms
	Retransmissions from servers to clients
	due to timeout expiration	5.76 * 10 4
	Retransmissions from servers to clients
	due to fast retransmit	1.45 * 10 4

TABLE III STATISTICS

 III OF THE BTPS FOR THREE HU-O N E USERS.

			Duration [s]	Tput [Kbps]	retr score	MBytes in
	User	BTPs	Min	Max	Min	Max	Min	Max	BTP
	Pink	8	1	2086	327	1463	0.000	0.008	252.548
	Silver	2	17	3596	100	391	0.045	0.055	45.862
	Aqua	1		1721		370	0.001	58.195

TABLE IV STATISTICS

 IV OF THE BTPS FOR THREE HU-M A N Y USERS.

					Duration [s]	Tput [Kbps]	retr score	MBytes in
	User		BTPs	Min	Max	Min	Max	Min	Max	BTP
	Red			141	1	73	271	2921	0.00	0.173	111.523
	Green		86	6	833	11	297	0.00	0.205	58.997
	Yellow		69	1	130	707	2386	0.00	0.025	99.653
	Throughput [bit/s]	1 5 10 15 20 25 30	5 x10			Yellow Green Red	0.01 0.05 0.1 0.15 0.2 Retransmission score		Yellow Green Red
		0	1000	2000 Time (s)	3000		0	1000	2000 Time (s)	3000

WiNMee 2010

Even if the operators have completely upgraded their networks, they still have to wait for all customers to buy new handsets before they can retire the older access technologies.

In our preliminary analysis, we also looked at the RTT. We saw that the such parameter can vary a lot depending not only on the state of the network but also on access technology and buffering policy used, which makes the RTT not a good indicator to understand the cause of the performance experienced by the users.

In the rest of the paper we will use retransmission score and loss rate interchangeably.


Jannik Laval

Alexandre Bergel

Stéphane Ducasse

Assessing the Quality of your Software with MoQam

INTRODUCTION

Over the last decade, the need for quality in software has increased. Several quality models have been proposed [START_REF] Glass | Building Quality Software[END_REF][START_REF] Jung | Measuring software product quality: A survey of iso/iec 9126[END_REF][START_REF] Spinellis | Code Reading The Open Source Perspective[END_REF]. These models emphasize the need to have quality checks while developing a software program. As far as we are aware of, no model to assess quality of existing software have reached a significant acceptance. This paper describes the Qualixo quality model. Qualixo is an open-source quality model developed by several companies and pushed further in the context of the Squale research project. According to Marinescu and Ratiu [START_REF] Marinescu | Quantifying the quality of object-oriented design: the factor-strategy model[END_REF], Qualixo can be classified as a Factor-Criteria-Metrics quality model. Qualixo is being applied in large companies such as AirFrance or PSA. It uses measurements to assess software quality. These measurements cover a number of different aspects of a software, including specification accuracy, programming rules, and test coverage. Qualixo has been originally implemented on top of Eclipse. In this paper we present Mo-Qam (Moose Quality Assessment Model), the implementation of the Qualixo quality model in the Moose open-source reengineering environment. This paper is organized as follows: Section 2 presents the model and its four components. Section 3 describes how the model is implemented in Moose. Section 4 offers two examples of notation and a real test of MoQam. Section 5 gives a brief overview of the related works, and finally, Section 6 concludes.

OVERVIEW OF THE QUALIXO MODEL

The model defined by Qualixo is composed of four elements, each having a different granularity. Figure 1 presents the four levels of the Qualixo model. Starting from the most fine-grained element it is composed of:

• a metric is a measurement directly computed from the program source code. The current implementation provides 17 metrics.

• a practice assesses one quality of a model. A practice is associated to one or more metrics. 50 practices are currently implemented.

• a criteria assesses one principle of software quality by weighting a set of practices. Such a principle could be safety, simplicity, or modularity. For now, 15 criteria are implemented.

• a factor represents the highest quality assessment. A factor is computed over a set of weighted criteria. 6 factors are currently available and are explained in a following section.

Metrics.

A metric is a measurement on a source code. it is a function that returns a numerical value which evaluate a source code. As such, metrics are considered as low level. Literature on metrics provides a significant amount of metrics such as the well known Depth Inheritance Tree (DIT, INH) and Specialization Index (SIX) [START_REF] Henderson-Sellers | Object-Oriented Metrics: Measures of Complexity[END_REF][START_REF] Kan | Metrics and Models in Software Quality Engineering[END_REF][START_REF] Lorenz | Object-Oriented Software Metrics: A Practical Guide[END_REF]. Figure 2 shows the different information collected to fully represent a metric. It is composed by an acronym, a name and a list of alternative names (a metric may have several name), a formulae referencing a function object, a version number (the version number refers to possible different implementations of the same metrics), a reference pointing to the articles precisely defining the metrics, possible metrics that could be used to replace the current one, a reference source and their associated results against which the metric can be tested for non-regression, supportedBy lists the list of tools implementing the metrics.

Practices. A practice is a composition of metrics that weights and scales the metric's value down to make it range between 0 and 3. By convention, 3 is a good mark meaning that the software under analyses does it well for the given metric. A practice may be associated to one or more metrics. The practice formula is defined in two different ways: either by a continuous function, or by a discrete function using metric thresholds. For example, a discrete function is used in practice Inheritance Size. It is based on Depth Inheritance Tree (DIT) [START_REF] Lorenz | Object-Oriented Software Metrics: A Practical Guide[END_REF].

Value is 0 if DIT > 7 Value is 1 if SIX > 6 Value is 2 if SIX > 5 Value is 3 if SIX =< 5
A practice is a formula based on metrics. Most of the time, the formula weights different metrics it is combining to emphasize a particular characteristic of the software under analysis. A practice may be discrete or not. A discrete function is used by certain practices to highlight which are badly noted. It imposes thresholds which should not be exceeded whereas a continuous function is linear.

As an illustration, consider the practice Coupling Class Efferent. It is based on the Coupling Between Object (CBO) metric [START_REF] Chidamber | A metrics suite for object oriented design[END_REF]. This formula returns a value between 0 and 3: Quality Criteria. Practices are gathered and balanced to define criteria values. A criteria groups practices by categories. For example, the criteria level of interdependence groups practices efferent coupling class and related coupling class because these two practices show dependencies between classes.

Quality Factor. A factor gives a mark, called a quality factor, between 0 and 3 for an average of criteria. Note that the criteria used by a factor must be coherent and, for example, measures the same entities. A factor is the highest level of evaluation. Therefore, a factory quality is computed for the whole program and may potentially covers all elements of the meta-model.

Six quality factors are currently defined in Qualixo:

• Functional capacity represents the adequacy between the needs and functionalities offered.

• Architecture corresponds to the technical architecture quality.

• Maintainability represents the facility to correct residual errors.

• Capacity to evolve measures the capacity to add functionalities.

• Capacity to re-use represents faculty to re-use the code artifacts.

• Reliability represents the stability of the program.

Thus, a complete assessment of a software system results in 6 quality factor. A quality factor below 1 is interpreted as a failure in meeting its quality objective. Between 1 and 2, the quality objective is considered as achieved with reserve. Above 2, the objective is considered as achieved.

Applying the Qualixo model on a given software system cannot be fully automated. Some metrics cannot be automatically extracted from the code, and thus require human intervention. Typically, metrics related to the documentation fall into this category.

IMPLEMENTATION

MoQam is the partial implementation of the Qualixo model on top of the Moose reengineering environment [START_REF] Ducasse | Moose: a collaborative and extensible reengineering environment[END_REF][START_REF] Nierstrasz | The story of Moose: an agile reengineering environment[END_REF] based on the FAMIX source code meta-model (See Figure 3). Only metrics that can be automatically computed are covered by our implementation. Therefore, practices, criteria and factors related to these software metrics are provided by our implementation (9 practices, 4 criteria, a part of 2 factors).

Our implementation enriches FAMIX element classes: class related metrics and practices are implemented as extension in FAMIXClass, method related metrics and practices in FAMIXMethod, package related metrics and practices in FAMIXPackage.

Moose comes with a large set of metrics. MoQam benefits from them by mapping each MoQam metric into a Moose one. As factors and criteria are application level aggregates, they are implemented in the class MooseModel.

As an example, consider the practice Inheritance Size. It aggregates one metric: DIT, which is weighted by a discrete function as shown in ncInheritance, and then is weighted by npInheritance. The practice does an average of the weighting function and returns a result between 0 and 3. The implementation is the following:

CASE STUDIES

We apply the Qualixo model to two large software systems: Moose (170 Classes) and ArgoUML (1654 Classes). Yet, just some practices and criteria are implemented.

Moose. This is a test of MoQam Implementation on the package Moose. Just some practices are tested here: result for practiceAfferentCoupling 1.47 result for practiceEfferentCoupling 1.04 result for practiceDocumentation 0 result for practiceInheritanceSize 0.83 result for practiceMethodsNumber: 3 result for practiceMethodsSize: 0 result for practiceSpaghettiCode: 0 Here, we can say:

• Links between classes are acceptable (practiceAfferentCoupling is equal to 1.47 and practiceEfferentCoupling is equal to 1.04)

• There is little or no documentation (practiceDocumentation) in methods.

• The depth inheritance tree is bad (practiceInheritanceSize less than 1). When we look the inheritance tree of MooseCore, we can notice that some classes have a hierarchy size higher than 6 (like all classes which inherit from FAMIXAb-stractNamedEntity). The DIT of the class FAMIXAbstract-NamedEntity is 5, because DIT is calculated from the class Object. So this is clearly an indication that the metric should be interpreted since we know that the inheritance hierarchy of Moose and in particular the FAMIX model is good and optimal.

• The number of methods for a class is good (practiceMethod-sNumber).

• But the size of methods and its complexity is high (prac-ticeMethodsSize and practiceSpaghettiCode).

Here, results show mainly that this is less documentation and it is necessary to add this. The result ArgoUML. This is a test of MoQam Implementation on ArgoUML.

Just some practice are tested here:

result for practiceAfferentCoupling: 3.0 result for practiceEfferentCoupling: 3.0 result for practiceDocumentation: 0 result for practiceInheritanceSize: 0.3541 result for practiceMethodsNumber: 0.0012 result for practiceMethodsSize: 0 result for practiceSpaghettiCode: 0

We can say that just links between classes are good. The rest has bad notation : there is no or little documentation, the inheritance tree is high, the number, the size and the complexity of methods is high.

Then criteria can be computed: the criterion criteriaInterdepen-danceLevel is an average of practiceAfferentCoupling and practice-EfferentCoupling. Thus its result is 3.0, the level of independence of ArgoUML is very good. And the criterion criteriaSimplicity is an average of practiceSpaghettiCode, practiceMethodsNumber and PracticeMethodSize. Thus its result is 0, the simplicity of Ar-goUML is very bad.

This list shows that we can improve the software. According to the results, things to do is : first, to add more documentation in methods and to review the number and the size of methods and third to analysis the inheritance tree because it is high.

This analysis can be used by managers or engineers to improve the process of reengineering of a software. These high-level attributes are assessed using a set of empirically identified and weighted object-oriented design properties [START_REF] Bansiya | A hierarchical model for object-oriented design quality assessment[END_REF].

RELATED WORK

QMOOD involves four levels (L1 through L4), and three mappings (L12, L23, L34) used to connect the four levels. While defining the levels involves identifying design quality attributes, quality carrying design properties, object-oriented design metrics, and objectoriented design components, defining the mapping involves connecting adjacent levels by relating a lower level to the next higher level.

QMOOD assesses for each component its quality. Based on the detection strategy mechanism, a new quality model is proposed, called Factor-Strategy. This model uses a decompositional approach, but after decomposing quality in factors, these factors are not anymore associated directly with a bunch of numbers. Instead, quality factors are now expressed and evaluated in terms of detection strategies, which are the quantified expressions of the good-style design rules for the object-oriented paradigm.

CONCLUSION

This paper describes MoQam, an implementation of a quality model for software named Qualixo. An implementation is also described and two case studies have been realized. Results of these case studies are encouraging to continue to develop it.

This approach has three positive points. First, MoQam uses four levels of granularity, which offers different scopes for an analysis. Second, the weighting to calculate the practices allow bad coding style to be highlighted. Third, these results may be used in a dashboard.

Future work will focus on four points: first, we will weight practices to calculate criteria. That allows the same purpose that the weighting of practices: we will be able to highlight bad programming style. Second, we will integrate some metrics to compare and replace metrics which can be debatable (like LCOM, which can be replaced by TCC and LCC (Tight and Loose Class Cohesion), for example). The third thing is to integrate the manual practices of the model to have all factors functional. We project to experiment this model on several package which we wish to study. The Fourth point is to allow to personalize criteria (which practices used) and factors (which criteria used) according to project.

Figure 1 :

 1 Figure 1: Meta-model of Qualixo Model.

Figure 2 :

 2 Figure 2: Meta model for metrics.

FAMIXClass>>notationOfComponentEfferentCoupling | result |

  result:= ((10-(self sureReferencedClasses size))/3) exp. (result < 0) ifTrue: [^0]. (result > 3) ifTrue: [^3]. ^result Another interesting practice is Documentation. In our implementation, this practice is associated with FAMIXMethod entity since it is based on metrics Number of Lines of Code which counts the lines of codes (and is equivalent to LOC) and Number Of Comments which counts the number of lines of comments.

FAMIXClass>>DIT ^self superclassHierarchy size 1 Figure 3 :

 13 Figure 3: Qualixo meta-model implementation in FAMIX.

FAMIXClass>>notationOfComponentInheritance (self dit > 7 )

 7 ifTrue:[ˆ0]. (self dit > 6) ifTrue:[ˆ1]. (self dit > 5) ifTrue:[ˆ2]. ^3 FAMIXClass>>notationOfPracticepInheritance ^(20 ** ((self notationOfComponentInheritance) negated)) MooseModel>>practiceInheritanceSize | practice result | practice:= self allClasses inject: 0 into: [:first:each | first + each notationOfPracticepInheritance ]. result:= practice / self allClasses size. ^((result log) / (20 log)negated)

  Hierarchical model. The Quality Model for Object-Oriented Design (QMOOD) model in use has lower-level design metrics defined in terms of design characteristics, and quality is assessed as an aggregation of the model's individual high-level quality attributes.

	Swat4j. Swat4j 1 is a quality model for Java. It comes with about
	30+ Metrics and about 100+ Industry Standard Best Practice Rules.
	Swat4j is designed based on the principles of ISO 9126-1 (Quality
	Model) and ISO 9126-3 (Software Product Quality, Internal Met-
	rics).

  Squale provides globals appreciations in terms of factors.Detection strategies. Marinescu and Ratiu[START_REF] Marinescu | Quantifying the quality of object-oriented design: the factor-strategy model[END_REF] raised the following question How should we deal with measurement results? After having pinpointed few limitations in Factor-Criteria-Metric models (e.g., obscure mapping of quality criteria onto metrics, poor capacity to map quality problems to causes), they introduce detection strategies as a generic mechanism for analyzing a source code model using metrics. The use of metrics in the detection strategies is based on mechanisms of filtering and composition. A filtering operation is characterized with thresholds and extremities. Composition operators are and, or, butnotin.

http://www.codeswat.com


Alexandre Bergel

Stéphane Ducasse

Jannik Laval

Romain Peirs

Enhanced Dependency Structure Matrix for Moose

Dependency Structure Matrix (DSM), an approach developed in the context of process optimization, has been successfully applied to identify software dependencies among packages and subsystems. It exists a couple of algorithms to help organizing the matrix in a form that reflects the architecture and highlights patterns and problematic dependencies between subsystems. However, the existing DSM implementations often miss some important information in their visualization to fully support a reengineering effort. In this paper we enhanced DSM with enriched cell contextual information by showing information (i) about the kinds of references made (inheritance, class accesses..), (ii) the proportion of entities (classes/methods) doing references, (iii) the proportion of entities been the target of the references. We distinguish independent cycles and stress the cycles using coloring information. This work has been implemented on top of the Moose open-source reengineering environment and Mondrian. It has been applied to non-trivial case studies such as the Morphic UI frameworks available in Squeak an open-source Smalltalk.

Introduction

Understanding the structure of large applications is a challenging but important task. Several approaches provide information on packages and their relationships, by visualizing software artefacts, metrics, their structure and their evolution. Software metrics can be somehow difficult to understand since they are dependent on projects. Distribution Map [START_REF] Ducasse | Distribution map[END_REF] alleviates this problem by showing how properties are spread over an application. Lanza et al. [START_REF] Ducasse | The class blueprint: Visually supporting the understanding of classes[END_REF] propose to recover high level views by visualizing relationships. Package Surface Blueprint reveals the package internal structure and relationships among other packages. A package blueprint is structured around the concept of surface, which represents the relationships between the analyzed package and its provider packages [START_REF] Ducasse | Package surface blueprints: Visually supporting the understanding of package relationships[END_REF].

Dependency Structure Matrix (DSM) is an approach originally developed for process optimization. A variety of algorithms exist to organize the matrix in a form that reflects the architecture. These algorithms highlight patterns and problematic dependencies among tasks. It has been successfully applied to identify software dependencies [START_REF] Lopes | Context-awareness in software architectures[END_REF][START_REF] Steward | The design structure matrix: A method for managing the design of complex systems[END_REF][START_REF] Sullivan | The structure and value of modularity in software design[END_REF]. MacCormack et al [START_REF] Maccormack | Exploring the structure of complex software designs: An empirical study of open source and proprietary code[END_REF] have applied the DSM to analyze the value of modularity in the architectures of Mozilla and Linux.

While DSMs are a proven solution to reveal software structure, DSMs have weaknesses too. They lack providing certain information when computed and rendered. DSM current implementations lack a fine grained information without losing their overview ability. Certain algorithms produce blurry cycles with the power of adjacency matrix method in which independent cycles are merged. Moreover detected cycles are not focused on an entity and lack of support for class extension.

Our contribution addresses such weaknesses. We enriched cell contextual information by showing information (i) about the kinds of references made (inheritance, class accesses..), (ii) the proportion of entities (classes/methods) doing references, (iii) the proportion of entities been the target of references. We provide hints at packages introducing wrong references. We distinguished independent cycles and stress the cycles using coloring information. In addition, we distinguish true cycles from independent cycles within the same level. Finally we offer an entity-focused oriented view of level cycle.

DSM Limitations

We identified a number of limitation for DSMs: merging independent cycles (Section 2.1), lack of fine grainedoverview (Section 2.2), cycles not focused on an entity (Section 2.3) and lack of support for class extension (Section 2.4). 1

Blurry Cycles with the Power of Adjacency Matrix Method

A way to identify cycle in DSM is to use the technique based on powering the adjacency matrix. The principle of this approach is to raise a binary DSM to its n-th power to indicate which elements can be traced back to themselves in n steps; thus constituting a cycle [START_REF] Yassine | Engineering design management: an information structure approach[END_REF]. However, the indicated elements do not automatically belong to the same cycle. Indeed, it can exist several cycles with the same number of steps and the power of the adjacency matrix method cannot differentiate these different cycles, so we have blurry cycles.

A B C D A X B X C X X D X

Figure 1. A DSM

On Figure 1, we see that the elements A and B constitute a direct cycle and the elements C and D constitute another one. But if we raise the binary DSM (Figure 2(a)) to the square by applying the adjacency matrix technique, a non-zero value appears in the diagonal for every element (Figure 2(b)). These non-zero values mean that any of the elements A, B, C and D are involved in at least one direct cycle but these non-zero values do not show what these direct cycles are made of. Moreover, with the partitioning algorithm based on powering the adjacency matrix, we merge these 4 elements together (Figure 2(c)) which means that in the partitioned matrix these elements will appear as one cycle (Figure 2(d)) -note that the grey zone represent the cycles. So, the partitioned matrix provides a wrong information by indicating a unique cycle (the grey area in Figure 2(d)) whereas the matrix should show two direct cycles as shown in Figure 2(e).

So, the power of adjacency matrix method does not allow us to determine precisely the different cycles. However, combining this algorithm with a path searching method identifies correctly all the different cycles.

Notice that the DSM software Lattix does not use the power adjacency partitioning algorithm but is using reachability matrix method.

Lack of Fine-grained Information

A traditional DSM offers a general overview but lacks from providing precise information about the situation it describes. We identify two kinds of weaknesses: lack of dependency causes and lack of dependency impacts.

A B C D A 0 1 0 0 B 1 0 0 0 C 1 0 0 1 D 0 0 1 0 (a) Binary matrix A B C D A 1 0 0 0 B 0 1 0 0 C 1 0 1 0 D 1 0 0 1 (b) Binary matrix to square ABCD ABCD (c) Merged DSM A B C D A X B X C X X D X (d) Partitioned DSM with adja- cency matrix method A B C D A X B X C X X D X
(e) Ideal partitioned DSM with two distinct cycles

Figure 2. Limitation of the power of adjacency matrix method

Lack of Causes. Dependencies can be due to several sources: class direct accesses, class extensions (see Section 2.3), inheritance relationships and method invocation. Fixing cycles may be different based on the source of linking e.g., changing a direct reference to a class is often simpler than changing an inheritance relationship. That is why, it is not enough to just indicate the dependencies in a DSM with a X (Figure 3(a)) or even with a number representing the number of dependencies that exist (Figure 3(b)). Indeed, indicating at least a number for each kind of dependency (Figure 3(c)) gives a more fine-grained information and so supports a better understanding of the situation.

A B C D A X B X C X D (a) DSM with marks A B C D A 5 B 3 C 1 D (b) DSM with numbers A B C D A 5 1 | 3 | 1 | 0 B 3 1 | 0 |1 | 1 C 1 0 | 1 | 0 | 0 D

Number of inheritances

Number of accesses

Number of invocations

Number of extended class (c) DSM with dependency kinds

Figure 3. Examples of references in a DSM

Lack of Impacts. In addition, the information provided often lacks important information and does not give an idea of potential problems. For example, knowing that a package has 99 references to another one is a valuable information. Such references could be done by 20 or 3 classes and these 99 references could refer to a small subset or a large number of classes. The same remark can be done for methods instead of classes. But knowing that these references originate only from 3 classes and 15 methods and that only 4 classes and 6 methods are referenced by these 99 dependencies makes a large difference. In addition, having access to this information without having to look at every class in the concerned packages clearly supports the software comprehension.

Cycles Not Focused on an Entity

Cycles are shown in the context of complete system and the ordering within a level is the result of the partitioning algorithm. It makes it hard to understand the cycle (and not the level) in which a given package is involved. In particular when cycles inside the same level are merged, we do not obtained an accurate information.

As an illustration, consider a package A involved in a direct cycle with the package B and this package B is involved in a direct cycle with the package C (Figure 4(a)). We therefore have A in a cycle that also includes C but the length of this cycle is not the same that the length of the cycle between package A and package B. This is why it is a valuable information to see the difference between the lengths of the cycles (Figure 4(b)) since the used methods to break them will not be the same. In Figure 4(b) direct cycles started from the entity A are displayed: yellow shows the direct cycles, then red the second level.

No Support for Class Extensions

A class extension is a method that is defined in a package, but whose class is defined in another package [START_REF] Bergel | Classbox/J: Controlling the scope of change in Java[END_REF][START_REF] Bergel | Classboxes: Controlling visibility of class extensions[END_REF]. Class extensions exist in Smalltalk, CLOS, Objective-C and now partly in C#. They offer a convenient way to incrementally modify existing classes when subclassing is inappropriate. Indeed, extending by subclassing may be inappropriate because that specific class is referred to, but, one cannot modify the source code of the class in question. A class extension can then be done to that specific class.

Enhanced DSM

Our apparoch takes into account the previously described limitations and adds some functionalities that does not seem to be offered by DSM software like Lattix [START_REF] Sangal | Using dependency models to manage complex software architecture[END_REF]: (i) enriched contextual cell information (Section 3.1), (ii) isolating independent cycles and coloring information (Section 3.

Enriched Contextual Cell Information

As described in the previous section, current DSM software do not provide a fine-grained information within the overview offered by the matrix. We address this issue in our enhanced DSM by enriching the cell contents (Figure 5). The enriched contextual cell information shows the following information:

1. Strength of the dependency. On the first line, we show the number of references from a package to another one. This number gives us the strength of the link which exists between these packages but give no more information.

2. Dependency Kinds. The second line shows the kinds of reference (Inheritance (H), Access (A), Invocation (I) and class Extension (E)) and how many references there are for each. These numbers give us a coarse grained information about the relationships between packages.

3. Source and Spread of the Dependency. Finally, we show how the references are spread in and to the packages. We give the numbers of classes in both packages on the third line. This information gives us an idea of the size of the packages involved in the dependency. On the fourth line, we indicate for the package doing the reference and the package been referenced the number of classes and methods that are actually doing the references or been referenced. The last line express the same idea but with percentages. This information is important because it shows us two things: the importance of the classes doing the references and the spread of such references on the target package. We can get an idea of the spread and flow of the references. For example, whether it is a small part of a package or a big one which is source of the dependencies and approximates the necessary engineering effort to remove these dependencies.

This enriched contextual view supports the identification of situation by just glancing over the matrix.

Enhanced Cycle Detection

Identifying cycles is important in large entangled software. In the context of DSM, cycle detection is often realized using a path searching algorithm [START_REF] Gebala | Methods for analyzing design procedures[END_REF]. This algorithm allows one to detect separately every independent cycle. Indeed, as explained in Section 2.1, two packages, A and B, may be in a direct cycle and packages C and D in another direct cycle. In this case, these two cycles are identified with path searching algorithm, which cannot be achieved with an algorithm based on the powers of adjacency matrix. Our approach enhances the traditional matrix by proposing: cycle distinctions (Section 3.2), cycle nesting identification (Section 3.2), and hints for cycling fixing (Section 3.2)).

Cycle Distinctions. Our approach distinguishes independent cycles. It is based on the path searching algorithm [START_REF] Gebala | Methods for analyzing design procedures[END_REF]. With the path searching method, 2 independent cycles are separately detected and can so be isolated from each other in the DSM (Figure 6). have a yellow or red color. The yellow color means that the 2 concerned packages (a DSM cell is the intersection of 2 packages) are involved in an indirect cycle (a cycle with more than 2 elements) while the red color means they are involved in a direct cycle. The pale blue square frames the whole of packages which are in cycle (it is visible in Figure 9), contrary to the white lines and colomns which represent packages with no cycle.

Cycle Fixing Hints. In addition, in the case of a direct cycle, if there is a large difference between the number of references between the 2 packages (by default, the ratio is 3), the cell that contains the least references has a light red color (Figure 7(b)). This information allows the user to focus his attention on the references which should be solved a priori in a first time. As shown in Figure 9, such hint is really useful to spot packages potentially introducing cycles. A Concrete Example. We applied our approach to the Morphic framework of Squeak. Note that it was never packaged in a modular way, hence showing a lot of cyclic dependencies. You can observe in Figure 9 a large cycle represented in pale blue. Without any color, this would be difficult to quickly distinguish direct and indirect cycles. Indeed, direct and indirect cycles would not clearly appear, so the observer could not easily separate them. But with colored cells, at first glance, identifying direct and indirect cycles is easy. In addition, you can focus your attention on the light red cells because they indicate what are the cells which should probably disappear to eliminate the direct cycles.

Entity-focused Cycle Centric View

We have seen in the previous section that our approach isolates independent cycles and add information to them by coloring cells to distinguish direct and indirect cycles. However, if it is easy to see the different cycles which exist into a given layer when there are a few number of packages, it is much more difficult with a large number of packages. Indeed, you do not easily know if the length of a cycle between 2 packages is short or long. This is particularly complicated since an element can belong to several cycles which do not have the same length. It is difficult to show the length of cycles to which belongs an element.

To solve this problem, we added the notion of focused element. Indeed, the length of a cycle between an element and another one is relative to the first one. So, we represent the length of the cycles relative to a chosen element that we call the focused element. For example, in Figure 10

B C A B D C A X X B X X D X X C X X D (a) Situation with the focused element A A B C D D A C B D X X A X X C X X B X X (

Cycle Level

So, to help the visualization of the different cycles in which your focused element is involved, we introduce a color information for every cycle level. Indeed, as shown in Figure 11, the elements involved in the first cycle level with the focused element (i.e., the elements which are in cycle with the focused element and which the length of the cycle is the shortest) are in red color. This process is repeated for every element which is in cycle with the focused element: the elements which belong to a same cycle level are in a same color. Thanks to that color information, first, you can easily see whether 2 elements are close in a cycle or not and second, you can count the number of elements in every cycle level.

Conclusion

This paper enhances Dependency Structure Matrix (DSM), an approach which identifies dependencies between software packages. A DSM renders references between packages in a matrix-like table. In addition, several algorithms already exist to reorder the matrix and so reveal the software architecture.

However, a traditional DSM does not provide enough information about the references between the packages and about the cycles which can exist between them. This paper addresses such limitations by improving the information contained in a DSM and enhancing the way a DSM is Thanks to these improvements, understanding and analysis of software applications are easier and thus faster. However, in future work, it would be very helpful to be able to see directly in the matrix the consequences of the changes brought to the application without having to change the code and may be from that a code generator could make itself the changes into the code from the changes realized into the matrix.

Figure 4 .

 4 Figure 4. The importance of cycles focused on an entity

Figure 5 .

 5 Figure 5. DSM cell with enriched contextual information

Figure 6 .

 6 Figure 6. Independent cycles distinction

Figure 7 .

 7 Figure 7. Direct and indirect cycles coloring

Figure 8 .Figure 8

 88 Figure 8. Cell color definition

Figure 9 .

 9 Figure 9. Example of cycle detection

  , you can see that relative to the element A, the elements B and D are involved in a direct cycle with A; and the element C is in an indirect cycle with A (Figure 10(a)). But if you focus your attention on the element D, that are the elements A and C that are involved in a direct cycle with D and the element B which is in an indirect cycle with D (Figure 10(b)).

A

Figure 10 .

 10 Figure 10. Visualization of the different cycles relative to the focused element

Figure 11 .

 11 Figure 11. Visualization of different cycle levels