Paul Elzière

Cécile Dalle-Ferrier

Costantino Creton

Étienne Barthel
email: etienne.barthel@espci.fr

Matteo Ciccotti
email: matteo.ciccotti@espci.fr

Large strain viscoelastic dissipation during interfacial rupture in laminated glass

In the dynamic rupture of laminated glass, it is essential to maximize energy dissipation. To investigate the mechanisms of energy dissipation we have experimentally studied the delamination and stretching of a polymeric viscoelastic interlayer sandwiched between glass plates. We find that there is a velocity and temperature domain in which delamination fronts propagate in a steady state manner. At lower velocities, fronts are unstable while at higher velocities, the polymer ruptures. Studying the influence of the interlayer thickness, we have shown that the macroscopic work of fracture during the delamination of the interlayer can be divided in two main components: 1. A near crack work of fracture which is related to the interfacial rupture and to the polymer deformation in the crack vicinity. 2. A bulk stretching work which relates to the stretching of the interlayer behind the delamination front. Digital Image Correlation measurements showed that the characteristic length scale over which this stretching occurs is of the order of the interlayer thickness. Finally, an estimate of the bulk stretching work was provided, based on a simple uniaxial tensile test.

Introduction

A very useful and interesting material that is ubiquitous in our daily lives is laminated glass, a layered composite where a polymer layer is sandwiched between two glass plates in order to provide impact resistance to transparent glass panels such as car windshields or glass floors. When laminated glass is impacted by a hard object at high enough speed, multiple cracks propagate in the glass layers with little energy dissipation and the expected fracture resistance arises from the presence of a viscoelastic polymer interlayer which dissipates most of the energy of the impact, as it delaminates from the glass and is stretched extensively.

Several studies have tried to model the impact process in its full complexity. They considered various loading conditions in finite element analysis: blast resistance 1 , ball drop tests 2 or headform impact 3 . At this level of macroscopic description, the complexity of the impact problem and the complex rheological properties of the polymer preclude a precise description of the dissipation mechanisms.

Model experimental setups have been developed to improve the understanding of the different energy dissipation mechanisms involved during the impact. During impact the broken glass pieces undergo a membrane stretch and the glass shards move away from each other. This leads to the delamination of the interlayer and its subsequent stretching. We mainly focused on a Through Crack Tensile test (TCT Test, Figure 1). This test reproduces the uniaxial stretching of the delaminated interlayer and has been used in several previous studies on laminated glass [4][5][6] . These studies have emphasized the importance of the deformation of the viscoelastic interlayer in the dissipative processes.

An interesting result stemming from the TCT Test is the existence of a steady state delamination regime. Sha et al. 4 observed a constant level of force and strain during the delamination and were able to perform an estimate of the adhesion energy with finite element calculations. Sha et al. described the interlayer as a linear viscoelastic material and the interface was modeled with cohesive elements. The order of magnitude of the glass/interlayer fracture toughness was found close to 100 J.m -2 (at room temperature and for a controlled displacement speed of ≈ 0.01 mm.s -1 ). Muralidhar et al. 5 added to the previous description by using a viscohyperelastic model for the interlayer. This model gave a better qualitative description of the experiments. Moreover, they pointed out that the large observed macroscopic work of fracture comes from both the deformation of the bulk material and the interfacial fracture processes. A similar separation of the macroscopic work of fracture into bulk and interfacial contributions has been previously described also by Rahulkumar et al. 7 . The coexistence of different dissipation regimes, length scales and zones was also used in several attempts to explain the large amount of dissipated energy measured during the tearing of viscoelastic materials or during the debonding of a viscoelastic polymer from a rigid surface [8][9][10][11] . Only a few experimental studies have focused on the details of the de-

METHODS

formation field near the crack tip for such materials 12 .

In this paper, we will show that in the TCT Test, a steady state delamination regime can only be achieved for certain conditions of applied velocity and temperature. In this steady state regime, the macroscopic work of fracture will be estimated and separated in two components: a bulk stretching work and a near crack work of fracture. We will show that most of the energy is dissipated by the stretching of the material over a length close to the interlayer thickness. In this stretching zone, we will finally explain the large macroscopic work of fracture by both the high strain level and the important strain rate.

Methods

Interlayer

The interlayer is a standard industrial Poly(vinylbutyral) with a glass transition around 20 • C. More details on the material can be found in Elziere 13 .

Uniaxial tensile test

Uniaxial tensile tests were carried out to characterize the large strain behavior of the interlayer. The tensile experiments were conducted on bone shaped samples that had 0.76 mm thickness, 4 mm width and an active length of 20 mm. For higher forces (at higher strain rates and lower temperatures), the tests were carried out on a Zwick/Roell Hamsler HC25 hydraulic machine with a load cell of 1kN. For lower forces (at lower strain rates and higher temperatures), the tests were conducted on a Instron 5565 machine with 10 N and 100 N load cells.

Temperature was controlled by a PID thermoregulator 2216L from Eurotherm Automation in a temperature chamber.

Preparation of laminated glass

Model laminated glasses were assembled in a clean room. The 2 mm-thick glasses were cleaned with a standard industrial soap solution and dried with air. The glasses were then assembled with the interlayer. The samples were heated at high temperature in an autoclave for 1.5 hours at 140 • C and 10 bar, resulting in very good adhesion at the two glass/polymer interfaces.

The TCT Test samples were prepared with an interlayer thickness ranging from 0.38 to 1.52 mm. The reference interlayer was 0.76 mm in thickness. The samples were 50 mm in width and 100 mm in length.

Through Crack Tensile Test (TCT Test)

Model laminated glass samples were tested in a custom experiment to study the delamination of the interlayer from the glass. For the TCT Test, the two glass plates were pre-cracked. Cracks were propagated on each glass side in the middle of the plate.

The through crack tensile tests (Figure 1) were conducted on the Zwick/Roell machine with a 10 kN load cell. The tests were conducted at fixed grip velocity ranging from 0.01 to 100 mm.s -1 .

Displacements were measured with a Baumer VLG-20M video camera. Frames were acquired with a Matlab R (R2015a) Video Acquisition toolbox.

Digital image correlation DIC

Some TCT Test samples were modified to measure the local displacement field in the interlayer during delamination by digital image correlation. Paint was randomly spread to form a speckle of points (approximately 10 µm size) on one side of an interlayer piece with half the standard thickness. Another half thickness interlayer was juxtaposed to this one and the laminated structure was assembled as sketched in Figure 2. As a result the paint dots were placed on the midplane of the structure. Frames were captured with a Photron Mini UX100 fast camera at 125 fps with a Questar QM1 long distance microscope (resolution of 3 µm/px). Image treatment was done in Matlab R R2015a with the CORRELI Q4 digital image correlation program [START_REF] Hild | Correli Q4: A Software for Finite-element Displacement Field Measurements by Digital Image Correlation[END_REF] . The mesh size of the finite element grid used by the software was set to 30 µm. A regularization length of 0.6 mm was used during all calculations.

Results

Large strain behavior of the interlayer in uniaxial tension

During the impact or during the TCT Test, the delaminated interlayer is stretched up to large deformations leading to a high amount of dissipated energy [START_REF] Nourry | [END_REF] . To fully characterize this dissipation process, the mechanical response of the interlayer itself was characterized in the large strain regime and at various strain rates. Uniaxial tensile tests up to a stretch of 3 were performed on the interlayer. These experiments were conducted at 20 • C for four different stretch rates: 0.001, 0.01, 0.1 and 1 s -1 . Two additional tests were conducted at 10 and 50 • C at 1 s -1 . The crosshead velocity was constant during the loading and the unloading and thus the instantaneous strain rate decreases as the stretch increases.

Figure 3 shows the true stress σ T against stretch λ T of the interlayer in a cyclic uniaxial tensile test. The test carried out at 10 The complex large strain behavior of the interlayer involves a non-linear response, an important dissipation and a time dependent behavior. At low temperature, the material creeps back to its original shape within a few minutes after unloading. The initial modulus at 1 s -1 varies from 1 MPa at 50 • C to 200 MPa at 10 • C. At 20 • C and low strain rates (0.001 s -1 ) or at 50 • C, the interlayer behaves as a viscoelastic rubber. At higher stretch rates such as 1 s -1 at 20 • C and at 10 • C, the interlayer displays an elastic-plastic like behavior, with a yield stress followed by a plateau for stretches varying from 1.1 to 1.4. During the unloading part, the stress relaxes rapidly and at about a stretch of 2, the sample buckles and the curve is not representative anymore of the real behavior. However, after the cyclic experiment at 10 • C and 20 • C, the sample recovers its initial shape in 1 to 2 min at room temperature. This behavior is not observed at 50 • C where a permanent stretch of about 1.1 is observed.

The volume density of dissipated energy in a cycle E diss is defined as the difference between the area under the loading and unloading curves (Insert Figure 4). The ratio of dissipated energy over the total work of external forces W ext is denoted R d = E diss /W ext and is plotted as a function of time and temperature in Figure 4. R d ranges from 75 to 85% at 20 • C, it is above 95% at 10 • C and it is close to 40% at 50 • C.

Steady state in a Through Crack Tensile Test

A typical TCT Test is shown in Figure 5 for a temperature of 20 • C, a constant velocity δ = 10 mm.s -1 applied to the upper clamped glass and an interlayer thickness h = 0.76 mm. These test conditions will be used as the reference conditions in this study. In this experiment, four delamination fronts (two on each glass panefront and back -on the top glass and on the bottom glass) propagate at a constant velocity in opposite directions. We denote a the delaminated length on each side, which is measured as the distance between the edge of the glass plate and the delamination front (Figure 5). In between these fronts the delaminated interlayer of initial length 2a is stretched to the length δ + 2a. The mean stretch of the delaminated interlayer λTCTT is thus given by:

λTCTT = δ + 2a 2a (1)
As found in previous studies 5,6 , a steady state regime with constant force is observed during the delamination. As shown in Figure 6, the delamination force F TCTT first goes through a peak and then stabilizes to a steady state value F 0 TCTT when the delaminated length a becomes larger than the interlayer thickness h. The mean stretch also rapidly reaches a plateau value λ 0 TCTT in time (Figure 6). This result can be retrieved by plotting, as in the insert, the length of the stretched delaminated interlayer δ + 2a as a function of its intial length 2a. The fronts propagate symmetrically and the slope of this curve gives λ 0 TCTT about 2.4 in this case. In the insert, the mean stretch λTCTT is defined as the ratio of the length of the stretched delaminated interlayer δ + 2a over its initial length 2a.

Effect of velocity and temperature: delamination phase diagram

Beyond the reference test conditions, the time and temperature dependence of the TCT Test response were also explored. TCT Tests were performed at three different temperatures (5, 20 and 50 • C) and different crosshead velocities ranging from 1 to 60 mm.s -1 .

The steady state delamination process described in the previous part is not observed for all temperatures and velocities. At lower imposed velocities, the delamination front is unstable and starts to undulate. Propagation often stops after some time leading to a sudden increase of the mean stretch and eventually to the rupture of the interlayer through the propagation of a blunted crack. At higher imposed velocities, even if the delamination initially proceeds in a steady state regime, the delamination is prematurely interrupted by the sudden rupture of the interlayer through the propagation of a sharp brittle crack. In the present work, we will only focus on the measurements in the steady state regime where delamination is stable.

In Figure 7, the delamination force in the steady state regime F 0

TCTT is plotted as a function of tensile velocity δ for various temperatures. The delamination force increases as the velocity increases or the temperature decreases. The limits between the three regimes are also roughly estimated and drawn on the graph (dark lines). We remark that only the data points in the intermediate regime can be reported since the steady state force is not defined for the unstable regimes. Fig. 7 The steady state delamination force F 0 TCTT increases with speed and decreases with temperature. The dark lines roughly delimit the three delamination regimes. Data points can only be reported in the intermediate regime where no undulation of the front (low speed and high temperature) or brittle behavior (high speed and low temperature) were observed.

In Figure 8, the mean stretch in steady state λ 0 TCTT is plotted as a function of applied velocity δ and temperature. The measurements cover the stable delamination regime at each temperature. At 5 • C, the stretch ranges from 2.05 to 2.3, at 20 • C it ranges from 2.1 to 2.6 and at 50 • C it ranges from 2.8 to 3.05 for the different speeds. While the stretch is more or less constant within the error bars at both 5 • C and 50 • C, it displays a significant increase with velocity at 20 • C.

RESULTS

Measurement of the strain field by DIC

Measurement of the strain field by DIC

The strain field in the delaminated interlayer appears to be quite homogeneous in space except in the neighborhood of the delamination fronts. This can first be inferred from Figure 5(c), showing that the width of the interlayer becomes constant at a certain distance from the delamination front. In order to obtain a better description of the stretch field, digital image correlation experiments were performed during the delamination of patterned TCT Test samples (as described in section 2.5).

To determine the length scale of the stretch gradient, TCT Test were performed in the reference steady state condition (10 mm.s -1 and 20 • C) for two different values of interlayer thickness: 0.76 and 1.52 mm. The speed of the delamination fronts was found to be almost identical for both thicknesses (respectively 3 and 4 mm.s -1 ). The mean stretch λ 0 TCTT reached during the steady state delamination far from the fronts is close to its mean value λ 0 TCTT , which was found to be equal to 2.3 and 2.1 respectively.

The displacement field is measured along a vertical line parallel to the traction axis (white line in in Figure 9). From this displacement field, the interlayer stretch field λ DIC (x f ) is determined as a function of the distance x f from the lower delamination front. The results are represented in Figure 10 after normalizing the nominal strain field ε N DIC = λ DIC -1 to its mean value εN0 TCTT = λ 0 TCTT -1. The distance to the delamination front x F is normalized by the interlayer thickness h.

In the region A of the curve in Figure 10, the interlayer deforms up to a fraction of about 60% of εN0

TCTT on a length close to the interlayer thickness h. The corresponding value of the stretch will be denoted λ * TCTT . After this sharp increase of the strain, the polymer reaches the steady state maximal stretch (which is found to be close to the mean value εN0 TCTT ) over a much longer distance of the order of the sample width w (region B).

As this stretching occurs in a steady state regime, the stretch rate can be calculated using the delamination front speed. At 20 • C and for an applied velocity of 10 mm.s -1 , the stretch rate in region A is about 3 s -1 for the 0.76 mm thickness interlayer and about 1.5 s -1 for the 1.52 mm thickness interlayer. The stretch rate in region B is lower (about 0.5 s -1 ) and is essentially independent of the sample thickness. Finally, in the middle region of the interlayer, at a distance larger than w from the delamination front, the stretch is essentially constant during delamination and the stretch rate in this region is vanishing.

Influence of the interlayer thickness

As observed in the previous section, most of the stretching of the interlayer during steady state delamination is rapidly reached over a length scale roughly equal to the interlayer thickness h and with a local stretch rate that is roughly inversely proportional to h. Hence, the interlayer thickness should have a major influence on the overall TCT Test response. A TCT Test was thus conducted with four different interlayer thicknesses: 0.38, 0.76, 1.14 and 1.52 mm in the steady state delamination regime at the reference conditions: 20 • C and 10 mm.s -1 . As reported in Figure 11 the increase in the interlayer thickness leads to a proportional increase in the measured steady state force F 0 TCTT from 220 to 710 N, while the interlayer mean stretch ( λ 0 TCTT ) decreases slightly from 2.4 to 2.2.

Discussion and modeling

During the reference TCT Test at 20 • C and 10 mm.s -1 , the interlayer is stretched from λ = 1 to about 2.4 and most of this stretching occurs over a length equal to the interlayer thickness h, which induces high local strain rates (of the order of 3 s -1 for the standard thickness of 0.76 mm). The large strain properties of the interlayer (reported in section 3.1) suggest that in this range of temperature and stretch rate most of the external work provided to stretch the interlayer is dissipated. During the delamination of the interlayer, the stretching of this local region of size h might thus induce a large amount of dissipated energy to be added to the energy cost for propagating the interface cracks.

In the literature, the elevated level of dissipation during the tearing of a viscoelastic material or during the separation between a viscoelastic polymer and a rigid elastic substrate has long been a puzzling problem 11,[START_REF] Gent | [END_REF]17 . During the fracture of a viscoelastic material, even if the rupture of the chemical or physical bonds only requires 0.1 to 10 J.m -2 , large macroscopic works of fracture of the order of 1 kJ.m -2 are generally recorded. Most approaches developed between the '70s and '80s are based on perturbations of the crack tip stress field of linear elastic fracture mechanics. These perturbations involve the local energy dissipation due to viscoelastic or plastic constitutive laws of the materaial, while preserving linear elastic behavior in the far field.

Schapery 8 and De Gennes 9 suggested that because of the time dependency of the polymer behavior, there were several separate dissipation zones ahead of the crack tip. Later Saulnier et al. 18 and Persson et al. 19 have shown that this simple linear viscoelastic description of the material can support a large dissipated energy amplification observed during the crack propagation. However, Gent 10 has shown that when combining the time-temperature equivalence determined from the linear rheology of the viscoelas-tic material with the velocity-temperature dependence of the measured work of fracture, this leads to estimating an unrealistically small size for the dissipation zone at the crack tip, close to 1 Å. Barthel and Fretigny 20 have derived an improved formulation for a fully linear viscoelastic system that highlights the importance of the coupling between the remote loading and the crack tip dissipation phenomenon through an intermediate viscoelastic dissipation zone. Hui et al. [START_REF] Hui | Proceedings of the Royal Soiety of London A[END_REF] have shown that for soft elastic materials the crack tip region is elastically blunted by local large strains over a region of typical size Γ crack /E that can be millimetric in size for rubber-like materials. As explained by Creton and Ciccotti 11,[START_REF] Villey | [END_REF] this implies that for soft viscoelastic materials the large strain region and the dissipative regions are generally strongly coupled and the large strain behaviour is the relevant one for modeling the dissipation associated to crack propagation. Moreover, when the thickness of confined soft materials becomes comparable to the large strain dissipative region, the large strain dissipation in the bulk of the sample can also become a significant contribution to the total work of fracture and the issue of separability of the interfacial terms is presently an important open issue.

In the present section the delamination results will be used to determine the macroscopic work of fracture needed to delaminate the soft viscoelastic confined layer in the steady state regime. Then, different dissipation zones will be identified and the dissipation processes will be connected to the intrinsic mechanical behavior of the interlayer. Finally, the emerging model will be used to explain some of the previous experimental observations.

Macroscopic work of fracture

Since the interlayer is stretched during delamination, the macroscopic work of fracture is either stored elastically or dissipated due to the viscous and plastic components of the interlayer rheology. Only a small amount of the input energy will reach the delamination front and will serve to break the interfacial bonds between the interlayer and the glass.

Using the previous measurements, the overall macroscopic work of fracture G m for steady state delamination can be evaluated as follows:

G m = ∂W ∂ A = F 0 TCTT w .( λ 0 TCTT -1) (2)
where w is the width of the sample (w = 50 mm). At 20 • C and 10 mm.s -1 , G m is about 11 kJ.m -2 for the standard thickness (h = 0.76 mm).

The definition of G m does not correspond to the classical strain energy release rate, since it only contains the dominant term constituted by the work of external forces per unit delaminated area. This quantity is experimentally very well defined, since it corresponds to the measured macroscopic work injected in the system to delaminate the sample. When dealing with soft viscoelastic confined materials, it would be very difficult to properly account for the variations of the stored elastic energy during crack propagation. The strain energy release rate is thus an ill defined quantity that should be treated with caution. On the other hand, since the PVB interlayer proved to be a very dissipative material in the do-4.2 Identification of the different dissipation zones main of stretch rate and temperature used here, the stored elastic energy is a small fraction of the total work for stretching the interlayer (c.f. section 3.1). The macroscopic work of fracture can thus be considered to be close to the strain energy release rate under these circumstances.

Identification of the different dissipation zones

During a zero angle peel test of a thin layer made of a purely elastic material from a rigid substrate, a significant portion * of the macroscopic work of fracture is stored elastically in the stretched delaminated polymer, while the remaining part is consumed in complex crack tip processes. Under these circumstances the strain energy release rate can be evaluated properly and it provides a direct access to the energy dissipated in the crack tip region.

Collino et al. 23 and Ponce et al. 24 have shown that when frictional sliding is allowed during the peeling of an elastomeric material from a rigid substrate at low peel angle, a steady state delamination can occur and far from the delamination front the polymer reaches a homogeneous strain in a similar configuration to the TCT Test. Dissipation was shown to occur in two different zones: a first dissipation zone is associated with the propagation of the crack front, while a second larger region is due to the interface slip over a long distance ahead of the front and contributes the dominant term of the total dissipated energy. Although the delaminated interlayer is stretched over a length equal to the sample width, little energy is dissipated in this region by bulk viscoelasticity due to the weak dissipation presented by these elastomers. The large viscous and plastic dissipation of the laminated glass interlayer presented here complicates this description by adding a dissipation region in the stretched interlayer.

Amouroux et al. 25 and Newby and Chaudhury 26,27 have also shown that during the peeling of a viscoelastic adhesive tape on a sliding substrate, energy is dissipated in different zones: interface sliding, near crack viscoelastic losses and bulk viscoelastic dissipation due to the polymer deformation in the bulk of the film, although the large stretch of the peeled tape is prevented by the presence of a stiff backing.

During the steady state delamination of the interlayer in a TCT Test, several of these dissipation regions are combined and potentially strongly coupled. Similarly to the Essential Work of Fracture approach, commonly used for fracture of ductile semi-crystalline materials [28][29][30] , we can tentatively separate the bulk stretching work Γ bulk due to the deformation of the interlayer from a near crack work of fracture Γ crack , which includes the interfacial bond rupture between the interlayer and the glass as well as the near crack deformation of the polymer.

In order to separate these two different dissipative contributions, the variation of the macroscopic work of fracture with the interlayer thickness can be extracted from previous results in standard conditions. G m is found to increase affinely with the interlayer thickness 4 16 -2 . The slope of this curve is about 8 MJ.m -3 . The extrapolation of to a zero interlayer gives a intercept at 4 kJ.m -2 . * This is half if the material peels in its linear elastic regime. The near crack processes will depend on the mode mixity of the loading and on the interlayer confinement, but in the explored range of interlayer thicknesses these do not depend on the thickness. Hence, on Figure 12 the slope of the line gives the volume density (Π bulk ) of the bulk stretching work: Γ bulk = Π bulk h. In the full sample there are four similar regions close to the delamination fronts in which the near crack work of fracture Γ crack (per unit area) is dissipated. Since cracks propagate symmetrically, half the sample is considered here and the intercept of the previous line gives 2Γ crack . Thus, the macroscopic work of fracture is:

G m = 2Γ crack + Π bulk h (3)
Γ crack represents the energy dissipated near one single crack front. Π bulk is the energy volume density stored and dissipated by stretching the bulk of the interlayer from 0% to ε0 TCTT .

In the steady state delamination regime the stretching of the interlayer can be schematically separated into four zones as depicted in Figure 13. The following picture arises:

• Zone 1: The near crack tip work of fracture Γ crack is dissipated in the vicinity of each delamination front, where strain rate fields are dominated by the advancing stress concentration region.

• Zone 2: In this fast stretching zone, the interlayer is rapidly stretched from 1 to λ * TCTT , which represents 60% of the steady state mean value λ 0 TCTT . This stretching occurs over a length that is comparable to the interlayer thickness h. It is in this fast stretching zone that most of the bulk stretching work

Γ bulk = Π bulk h is dissipated. Π bulk
is the volume density of this work.

• Zone 3: In this intermediate zone, the polymer is stretched from λ * TCTT up to the maximal stretch λ 0 TCTT far from the delamination front over a longer region (length equivalent to the sample width w) and at a much slower pace.

• Zone 4: The middle region of the sample is essentially inactive since the stretch is constant both in time and space, and stress relaxation is negligible during the time scale of the experiment. On the other hand, if we only consider one half of the sample, as in Figure 13, the large macroscopic work of fracture G m is provided at the free end of this region.

Modeling the bulk dissipation

The leading term in the dissipation during steady state delamination is given by the fast stretching zone, where the interlayer undergoes the largest portion of its stretch and at the highest stretch rate. Although the interlayer undergoes a progressive loss of constraint when stepping though the zones 2, 3 and 4 (c.f. Fig. 13), a uniaxial tensile test at the appropriate stretch rate can provide a good approximation the amount dissipated energy in zones. We remark that the stretching of the interlayer ligament is similar to the stretching of fibrils during the peeling of pressure sensitive adhesives from a rigid substrate [START_REF] Villey | [END_REF] or from a tack test and the analogy between fibril stretching and homogeneous uniaxial tension tests has been done previously for soft solids 31 and for liquids 32 . Another analogous fibril stretching phenomenon occurs at a completely different length scale in the widening of crazes in glassy polymers [START_REF] Kramer | Fundamental processes of craze growth and fracture[END_REF] . In all these cases the polymer is stretched up to very large strains at relatively high strain rates leading to large amount of dissipated energy. However, the level of localization of the "active" high strain rate region will depend on the details of the non-linear behavior. In the case of the extension of craze fibrils in a polymer glass the extension from λ = 1 to λ = 4 occurs over the first few nm of a µm long fibril [START_REF] Miller | [END_REF] . The relevant stretch rate should thus be estimated at this local scale and is much larger than the average strain rate in a very similar way to the case of the TCT Test.

In order to understand why the bulk component of G m is proportional to the interlayer thickness, the volume of polymer involved in the stretching as the front advances by a distance da has to be evaluated. As a remote loading displacement dδ is applied with a constant loading speed δ that corresponds to a constant measured force F TCTT , the four crack fronts will simultaneously move a distance da. As described before, the delamination fronts are moving at a constant speed and the following relationship can be written:

da = ȧdt = 1 2( λ 0 TCTT -1) dδ (4)
where ȧ is the delamination front speed and dt is a small time increment.

The interlayer in the volume whda will first be delaminated when crossed by the crack fronts and will then undergo the large deformation process in the fast stretching zone. Thus an estimation Π th bulk of the bulk energy density stored and dissipated in the fast stretching zone is given by the work done in a uniaxial tension to stretch the interlayer from 1 to λ * TCTT at a stretch rate λ ∼ λ * TCTT ȧ/h:

Π th bulk ≈ λ * TCTT -1 1 σ T dλ T (5)
with σ T and λ T the true stress and stretch values measured during the uniaxial tensile test.

The stretch rates involved in the TCT Test at h = 0.76 mm and 10 mm.s -1 are about 3 s -1 . Using the uniaxial tensile test performed at the same temperature 20 • C and at the closest stretch rate 1 s -1 we found Π T bulk ≈ 9 MJ.m -3 . This value is comparable with the one reported in Figure 12.

We remark that this rough estimation should be refined in future work in order to take into account the progressive loss of constraint that the polymer undergoes when being stretched through the regions 2, 3 and 4 in Fig. 13. The purpose of this preliminary modeling is to show that the main component of the macroscopic work of fracture is close to the work of uniaxial extension of the interlayer. Thus, the dissipated portion of this energy can be extracted from the bulk energy density using the dissipation ratio R d defined previously. In the fast stretching zone, most of the external work is dissipated. In the reference conditions of the TCT Test 85% of the work done on the fast stretching is zone is dissipated by the viscous and plastic deformation of the polymer.

Velocity and temperature dependence of the interlayer behavior and of the TCT Test

As the main component of the macroscopic work of fracture is related to the stretching of the interlayer, a qualitative relationship between the large strain uniaxial tensile properties of the interlayer and the TCT Test results can be drawn as a function of loading velocity and temperature. However, the near crack tip work of fracture Γ crack could also depend on the delamination velocity ȧ and the temperature in an independent way, and this can indirectly affect the bulk term through a modification of the steady state mean stretch λ 0 TCTT . The variations of the delamination force F 0 TCTT with the applied velocity (Figure 7) can be explained by the behavior of the polymer in uniaxial tension. Indeed, it was found that λ 0 TCTT was almost constant with applied velocity at a given temperature (Figure 8). Therefore the stress needed to stretch the interlayer in uniaxial tension to an identical stretch increases with increasing average stretch rate. Similarly, as the steady state mean stretch of the interlayer decreases when the temperature increases, and the interlayer is softer, the delamination force decreases.

The simple description of the TCT Test through the uniaxial tensile behavior of the interlayer, does not however explain the increase of λ 0 TCTT with velocity observed at 20 • C. The macroscopic stretch plateau reached by the interlayer might be controlled by a balance between the velocity dependence of the resistance to crack propagation Γ crack and that of the polymer hardening at large stretch. Such a dynamic balance is frequently observed in the detachment of soft adhesives where increasing the debonding velocity may decrease or increase the average macroscopic deformation at which the fibril detaches.

Finally, the macroscopic work of fracture depends on loading velocity and temperature as can be seen in Figure 14. Variations similar to the ones of the delamination force are observed: G m increases when the applied velocity increases and when the temperature decreases. A large drop of G m is observed when the temperature increases above the glass transition to 50 • C. The combination of these variations could be used to the different delamination regimes observed in the TCT Test.

The lower limit instability (low velocity and high temperature) could be linked to the requirement of satisfying both the energetic and stress criterion to propagate the delamination fronts. These minimal energy and minimal stress might also depend on velocity and temperature, but at low imposed velocity the macroscopic work of fracture can be too low to propagate the fronts. Moreover, at low stretch rates and high temperatures, the interlayer is softer, which might also prevent the stress to be high enough.

On the contrary, the upper limit of the TCT Test (high velocities and low temperature), could be linked directly to the limited tear resistance of the interlayer as both the stress and the available energy at the front need to be high enough to initiate and propagate the fracture of the interlayer. This would explain the stable, yet not reproducible, delamination observed at high velocity and low temperature.

Conclusion

In the impact rupture of laminated glass, the main source of energy dissipation is provided by the coupled stretching and delamination of the polymer interlayer between broken glass shards. This specific mode of polymer-glass delamination presents some analogy with the peeling of a soft layer in the limit case of vanishing peeling angle 35 . Using the through crack tensile test, we have shown that steady state delamination can be obtained only in a limited range of temperature and applied velocity. In this steady state regime, the delamination force and mean interlayer stretch are constant while four individual delamination fronts propagate in a symmetric manner at constant velocity. Because of the large stretch incurred by the polymer interlayer, this velocity is significantly smaller than the imposed velocity. In fact, our DIC measurements demonstrate that, upon delamination, most of the stretching of the polymer interlayer occurs over a length scale of the order of the interlayer thickness. Beyond this distance, stretching increases much more slowly. Based on this observation, we can evaluate the bulk work of stretching (volume density Π bulk ) from the uniaxial tensile response of the polymer measured at the relevant temperature and stretch rate. This estimate is consistent with the value obtained experimentally from the linear evolution of the work of fracture with interlayer thickness. Quite significantly, this linear evolution extrapolates to a non-zero work of fracture at zero thickness. This extrapolation signals massive dissipation near the crack tip, with a work of fracture Γ crack = 2 kJ.m -2 smaller yet comparable to the bulk stretch contribution. This value, however, is still thousandfold larger than the energy required to break the interfacial hydrogen bonds [START_REF] Israelachvili | Intermolecular and Surface Forces[END_REF] , because of strong material dissipation around the crack tip. Further work will investigate the connection between these two dissipation processes in an attempt to establish the relation between applied force (or mean stretch) and delamination velocity.

Fig. 1

 1 Fig. 1 Through Crack Tensile Test (TCT Test) model experiment. A uniaxial tensile test is conducted on a pre-cracked laminated glass sample. The interlayer is stretched in-between the delamination fronts which propagate in opposite directions.

Fig. 2

 2 Fig. 2 Experimental setup of the digital image correlation. Paint was randomly spread on one face of an interlayer sheet to form a speckle. The sample width is 50 mm.

Fig. 3

 3 Fig. 3 Uniaxial cyclic tensile tests at 10, 20 and 50 • C on the interlayer up to a stretch of 3 at different stretch rates.

Fig. 4

 4 Fig. 4 Dissipated energy ratio, namely dissipated energy over total work of external forces, as a function of time and temperature. In the insert, the highlighted areas correspond to dissipated energy (dark hashed) and elastically stored energy (plain green) on a uniaxial tensile test response at 20 • C and 1 s -1

.

Fig. 5 Fig. 6

 56 Fig. 5 A typical TCT Test at 20 • C and 10 mm.s -1 versus time. The sample width is 50 mm. The displacement of the upper clamped glass is called δ . The crack front position relative to the glass edge is noted a. The position of a given point in the reference frame of the lower delamination front is x F .

Fig. 8

 8 Fig. 8 Dependence of the mean stretch in the steady state regime with velocity and temperature.

Fig. 9

 9 Fig. 9 Digital image correlation frame. The displacements measured on the vertical white line are corrected by the displacements (supposed to be due to experimental noise) of the white square region out of the delaminated area.

Fig. 10

 10 Fig. 10 Local stretch measurements through digital image correlation at 20 • C and 10 mm.s -1 . Two thicknesses h were tested. Two stretch rate regions are identified ahead of the crack front. The first region A spans on a length close to the interlayer thickness h. The second region B spans on a length close to the specimen width w.

Fig. 11

 11 Fig. 11 Force (blue circles) and mean stretch (red triangles) measured for different interlayer thicknesses during a TCT Test at 20 • C and 10 mm.s -1 .

2 ) 3 Fig. 12

 2312 Fig. 12 Macroscopic work of fracture required to delaminate different laminated glass samples with increasing interlayer thicknesses at 10 mm.s -1 and 20 • C

Fig. 13

 13 Fig. 13 Far field/crack tip link and energy dissipation during steady state delamination. The stretching of the interlayer can be schematically separated into four zones described in the text. The blue shading in the upper part of the interlayer represents the intensity of the local strain. The reds shading in the lower part represents the local strain rate and is linked to energy dissipation. The dashed line represents the interlayer profile at a previous time during delamination.

Fig. 14

 14 Fig. 14 Variations of the macroscopic work of fracture G m provided during the TCT Test at h = 0.76 mm for different temperatures (5, 20 and 50 • C) and different velocities.

  • C is representative of the behavior in the glassy regime, while the test at 50 • C is representative of the rubbery regime. The results at 20 • C are close to the glass transition of the interlayer, which spans from 20 • C to 30 • C.

Y. Sha, C. Y. Hui, E. Kramer, P. Garret and J. Knapczyk, Journal of adhesion science and technology, 1997, 11, 49-63.

S. Muralidhar, A. Jagota, S. Bennison and S. Saigal, Acta Materialia, 2000, 48, 4577-4588.

6 C. Butchart and M. Overend, International Conference at glasstec, Düsseldorf, Germany, 2012.

Acknowledgements

We thank A. Jagota, C.Y. Hui and R. Gy for fruitful discussions.


Anne Girault

Marie Ferrua

Aude Fourcade

Guillaume Hébert

Claude Sicotte

Muriel Mons

Sophie Beaupère

Naïma Mezaour

François Lemare

Anne Montaron

Cancer patients' willingness to use it for their health

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

-the opportunity to have access to their electronic medical record -the possibility to increase communication with providers (via emails)

• Differences in perceived ease of use corresponding to age and socioeconomic status have to be addressed in the near future.

1371 questionnaires collected among seven outpatient departments (medical oncology for prostate, breast, skin, head and neck, endocrine, gastric and cervical cancers, radiotherapy, radiology, anesthesia, hematology).

Questionnaire design : (i) Access and use of IT (ii) Willingness to use IT for their health (iii) Socio-demographics (age, gender, socioeconomic status, number of people in the household, and the type of locality they live in).

Statistical analyses performed with R (α= 0.01)

PATIENTS AND METHODS

RESULTS

BACKGROUND

CONCLUSION OBJECTIVE I. Access and Use

• 71% used a mobile phone everyday • 93% had access to Internet from home.

• Tablets and smartphones were still minority.

III. Perceived ease of use of IT

• Above all, patients were not reluctant to use IT.

• 84% of the population studied declared to be able to use a computer, a tablet or a smartphone. • Only 8% disagreed.

• Influence of sociodemographics

Perceptions regarding ability to use IT were negatively associated with age and employment status.

Discussion

Challenges

• Comply with standards of privacy and security • Anticipate the impact on doctor-patient relationships • Providers expected to be more responsive • Patients willing to maintain face-to-face hospital contact Influence of sociodemographics -Age was negatively associated with the frequency of use of mobile phones and smartphones (p<0.001) but correlation coefficients were not important (respectively, r=-0.26, r=-0.27).

-Age and employment status were predictors of the frequency of use of mobile phones and smartphones.

Influence of sociodemographics

No significant gap among attitudes between the different patient groups could be identified.

Correspondence : anne.girault@ehesp.fr

Perspectives Study limitations

• Sampling from a single centre => limited generalizability although overall access and intentions were consistent with the results found in other studies • Risk of social desirability from respondents « i feel i am too old to use these technologies » « i am afraid my personal data will not be protected » Participation level = 85%

•

  Understand patients' current access to IT • Assess their willingness to use IT to manage their cancer. • Identify the influence of sociodemographic factors CANCER PATIENTS' WILLINGNESS TO USE IT FOR THEIR HEALTH A. Girault, M. Ferrua, A. Fourcade, G. Hébert, C. Sicotte, M. Mons, S. Beaupère, N. Mezaour, F. Lemare, A. Montaron, M. Ducreux, C. Guepratte, M. Di Palma, E. Minvielle Gustave Roussy -114 rue Edouard Vaillant -94805 Villejuif -FRANCE Recent changes in cancer care delivery (better survival rates, more outpatient care, oral therapies) are challenging current cancer care coordination practices > IT could improve cancer care coordination • Access and use of IT were widespread among the studied population. • Patients advocated for an extended use of IT in oncology, and above all:

Fig. 1 :

 1 Fig. 1: Frequency of use per IT device


Gustavo Santos

Klérisson V R Paixão
email: klerisson@ufu.br

Nicolas Anquetil
email: nicolas.anquetil@inria.fr

Anne Etien
email: anne.etien@inria.fr

Marcelo De Almeida Maia
email: marcelo.maia@ufu.br

Stéphane Ducasse
email: stephane.ducasse@inria.fr

Recommending Source Code Locations for System Specific Transformations

From time to time, developers perform sequences of code transformations in a systematic and repetitive way. This may happen, for example, when introducing a design pattern in a legacy system: similar classes have to be introduced, containing similar methods that are called in a similar way. Automation of these sequences of transformations has been proposed in the literature to avoid errors due to their repetitive nature. However, developers still need support to identify all the relevant code locations that are candidate for transformation. Past research showed that these kinds of transformation can lag for years with forgotten instances popping out from time to time as other evolutions bring them into light. In this paper, we evaluate three distinct code search approaches ("structural", based on Information Retrieval, and AST based algorithm) to find code locations that would require similar transformations. We validate the resulting candidate locations from these approaches on real cases identified previously in literature. The results show that looking for code with similar roles, e.g., classes in the same hierarchy, provides interesting results with an average recall of 87% and in some cases the precision up to 70%.

I. INTRODUCTION

Developers sometimes perform sequences of source code transformations in a systematic way [START_REF] Nguyen | A study of repetitiveness of code changes in software evolution[END_REF], [START_REF] Santos | System specific, source code transformations[END_REF]. These sequences are composed of small code transformations (e.g., create a class, then extract a method to this class), which are applied to groups of somehow related code entities (e.g., methods in sibling classes). Due to the repetitive nature of these transformations, manually applying them is a tedious and error-prone task [START_REF] Kim | Recommendation Systems in Software Engineering[END_REF].

Existing tools automate the application of repetitive transformations [START_REF] Kim | Scripting parametric refactorings in java to retrofit design patterns[END_REF]- [START_REF] Zhang | Interactive code review for systematic changes[END_REF]. However, once the developers know the sequence of transformations to perform, finding all the code entities that are candidates for these transformations involves inspecting the entire source code of the system. In fact, past research showed that developers forget code locations that are candidate for transformation, some of these locations popping out from time to time as other evolutions bring them to light [START_REF] Fry | A human study of fault localization accuracy[END_REF].

To find candidates for a given transformation, we start from the assumption that similar code entities might be transformed in a similar way. Thus, clone detection and code search tools can be used to identify these candidates [START_REF] Roy | Comparison and evaluation of code clone detection techniques and tools: A qualitative approach[END_REF]- [START_REF] Armaly | A case study of automated feature location techniques for industrial cost estimation[END_REF]. In general, these tools use as input the source code of the system and one source code example. Figure 1 (upper part) depicts the expected behavior of these tools. As a result, code search tools generate a list of code locations that are similar to the given example. But, they still require that, for each candidate, developers manually: (i) check whether the candidate is a correct recommendation and, if so, (ii) effectively transform the code. Fig. 1. Searching code with code. Our approach retrieves code entities from an example and refine the results based on a given recorded sequence of transformations.

In this paper, we evaluate three different code search approaches, using basic concepts from related work:

Structural searches for code placed in similar locations, e.g., same package, superclass, etc.; AST-based searches for code entities with similar Abstract Syntax Trees (AST); and IR-based searches for code entities with similar vocabulary, extracted from identifiers and comments.

Prior work shows that false positives results, i.e., incorrectly reported candidates, are bad for both usability and adoption of such approaches [START_REF] Ruthruff | Predicting accurate and actionable static analysis warnings: An experimental approach[END_REF]- [START_REF] Sadowski | Tricorder: Building a program analysis ecosystem[END_REF]. We further propose to improve precision on the code search results by trying to apply the sequences of transformations in each candidate, see Figure 1 (lower part).

The main contributions of this paper are: (i) we present three methods to automatically compute a list of candidates locations for application of a given sequence of code transformations; (ii) we check the correctness of the recommendations proposed by these approaches; and (iii) we evaluate and compare all three methods. This paper is organized as follows: Section II provides a motivating example of the sequence of transformations we are working with. Section III provides a background of code search approaches in the literature. Section IV presents our approach to find and validate candidates for transformation. Section V presents our case study with real-world systems. Section VI presents threats to validity of our study and Section VII concludes.

II. MOTIVATING EXAMPLE

In this section, we present an illustrative example of repetitive source code transformations.

We extracted this example from JHOTDRAW 1 , a framework for technical graphics in Java. Specifically in version 7.4.1, developers replaced the color system hierarchy to inherit the Java's AWT API.

Several modifications were done to implement this replacement, and a total of eight classes were systematically modified. Figure 2a shows the partial diff between source code of the class HSLRGBColorSystem and the new class HSLColorSpace, in terms of added (+) and removed (-) lines. Figure 2b shows the same sequence of transformations, now applied to the class CMYKNominalColorSystem.

Considering both examples in Figure 2, we observe the same sequence of transformations:

• Import class ColorSpace from Java AWT (line 3 in Figure 2a);

• Rename the class to "*ColorSpace" (line 5);

• Extend ColorSpace (line 5);

• Implement new interface NamedColorSpace (line 5);

• Implement the Singleton design pattern (lines 7-18). We introduce the definitions and terminology that we use in the rest of this article. Not all of them are well-known or standard terminology in the context of code search and change recommendation, therefore we define them explicitly: Definition 1 A macro (also known as: transformation pattern [START_REF] Santos | Recording and replaying system specific, source code transformations[END_REF], systematic edit [START_REF] Zhang | Interactive code review for systematic changes[END_REF], or edit script [START_REF] Meng | LASE: Locating and applying systematic edits by learning from examples[END_REF]) is a sequence of code transformations originally composed by the developer which can be automatically performed in several code locations.

In the beginning of this section, we described the transformations that were systematically performed in JHOTDRAW. This description would be a starting point to create a macro for this system.

The general goal is to have tools to apply automatically macros in all the code locations where they need to be. This goal supposes that the macro can actually be replayed in different locations (not treated in this paper, see [START_REF] Santos | Recording and replaying system specific, source code transformations[END_REF], [START_REF] Negara | Mining fine-grained code changes to detect unknown change patterns[END_REF]), then we can find all the locations that are candidate for such a replay. For example, from both cases in Figure 2, one could notice that both modified classes inherited from AbstractColorSystem before the transformations took place. One could use this information as a hint to identify other classes that need to be modified.

Definition 2 An application condition for a macro, selects from all entities in a system (classes or methods in this paper), the ones that must be transformed by the macro.

In the concrete example, the application condition would be: all the subclasses of AbstractColorSystem in JHOTDRAW. However, it might not be clear for the developer whether this simple condition is correct, necessary, and/or sufficient to find all the correct locations in the system. In other systems, the condition might be more complex than just considering the hierarchy of a specific class.

Figure 2 shows that, when applying the Singleton design pattern, developers did not set the constructor accessibility to private (line 16). Also, two other classes (not shown here) did not implement the Singleton pattern at all. Such errors and omissions could lead to inconsistent code. When it comes to bigger systems, this situation could be even worse. Santos et al. [START_REF] Santos | System specific, source code transformations[END_REF] also showed cases in the ECLIPSE IDE in which the transformations were not applied to all the opportunities that should have been transformed.

To automatically recommend source code locations that are likely candidates to apply a macro, one needs examples of such locations, given by the developers, from which the application condition can be abstracted. Definition 3 A code example is a location in the source code where the macro was successfully applied. In practice this example consists in a single source code entity (a class or a method) where to start replaying the macro.

As an example, the macro on JHOTDRAW starts by adding an import declaration to the class HSLRGBColorSystem. The first location example is the one where the macro is created. 2This first example gives initial data on the entities modified and their properties. Definition 4 A candidate location is an entity in the source code that is candidate to be a code example. Candidate location can be wrong in two senses: (i) the macro cannot be replayed on it; or (ii) the macro could be replayed, but the developer does not wish to do so because it does not meet the, possibly informal, application conditions.

III. RELATED WORK

In this section, we discuss related work on recommending candidates for source code transformations. We do not include change impact analysis approaches in this paper; these approaches suggest which code entities should change, but they do not recommend which transformations should be performed. In this section, we classify code search approaches according to the goal of the recommendations.

Querying Similar Code Entities: Code search tools propose to locate source code based on a given query [START_REF] Shepherd | Sando: An extensible local code search framework[END_REF]- [START_REF] Damevski | A field study of how developers locate features in source code[END_REF]. Some tools retrieve code samples from vast repositories of source code [START_REF] Reiss | Semantics-based code search[END_REF]- [START_REF] Sindhgatta | Using an information retrieval system to retrieve source code samples[END_REF]. Some approaches rely on the declaration of queries using Domain Specific Languages (DSL) [START_REF] Wang | Matching dependence-related queries in the system dependence graph[END_REF], [START_REF] Martin | Finding application errors and security flaws using PQL: A program query language[END_REF]. Other approaches look for similarities between Abstract Syntax Trees (AST) [START_REF] Balachandran | Query by example in large-scale code repositories[END_REF]. Opposed to the existing code search approaches, we do not intend to provide code samples from other repositories of source code. Our goal is to find samples that require similar transformations within a specific software system. McIntyre and Walker [START_REF] Mcintyre | Assisting potentially-repetitive smallscale changes via semi-automated heuristic search[END_REF] proposed REVERB, a tool that observes code edits from the developer in the ECLIPSE IDE. Then, it searches for code with dependencies in common, such as the methods being called, to find where small-scale changes should be applied. Another tool that leverages the dependency relations among various program elements is AUTOQUERY [START_REF] Wang | Autoquery: automatic construction of dependency queries for code search[END_REF]. It relies on conversion of code snippets into program dependence graphs and searches using dependence-based code search technique. However, for most of the approaches in this category, the tool only provides the list of code entities that should be transformed next. The transformation effort is still required from the developer.

Recommending Refactoring Opportunities: Several approaches propose to identify code in which a refactoring must be applied. For example, Khomh et al. propose the detection of God classes to recommend the application of Extract Class refactoring [START_REF] Khomh | A bayesian approach for the detection of code and design smells[END_REF]. Bavota et al. [START_REF] Bavota | Recommending Refactoring Operations in Large Software Systems[END_REF] discuss state of the art approaches that recommends the application of other refactorings described in Fowler's catalog [START_REF] Fowler | Refactoring: Improving the Design of Existing Code[END_REF]. Refactorings such as Extract Class have well defined purposes, therefore these approaches search for very specific properties in source code for recommendation. Most of the approaches rely on syntactic dependencies, such as method calls and shared variables [START_REF] Bavota | Automating extract class refactoring: An improved method and its evaluation[END_REF]- [START_REF] Fokaefs | Decomposing object-oriented class modules using an agglomerative clustering technique[END_REF]. Some other approaches rely on code metrics, e.g., too many methods in a class [START_REF] Joshi | Concept analysis for class cohesion[END_REF]- [START_REF] Simon | Metrics based refactoring[END_REF]; and conceptual information retrieved from the source code vocabulary [START_REF] Bavota | Improving software modularization via automated analysis of latent topics and dependencies[END_REF], [START_REF] Dig | Automated detection of refactorings in evolving components[END_REF]. In different way, Schuster et al. proposed refactoring at compilation time [START_REF] Schuster | Macrofication: Refactoring by reverse macro expansion[END_REF]. Their idea is to match a pattern-template macro with code fragments and replaces them with equivalent but simpler pattern. In our work, the transformations we found are specific to the system on which the developer is working. The rationale behind the transformations, i.e., the application condition, is different for each system.

Recommending Other Recurring Transformations: LIB-SYNC [START_REF] Nguyen | A graph-based approach to api usage adaptation[END_REF] and APIEVOLUTIONMINER [START_REF] Hora | APIEvolu-tionMiner: Keeping API evolution under control[END_REF] focused on updating the API on which a system depends. The tools extract code transformation rules from other systems that updated to the same API usages in the past, then they recommend locations in source code and transformations to replace old API calls to new ones. FIXWIZARD [START_REF] Nguyen | Recurring bug fixes in object-oriented programs[END_REF] focused on recurring bug fixes. In the code history of five real open-source projects, up to 45% of bug fixing transformations were repetitive. Based on the recurring examples the authors found, the tool also recommends both code locations and required transformations to fix the bug. PR-MINER [START_REF] Li | PR-miner: Automatically extracting implicit programming rules and detecting violations in large software code[END_REF] focused on programming rules, e.g., function b() must be called after function a(). The rules are also extracted from the code history of real software systems, in which inconsistencies in these rules led to bugs. The tool also locates code that violates these rules and recommends transformations to fix them. Similar to refactoring approaches, both API usage and bug fix approaches search for very specific properties in code, e.g., API calls and known patterns that would introduce bugs. Moreover, the recommended transformations are mostly extracted from the code history of the system under analysis. In our work, the transformations are considered as occasional but repetitive. Therefore, we require support for the application of these transformations in situ.

Using Transformations to Find Recommendations: Automated code transformation has been proposed in the literature to provide support for developers to compose their own transformations. More recently, some tools proposed to analyze the code under transformation to find other locations in which they could be performed. Andersen et al. proposed patch inference techniques to derive a term-replacement from diff output [START_REF] Andersen | Generic patch inference[END_REF], [START_REF] Andersen | Semantic patch inference[END_REF]. Thung et al. proposed a recommender system to offer code change candidates that enable backporting of Linux drivers code [START_REF] Thung | Recommending Code Changes for Automatic Backporting of Linux Device Drivers[END_REF]. LASE [START_REF] Meng | LASE: Locating and applying systematic edits by learning from examples[END_REF] and CRITICS [START_REF] Zhang | Interactive code review for systematic changes[END_REF] rely on code examples from the developer, e.g., the source code before and after the developer fixed a bug in a method. The tools calculate unmodified statements in the modified methods, to further search for methods containing similar statements by matching nodes in the AST. Both tools rely on transformations related to bug patches, which generally comprise few and very localized transformations (e.g., inside a method). The transformations we study in this paper have a higher level of granularity, including from the addition of statements in a method to modifying the hierarchy of classes (e.g., the example in Section II). Therefore, our validation approach, i.e., trying to apply transformations to candidates, require an approach that automates more complex transformations.

IV. RECOMMENDING CODE LOCATIONS

In this section, we present our approaches to find code locations that are candidates for systematic transformation. Our approach has specific requirements:

• the source code of the entire system must be available.

As a starting point, all entities in the entire source code are candidate locations;

• a macro (see Section II) has been created (optional);

• one or more code examples have been specified. The code entity on which the macro was recorded already counts as one example. The goal of our approach is to find other locations in the source code that are similar to the code examples and, therefore, seem to require similar transformations. We tested code search approaches to recommend a list of candidate locations where to re-apply the transformations.

The code search approaches we use are inspired by approaches in the literature. First, we search for code in similar locations, e.g., same package, same superclass, etc. (Section IV-A). Second, we search for code with similar structure, as represented by their ASTs (Section IV-B). Third, we search for code with similar identifiers and comments (Section IV-C). And fourth, we use the macro (when available) to refine the list of candidate locations by checking whether the transformations can be performed on them (Section IV-D).

A. Structural approach

Nguyen et al. [START_REF] Nguyen | Recurring bug fixes in object-oriented programs[END_REF] identified recurring bug fixes in the code history of five real open-source systems. The recurring fixes often occurred in code locations with similar properties, such as methods containing code clones, classes extending the same superclass or implementing the same interface, methods overriding the same parent method, or classes implementing the same design pattern.

Based on these findings, we implemented a location code search approach which depends on two or more code examples. We call this approach "Structural" because it considers basic information of where the code is located. We use concrete example from JHOTDRAW (presented in Section II) to show how the approach works. In this case, developers modified two classes with similar basic properties, as shown in Table I. Both classes belong to the same package ("pckg") and inherit from the same superclass ("sup."). For classes, the properties include their package, superclass and class names. For methods, we would compute the properties of their classes (i.e., package, superclass and class names), as well as the signature of the method. The structural approach then searches other entities in the system sharing the same similar properties. In the example presented in Table I, the approach searches classes in package org.jhotdraw.color which inherit from AbstractColorSystem. The name of the class is only considered when one searches for similar methods.

The search is an all-inclusive one, i.e., it assumes that all classes (or methods) in the same location, whether physical (e.g., package) or logical (e.g., superclass), require similar transformations. This means that in the worst case, i.e., no similar properties are found, the result will be all the classes in the system.

B. AST-based approach

In Section III, we mentioned tools that analyze code examples to find candidates for transformations. These tools, namely LASE [START_REF] Meng | LASE: Locating and applying systematic edits by learning from examples[END_REF] and CRITICS [START_REF] Zhang | Interactive code review for systematic changes[END_REF], look for methods that have similar statements in comparison with two or more code examples. In some sense, both tools look for instances of clones, relying on the AST of methods under analysis. Based on this idea, we implemented a code search approach which depends on a single code example (as opposed to the prior work that required two). 3In the concrete example with JHOTDRAW, we focus on comparing the constructor of the class HSLColorSpace for illustrating example. In a practical setting, the entire class will be analyzed because it was the first entity affected by the transformations in our example (see Section II). Assuming we want to know whether CMYKNominalColorSpace is a good candidate to replay the macro, we would try to match the source code between the constructors. Figure 3 presents a diff between these two constructors.

First, we use a greedy text-based algorithm to compute the longest common subsequence (LCS) [START_REF] Myers | An o(nd) difference algorithm and its variations[END_REF] of code. When two methods have different source code, the LCS algorithm aligns what is the most common code between them. In this case, both constructors have the same call to super and the same reference to class ColorSpace. Therefore, the longest common subsequence in this case is "super(ColorSpace.".

The approach then retrieves the sequence of nodes, in the AST of both methods, that contains this subsequence. It is worth noting that the LCS algorithm is used only to retrieve the most similar code and, consequently the sequence of nodes that contains this code. From there on, we compare each node of the sequence separately. In this example, the computed sequence of nodes comprises:

• the invocation of the constructor in the superclass (super(ColorSpace, int)), which also contains

• the reference to the class ColorSpace,

• the access of an attribute in class ColorSpace (TYPE_HSV, for class HSLColorSpace), and

• the declaration of an integer value (3).

The constructor in HSLColorSpace is then four nodes similar to the one in CMYKNominalColorSpace. This result is used to rank the candidate set, i.e., to determine which locations are more similar to the example. The top ranking locations are then considered candidate locations.

C. IR-based Approach

Information retrieval (IR) techniques use lexical analysis to search documents relevant to a query (the best known example would be the Google search engine). One of the most widely used searching model is called bag-of-words. Under this model, text (in our case, source code text) is represented as unordered sets of terms. Then, given a query, which is also a set of terms, the IR engine retrieves documents that contain similar terms. To account for the relative importance of a term in all documents of the corpus and in each individual document, a reasonable similarity function is the cosine similarity of term frequency and inverse document frequency, known as TF-IDF [START_REF] Baeza-Yates | Modern Information Retrieval -the concepts and technology behind search[END_REF].

We implemented a search engine which indexes source code. This approach views classes (or methods) as documents and terms are retrieved from identifiers and comments. We process each term to (i) split identifiers with the camel case and underscore naming convention; (ii) remove affixes and suffixes, (ii) discard common words that do no add meaning (stop-words); and (iii) discard words that are keywords from the programming language (additional stop-words). Table II shows set of terms extracted from HSLRGBColorSystem, where the term "satur" is the result of processing the original term "saturation".

This approach works with a single code example as the previous one. This code example is processed and provided to satur color count system compon green light blue base primari hslrgb the search engine as a query. Our IR-based approach computes a numeric score on how much each source code entity is similar to the query (the code example). Then, we rank the candidate set, e.g., all the classes, according to their cosine similarity. The top ranking entities are then considered as candidate locations.

Again, consider the case on Section II in which a developer changes the class HSLRGBColorSystem. Table III shows the top ranked entities for this "query", according to the cosine similarity with HSLRGBColorSystem.

D. Replayable Approach

Given a list of candidates for transformation, it is not clear for a code search approach whether the transformations can be actually replayed in each candidate location. To validate their recommendations, we propose to use the macro (when it is available) and try to replay it. If the replaying operation fails, we assume the candidate location is a wrong one and we remove it from the list of recommendations.

Concretely, we extended MACRORECORDER [START_REF] Santos | Recording and replaying system specific, source code transformations[END_REF], the tool we use in this paper to record and replay macros. The replaying operation will fail if: (i) an exception is thrown during the transformation, i.e., the code entity to be transformed could not be retrieved in the candidate location; or (ii) the transformations in the macro produced code that was not compilable, consequently the tool rolls back the all the changes done by the macro.

It is worth noting that MACRORECORDER does not perform the transformations immediately on code. The tool first performs them on a model to check preconditions and display the modified code to the developer, who will ultimately accept or reject the modifications. Moreover, it is expected that the macro will not fail replaying the macro in a correct candidate.

V. EVALUATION

In this section, we evaluate the code search approaches proposed in this paper. Section V-A presents the real-world systems under analysis and the macros that were recorded for them. We describe the metrics we used in this evaluation in Section V-B. Then, Section V-C presents how we compute candidate locations for the transformations. We evaluate structural, AST-based, and IR-based approaches in Section V-D. We evaluate our fourth approach, i.e., using the macro to validate the recommendations, in Section V-E. We discuss two approaches that compute ranked recommendations, namely AST-based and IR-based approaches, in Section V-F.

A. Target Systems

Our dataset is based on sequences of transformations found in previous work [START_REF] Santos | System specific, source code transformations[END_REF], [START_REF] Santos | Recording and replaying system specific, source code transformations[END_REF]. In total, we selected two Java systems and five Pharo4 systems, described as follows.

Eclipse went through a considerable restructuring to integrate the OSGi technology. We focused in the user interface plugin, which was separated into five new plugins in the version 3.0. JHotDraw is a framework for technical graphics. Its restructuring aimed at specializing the interface of color spaces (as discussed in Section II). PetitDelphi is a parser for Delphi that has been enhanced to generate an AST from a tokenized tree. The restructuring aimed at pruning the generated AST nodes. PetitSQL is another parser, for SQL. Its rearchitecting focused on correcting API usage of the grammar. PackageManager is a package management system, similar to Maven, for Pharo. Its rearchitecting focused on changing the interface to access package metadata. MooseQuery is a framework to query dependencies between entities in the FAMIX model [START_REF] Ducasse | MSE and FAMIX 3.0: an Interexchange Format and Source Code Model Family[END_REF]. It was restructured to be language independent (the original implementation focused on object-oriented languages). Pillar is a language and family of tools to write and generate documentation in text, PDF, HTML pages, etc. The tests were restructured in order to provide a simpler and reusable interface.

Table IV summarizes descriptive data about the systems. Several of these systems are small, however they are written in Pharo which is a concise language. For an automation tool, the repetitiveness of the transformations is more important than the size of the system (see Threats to Validity in Section VI).

In total, we select 13 real sequences of transformations that were found in the history of their respective systems. For some systems (ECLIPSE, PETITSQL, PACKAGEMANAGER, and MOOSEQUERY) we selected more than one sequence of transformations. Table V presents descriptive data about our dataset. It describes, for each case: the number of occurrences of the repetitive task, and the number of transformations involved for each task, i.e., the number of transformations in the sequence. We use this set of occurrences as our oracle.

B. Evaluation Metrics

In this section, we present the metrics we use in the evaluation. Our approaches return a list of candidate locations as a result (the Candidates set). For each instance of macro, the oracle set represents the code locations that were in fact modified by the developers (the Correct set).

Precision is the percentage of identified candidates that are correct. Recall measures the percentage of correct locations identified by a given approach. F-measure (F 1 ) is the harmonic mean of precision and recall. These metrics are also described more formally as follows:

precision = |Correct ∩ Candidates| |Candidates| (1) recall = |Correct ∩ Candidates| |Correct| ( 2
)
F 1 = 2 * precision * recall precision + recall (3)
Typically, a better recall comes with lower precision, and vice-versa. On one hand, recall is important because we want to avoid omissions, i.e., the approach should be able to find all the correct transformation opportunities. On the other hand, as a recommendation tool for the developer, it is also important that the approach returns as little incorrect candidates as possible (i.e., a high precision). Prior work shows that incorrect candidates (false positives), are bad for both usability and adoption of such approaches [START_REF] Ruthruff | Predicting accurate and actionable static analysis warnings: An experimental approach[END_REF]- [START_REF] Sadowski | Tricorder: Building a program analysis ecosystem[END_REF]. Therefore, we hope for higher precision rather than higher recall.

On top of these three metrics, we added two more for AST-based and IR-based approaches. Both rank their list of candidates in decreasing order of similarity. In this case, special ranking metrics, such as the Discounted Cumulative Gain (DCG) [START_REF] Järvelin | IR evaluation methods for retrieving highly relevant documents[END_REF] and the Precision at n (P@n) [START_REF] Craswell | Precision at n[END_REF], were proposed by practitioners to weight correct recommendations based on their ranking position. Concretely, those metrics weight correct results near the top of the ranking higher than in lower positions.

The assumption is that a developer is less likely to consider elements near the end of the list.

With DCG, see Equation 4, rel i indicates the relevance of an entity at rank i and decreases as i augments. In Equation 5, r stands for relevant candidates retrieved at rank size of n.

DCG p = p i=1 2 reli -1 log 2 (i + 1) (4)
P @n = r n (5)
We compare the AST-based and IR-based approaches using these metrics. It is worth noting that DCG is not normalized. Therefore, we only compare both approaches under the same setting, i.e., for the same system under analysis. Moreover, DCG is cumulative; it increases as more candidates are provided. Therefore, we can only compare both approaches under the same candidate list as well.

C. Finding Candidates for Transformation

We compute candidates locations for transformation using the approaches described in Section IV. Our approaches require some input which is retrieved from target systems as follows.

• The versions of the source code for each system are indicated in Table IV. All classes and methods of the system are used as input as specified in Section IV.

• For Pharo systems, we used the macros as recorded by MACRORECORDER tool [START_REF] Santos | Recording and replaying system specific, source code transformations[END_REF]. This tool is also used to experiment with our "fourth" approach that proposes to filter the candidate list by dropping those candidates where the macro cannot be replayed (Section IV-D).

For systems written in Java, we have no macro replaying tool for now and we could not test this combined approach.

• Our approaches require one (for AST-based and IRbased) or more (for structural) code examples. These code examples are selected randomly from all the actual occurrences of the macro (see again Table V).

Each approach will generate a list of candidates for transformation from which we can compute precision and recall or DCG metric according to our oracle.

D. Overall Results

Table VI presents precision and recall values for structural,

AST-based and IR-based approaches. We observe that the Structural approach is performing reasonably well (especially considering its simplicity) with an average precision of 60%. Although this approach only considers package, class, and method names, all recommendations are correct (100% precision) in five (out of 13) cases. Concerning recall, the structural approach also gives good results on average (87%), and eight out of 13 cases with perfect recall. The F-measure results confirm better results for Structural approach.

Given the simplicity of the Structural filter, one could suspect that good results might be linked to a lower number of classes in the systems under analysis, however Spearman correlation shows weak correlations (ρ = 0.36 for precision and ρ = -0.31 for recall). Therefore that does not seem to be the case.

We observed overestimation with Structural approach in some cases as well. In four cases, less than 25% of candidates are correct. For example, in PETITDELPHI, developers systematically removed methods of one class which represented a specific grammar rule. The structural approach recommended all the methods of this class as candidate locations, whether they did represent this grammar rule or not. The result is due to the Structural approach which does not look at the AST. Similar situation occurred in PETITSQL II.

In ECLIPSE I and PACKAGEMANAGER IV, a few candidates were not found because they were contained in other package than the one from the examples. Similarly, ECLIPSE II and JHOTDRAW, some few candidates inherited from a different superclass than the one from the code examples. These cases were considered exceptions, as can be seen by the very good recall, i.e., these few cases did not represent the majority of the gold standard.

The AST-based and IR-based approaches achieved an average precision around 40%. Recall average values for these two methods are 79% and 67% respectively. Regardless of the lower precision and recall, these two approaches raised important scalability issues. For example, performing code search around one thousand methods in PETITDELPHI (a medium system in our dataset), took more than 15 minutes. It turns out that comparing source code ASTs or processing identifiers takes too long to deploy such approaches into the development environment.

Summary: The Structural approach gives better results concerning both precision and recall. These results indicate that repetitive transformations usually affect similar code locations, e.g., classes in the same package, with the same superclass, or methods in the same class.

E. Replayable approach results

In this section, we add to the three approaches evaluated above the idea of validating the candidate locations by trying to replay the macro on them. We report here the results for Pharo systems because this is the context in which we have the MACRORECORDER tool to replay macros. We report only precision results because it is expected that macros Table VII shows that the precision increased in four out of ten cases, with two very significant increases observed in PETITSQL I (from 24% to 85%), and PILLAR (from 19% to 93%). Similarly to PETITDELPHI and PETITSQL, the structural approach recommended all the methods in the hierarchy of document classes in PILLAR. We manually inspected each case and, although MACRORECORDER could replay the macro, the resulting code would have been incorrect. However, such behavior does not present a serious threat because the transformations are effectively performed by MACRORECORDER after inspection from the developer. Moreover, with the high precision (93%) we conclude that these cases were exceptions.

Summary: Although simple, the Structural-Replayable approach gives very good results with an average precision of 70%. The replayable filter is also easy to implement (when there is a record-and-replay tool available) and it improves precision for all the other approaches.

F. Combining Structural with AST-based and IR-based approaches

In particular cases, e.g., PILLAR, we observed that AST-based and IR-based approaches performed better than the structural one, despite some performance issues. However, the structural approach performed better and required less resources in most of the systems. In this section, we use the list of candidates generated by the structural approach as the candidate set for AST-based and IR-based approaches (instead of the entire system). For this analysis, we focus on the results of structural approach before validation with the macro. Thus, we include the Java systems in the evaluation.

Table VIII presents DCG results. This metric measures the entire ranking. The AST-based approach performed better than the IR-based one in all but one case, e.g., ECLIPSE I. Since DCG is a cumulative metric, the results in Table VIII indicate that the AST-based approach places correct recommendations in a higher position in comparison with the IR-based approach. Table IX presents P @n results. In most of the systems, a higher precision at early positions at the ranking also implied a higher DCG. In ECLIPSE I, precision results are the same for both approaches, however the AST-based one have lower DCG. This result is also caused by DCG's cumulative property, i.e., the IR-based approach places correct recommendations (after the 20 th position) in a higher position in comparison with the AST-based one. However, both approaches did not improve PETITDELPHI's precision. In Section V-D, we discussed that developers removed all the methods representing a particular grammar rule. This particularity is represented by using the operator "," (a comma) 5 . The IR-based approach does not consider this operator as a term; instead, the similarity considered only the name of the method. Moreover, the AST-based approach only produce high similarity for methods with the same number of comma operators.

Other limitations appeared when the candidates have few properties in common. For example, in MOOSEQUERY II, the methods transformed by the macro have short names (e.g., from and to), and they only share one return statement in common. Thus, both AST and IR similarities will be low even between correct candidates; the recommendations will then be sorted with incorrect ones. Similar cases occurred in PETITSQL I and PACKAGEMANAGER IV.

Summary: The AST-based approach produced more correct ranking in comparison with the IR-based approach. All but one of the 13 cases were better ranked by AST similarity for top-20 recommendations.

VI. THREATS TO VALIDITY

We now discuss threats to the validity of our study: Internal Validity: The authors were among the developers in four of the systems under analysis. This could mean that there is a bias toward the expected searching results. Thus, one could assume that results are less significant, because we designed a searching process looking at our own source code. While the identification bias is relevant, it does not affect the essence of 5 Pharo allows one to override operators such as "," or "=".

the study. The repetitive transformations we found occurred before our study, and therefore they were not influenced by our approach. Our participation in the development only helped us to re-discover them.

External Validity: In this study we considered 13 cases where we found repetitive transformations. It is not clear whether conclusions generalize beyond this setting. Most of the systems under analysis are small. One may argue that it is easier to find candidate locations in a smaller system. However, Santos et al. [START_REF] Santos | System specific, source code transformations[END_REF] showed that developers missed some (out of 21) candidate locations for a small system such as PETITDELPHI. In this paper, we also studied a more complex system, ECLIPSE, in which systematic transformations occurred in the past. However, the cases in PETITSQL and PACKAGEMANAGER, considered as small, seem to indicate that the size is not an issue. The macros we found in these systems repeated 98 and 66 times, respectively.

Construct Validity: In our study, we select at random code examples based on the occurrence of repetitive transformations in the past. One might argue that the code search results are highly dependent on the selection of these examples. To alleviate this threat, we executed the structural approach several times. This approach is the one that produces the preliminary candidates for the remaining approaches. We report in this paper the results in which the selection of code examples produced most candidate locations.

In our study, we use the occurrences of the macro as our oracle. However, previous work on this dataset suggested that developers might have missed some transformation opportunities. We also acknowledge this threat. In a practical setting, the list of candidates that our approach produces, either selected by the macro or ranked by AST or lexical similarity, is shown to the developer as a recommendation. Our approach still requires the developer to accept (or reject) the recommendation, either it will be a surprising recommendation or not, because some of the code locations may be found easily by manual inspection, and others may not.

VII. CONCLUSION

From time to time developers need to systematically apply sequences of source code transformations in a software. Due to the repetitive nature of this task, solutions where proposed to help create the repetitive sequence and reproduce it on different locations in a system.

In this paper, we present different solutions to identify automatically all the locations where such a repetitive sequence of transformations should be applied. We evaluated these three solutions on real cases of sequences that had been identified in existing publications [START_REF] Santos | System specific, source code transformations[END_REF], [START_REF] Santos | Recording and replaying system specific, source code transformations[END_REF]. These examples cover seven different systems (small to large) in two OO languages (Java and Pharo), and a total of 13 examples of sequences specific to the systems where they were found.

Our approaches receive as input one or two code examples and try to generalize these examples to all possible locations on which the sequence should be applied. The results showed that a simple filtering based on "structural analysis" (e.g., classes in the same package, or methods in the same class hierarchy) already produce good results in terms of recall (87% in average) and precision (70% in average). These good results can be further improved by adding an analysis on the AST.

  1 http://www.jhotdraw.org/ (a) Partial diff between class HSLRGBColorSystem in version 7.4.1, and HSLColorSpace in version 7.5.1. (b) Partial diff between CMYKNominalColorSystem in version 7.4.1, and CMYKNominalColorSpace in version 7.5.1.

Fig. 2 .

 2 Fig. 2. Code transformations performed in JHOTDRAW to improve the color system hierarchy.

Fig. 3 .

 3 Fig. 3. Diff between constructors of classes HSLColorSpace and CMYKNominalColorSpace in JHOTDRAW.

TABLE I PROPERTIES

 I FROM EXAMPLES IN JHOTDRAW. PROPERTIES ARE EXTRACTED FROM THE NAME OF THE CLASS ITSELF, THE NAME OF THE PACKAGE, AND THE NAME OF THE SUPERCLASS (SEE ALSO FIGURE 2).

	class	HSLRGB-ColorSystem	CMYKNominal-ColorSystem
	pckg	org.jhotdraw.color	org.jhotdraw.color
	sup. AbstractColorSystem AbstractColorSystem

TABLE II SET

 II OF TERMS EXTRACTED FROM CLASS HSLRGBCOLORSYSTEM.

TABLE III MOST

 III SIMILAR CLASSES TO HSLRGBCOLORSYSTEM.

	Class name	Similarity
	RGBColorSystem	0.3551
	HSLRYBColorSystem	0.1869
	HSVRYBColorSystem	0.1399
	HSVRGBColorSystem	0.0706
	AbstractColorSystem	0.0417
	CMYKICCColorSystem	0.0342
	CMYKNominalColorSystem	0.0302
	CompositeColor	0.0255
	AbstractHarmonicRule	0.0228
	DefaultHarmonicColorModel	0.0219

TABLE IV DESCRIPTIVE

 IV METRICS OF OUR TARGET SYSTEMS. THE FIRST TWO SYSTEMS ARE IN JAVA, THE OTHER FIVE ARE WRITTEN IN PHARO.

	System (version)	Packages Classes KLOC
	Eclipse-UI (2.1)	68	2253	185
	JHotDraw (7.4.1)	39	614	59
	PetitDelphi (0.210)	7	313	8
	PetitSQL (0.34)	1	2	0.3
	PackageManager (0.58)	2	117	2.5
	MooseQuery (0.245)	2	3	0.2
	Pillar (0.178)	24	278	14

TABLE VI STRUCTURAL

 VI , AST-BASED, AND IR-BASED RESULTS. Occ.: NUMBER OF OCCURRENCES OF THE ORACLE (AS SHOWN IN

TABLE V )

 V ; Prec.: PRECISION; Rec.: RECALL; F 1 : HARMONIC MEAN OF PRECISION AND RECALL.

		Occ.		Structural			AST-based			IR-based
	Macro		Prec.	Rec.	F 1	Prec.	Rec.	F 1	Prec.	Rec.	F 1
	Eclipse I	26	0.68	0.81	0.73	0.05	0.12	0.07	0.36	0.61	0.45
	Eclipse II	72	1.00	0.92	0.95	0.21	0.42	0.28	0.08	0.16	0.10
	JHotDraw	9	1.00	0.89	0.94	0.06	0.42	0.10	0.29	1.00	0.44
	PetitDelphi	21	0.12	1.00	0.21	0.04	1.00	0.07	0.02	0.04	0.02
	PetitSQL I	6	0.24	1.00	0.38	0.27	1.00	0.42	0.16	0.66	0.25
	PetitSQL II	98	0.40	1.00	0.57	0.32	1.00	0.48	0.94	0.32	0.47
	PackageManager I	66	1.00	1.00	1.00	0.74	1.00	0.85	0.92	0.89	0.90
	PackageManager II	19	1.00	1.00	1.00	1.00	1.00	1.00	0.54	1.00	0.70
	PackageManager III	64	1.00	1.00	1.00	1.00	1.00	1.00	0.87	1.00	0.93
	PackageManager IV	7	0.66	0.57	0.61	0.66	0.57	0.61	0.05	1.00	0.09
	MooseQuery I	16	0.41	1.00	0.58	0.34	1.00	0.50	0.19	1.00	0.31
	MooseQuery II	8	0.12	0.20	0.15	0.02	0.80	0.03	0.16	0.10	0.12
	Pillar	99	0.19	1.00	0.31	0.77	1.00	0.87	0.75	1.00	0.85
		Average	0.60	0.87	0.64	0.42	0.79	0.48	0.41	0.67	0.43
	are configured to be replayed on correct candidate locations.
	Therefore, the replayable approach does not affect recall.

TABLE VII REPLAYABLE

 VII APPROACH RESULTS. PRECISION RESULTS WITHOUT REPLAYABLE APPROACH WERE PRESENTED IN TABLE VI.

		Structural	AST-based	IR-based
		+Replayable +Replayable +Replayable
	Macro	Prec.	Prec.	Prec.
	PetitDelphi	0.12	0.04	0.02
	PetitSQL I	0.85	0.85	0.57
	PetitSQL II	0.40	0.32	0.94
	PackageManager I	1.00	0.74	0.92
	PackageManager II	1.00	1.00	0.54
	PackageManager III	1.00	1.00	0.87
	PackageManager IV	0.66	0.66	0.05
	MooseQuery I	0.66	0.48	0.31
	MooseQuery II	0.40	0.10	0.33
	Pillar	0.93	0.93	0.93
	Average	0.70	0.61	0.54

TABLE VIII DCG

 VIII RESULTS FOR AST-BASED AND IR-BASED APPROACHES.

	Macro	AST-based	IR-based
	Eclipse I	4.25	9.36
	Eclipse II	7.03	2.27
	JHotDraw	3.64	3.59
	PetitDelphi	4.12	1.76
	PetitSQL I	3.31	1.52
	PetitSQL II	20.40	19.46
	PackageManager I	15.61	14.78
	PackageManager II	6.81	6.34
	PackageManager III	15.28	13.59
	PackageManager IV	2.74	1.89
	MooseQuery I	5.61	0.33
	MooseQuery II	2.16	0.50
	Pillar	20.28	19.99
	Average	11.12	9.54

TABLE IX AST

 IX -BASED AND IR-BASED RESULTS. P@n: PRECISION OF THE CANDIDATES AT THE TOP-5, 10, AND 20 POSITION IN THE RANKING.

		P@5	P@10	P@20
	Macro	AST	IR AST	IR AST	IR
	Eclipse I	1.00 1.00 1.00 1.00 1.00 1.00
	Eclipse II	1.00 0.20 0.80 0.10 0.85 0.05
	JHotDraw	1.00 1.00 1.00 1.00 1.00 1.00
	PetitDelphi	0.20 0.20 0.10 0.20 0.10 0.25
	PetitSQL I	1.00 0.00 0.60 0.40 0.30 0.40
	PetitSQL II	1.00 0.60 1.00 0.80 0.95 0.90
	PackageManager I	1.00 1.00 1.00 1.00 1.00 1.00
	PackageManager II	1.00 1.00 1.00 1.00 1.00 1.00
	PackageManager III 1.00 1.00 1.00 1.00 1.00 1.00
	PackageManager IV 0.60 0.40 0.40 0.20 0.30 0.33
	MooseQuery I	0.80 0.00 0.80 0.08 0.70 0.08
	MooseQuery II	0.20 0.00 0.10 0.00 0.15 0.10
	Pillar	1.00 1.00 1.00 0.90 0.85 0.90
	Average	0.83 0.56 0.75 0.59 0.70 0.61

Recording the macro supposes that the developer executes the transformations at least once on the source code.

This algorithm was inspired by a similar one in LASE.

http://www.pharo.org/

ACKNOWLEDGMENTS

We thank the anonymous reviewers for their insightful comments on early draft of the paper. This work was funded in part by the contract CPER Nord-Pas de Calais/FEDER DATA Advanced data science and technologies 2015-2020. We also acknowledge the support of the Brazilian research agencies CAPES, CNPQ, and FAPEMIG.