Weighted Multi-Factor Multi-Layer Identification of Potential Causes for Events of Interest in Software Repositories Philip Makedonski, Jens Grabowski Institute of Computer Science, University of Göttingen Goldschmidtstr. 7, 37077 Göttingen, Germany {makedonski,grabowski}@cs.uni-goettingen.de rather than causes. For example, developers typically describe their development and maintenance activities Abstract as fixing issues and problems, improving certain prop- erties, adding features and functionality, and refactor- Change labelling is a fundamental challenge in ing code. In contrast, during software assessment, we software evolution. Certain kinds of changes are often more interested in the potential causes for can be labeled based on directly measurable such activities which are typically not explicitly la- characteristics. Labels for other kinds of belled as such due to the fact that such knowledge is changes, such as changes causing subsequent usually not available at the time when the correspond- fixes, need to be estimated retrospectively. ing activity was performed. In this article we present a weight-based ap- In this article, we are concerned with activities proach for identifying potential causes for which are associated with contributing to various tech- events of interest based on a cause-fix graph nical risks for undesirable phenomena, such as failures, supporting multiple factors, such as causing or difficult to maintain code that needs refactoring. a fix or a refactoring, and multiple layers re- We explore means for the retrospective identification flecting di↵erent levels of granularity, such as and quantification of such activities based on empiri- project, file, class, method. We outline di↵er- cal data and di↵erent factors contributing to labelling ent strategies that can be employed to refine activities as risky. The quantitative information in the the weights distribution across the di↵erent form of weights provides a more refined view on the ex- layers in order to obtain more specific labelling tent to which an activity can be considered a technical at finer levels of granularity. risk. The presented approach can be generalised to labelling activities as potential causes for events of in- 1 Introduction terest with respect to any particular assessment task, The field of software mining explores di↵erent ap- regardless of whether it is concerned with a technical proaches for extracting information from software risk or not. repositories both in the form of basic facts and in the Existing approaches are typically based on some form of derived knowledge. While software repositories form of origin analysis [GT02], involving line- provide a wealth of information related to the devel- tracking and annotation graphs [KZPW06], line his- opment and evolution of software projects, most of it tories [CC06], line mapping [MHC14], as well as sev- is of empirical nature, that is, describing consequences eral refinements to these [WS08, CCDP09] in order to map and track entities across revisions. Di↵erent Copyright c 2015 by the paper’s authors. Copying permitted applications for such approaches have been discussed for private and academic purposes. This volume is published in the literature, ranging from finding fix-inducing and copyrighted by its editors. changes [SZZ05] and the role of authorship on im- In: A.H. Bagge, T. Mens (eds.): Postproceedings of SATToSE 2015 Seminar on Advanced Techniques and Tools for Software plicated code [RD11] to defect-insertion circumstance Evolution, University of Mons, Belgium, 6-8 July 2015, analysis [PP14]. While these are closely related to the published at http://ceur-ws.org topic of this article, to our knowledge none of the exist- ing approaches has incorporated weighting of the ex- Cause-Fix Graph: A hierarchical directed graph tent to which a change contributes to a subsequent fix. G = (N, E), where the set of nodes N includes The weighting information can be used to refine and representations for each state of each artifact. A improve existing applications, such as better targeted state may contain other states at finer levels of recommendations for artifacts that need additional re- contains granularity, i.e. ct ! at , based on the con- view or testing. tainment relationships between the corresponding This article is structured as follows: In Section 2 artifacts for the states (assuming that artifact c we outline the basic notions related to our approach. contains artifact a, i.e. c contains ! a). For exam- In Section 3 we discuss the weighting approach and ple, the state for a class may contain also states for its generalisation for arbitrary factors. In Section 4 methods modified at the same time as the class. we refine the approach to cover multiple levels of ab- The set of directed edges E includes representa- straction across distinct layers. Then, in Section 5, we tions for each cause-fix relationship between two discuss di↵erent strategies for distributing the weights states of an artifact. across the layers. Section 6 summarises related work. Finally, we conclude with a short summary and out- Based on the cause-fix relationships, for a given look in Section 7. state at identified as a fix, we define the set of states fixed by at (i.e. the set of causes for at ) as: 2 Causes and Fixes In this article we are concerned with determining the causes likely causes for events of interest. Before we proceed, aFIXES t = {at n 2 A : at n ! at } (1) we need to establish what we consider under “events of interest” and other related notions: Conversely, for a given state at n identified as a cause, the set of known caused fixes for at n is defined Artifact: A generalised notion of a software-related as: entity a at any level of granularity, such as project, file, class, method, on which developers perform causes development and maintenance activities. An ar- aCAUSES t n = {at 2 A : at n ! at } (2) tifact may contain other artifacts at finer levels of granularity. A cause-fix graph can be constructed by utilising information extracted from version control systems. State: A generalised notion of a revision at of artifact This can be accomplished automatically by applying a at a point in time t. The set of all states of an any of the approaches for tracking the location of artifact a is denoted as A. modified fragments across revisions already described in the literature [WS08, CCDP09] and transforming Event of interest: A state at of an artifact a at a their output. The resulting graph at the project (or point in time t which can be described by some global) level of abstraction represents the cause-fix re- quantitative or qualitative characteristic factor, lationships between states of the whole project. An such as the content of a descriptive message as- example for such a graph for five states of a project p sociated with the state. (p1 to p5 ) is shown on Figure 1. Fix: A modification to an existing part of an artifact a in a given state at , that was last modified or 3 Weights and Factors created at an earlier point in time t n resulting A simplified binary classification of nodes in the graph in a state at n . The modification may, but does as causes for events of interest presents some limita- not strictly need to, relate to fixing a problem. tions. The basic example from Figure 1 already raises Cause: A modification of a part of an artifact a at a two questions related to the significance of the classi- given state at that was modified at a later point fications: in time t + n resulting in a state at+n . • Given that both p3 and p4 are identified as causes Cause-Fix Relationship: A relationship between for the fix in p5 , are they both equally likely causes two states (at n , at ) of an artifact a, where a and thus to be considered of equal importance? part of a that was modified in at n was subse- quently modified in a later state at , hence at n • Given that p3 is identified as causing both p4 and is considered a cause for at . It is denoted as p5 , is it then considered a less likely cause for p5 , causes at n ! at . and thus to be considered of less importance? cw(p1, p3, refactors) = 0 cw(p3, p5, refactors) = 0 cw(p1, p3, fixes) = 0 cw(p3, p5, fixes) = 0.5 causes causes cw(p3, p4, refactors) = 1 cw(p4, p5, refactors) = 0 cw(p3, p4, fixes) = 0 cw(p4, p5, fixes) = 0.5 causes causes refactors fixes p1 p2 p3 p4 p5 time fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.tw = 0.0 fixes.tw = 0.0 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.0 fixes.aw = 0.0 fixes.aw = 0.0 fixes.aw = 0.25 fixes.aw = 0.5 fixes.aw = 0.0 refactors.rw = 0.0 refactors.rw = 0.0 refactors.rw = 0.0 refactors.rw = 1.0 refactors.rw = 0.0 refactors.tw = 0.0 refactors.tw = 0.0 refactors.tw = 1.0 refactors.tw = 0.0 refactors.tw = 0.0 refactors.aw = 0.0 refactors.aw = 0.0 refactors.aw = 0.5 refactors.aw = 0.0 refactors.aw = 0.0 Figure 1: Multi-factor cause-fix graph example In order to be able to reason about these questions, we need means to quantify the relationships between 1 fixes and causes. We can establish that cause-fix re- cw(at n , at , wf ) = rw(at , wf ) (4) lationships are many-to-many, that is a revision may |aFIXES t | be the cause for many subsequent revisions, and a re- For each fix at caused by a causing state at n , the vision may fix multiple previous revisions. Conceptu- causing state at n is then said to accumulate a total ally, we consider a fix as an activity that is “removing weight (tw ) with regard to weight factor wf , defined a weight” from a state of an artifact. Consequently as: the activities that contributed to the causes for the fix “added weight” to the corresponding states of the X artifact. Our approach to quantifying the degree to tw(at n , wf ) = cw(at n , at , wf ) (5) which a revision can be considered as the cause for at 2aCAUSES t n another revision is based on this conceptual premise. In addition, there may be di↵erent types of “weights” For example, the fix in p5 is removing a weight based on di↵erent characteristics of the fixing revision, rw(p5 , fixes) = 1 with respect to the weight factor e.g. “fixing an issue”, “refactoring code”, etc., reflect- “fixes”. In the set P denoting all states of p, there are ing the di↵erent kinds of events of interest. In order causes two states pFIXES 5 = {p5 n 2 P : p5 n ! p5 } = to accommodate this, we extend the notion to “re- {p3 , p4 } identified as causes for this fix. They are con- moving a weight related to a weight factor wf ” where sidered to be contributing equally to that weight. In wf 2 {fixes, refactors, . . .}. Thus, we speak of a fixing this case, each cause-fix relationship is contributing a revision at as having removed weight (rw) with respect weight cw(p5 n , p5 , fixes) = 0.5. On the other hand, to weight factor wf where: p4 can be considered “neutral” with respect to the “fixes” weight factor (i.e. rw(p4 , fixes) = 0), as it is not ( identified as an event of interest. Hence, p3 does not 1 if wf property holds for at contribute any weight to p4 (i.e. cw(p3 , p4 , fixes) = 0). rw(at , wf ) = (3) In this case, we speak of p3 and p4 as having a 0 otherwise tw(p3 , fixes) = tw(p4 , fixes) = 0.5. Thus, at first glance it may seem that p3 and p4 can be considered Each of the causes at n can be regarded as con- equally important. tributing to that weight, thus for each cause-fix re- In order to reason about the second question, we causes lationship at n ! at and for each weight factor need to contemplate the inverse relationship. Consid- wf , we define the notion of contributed weight (cw) ering p3 in the example, it causes both p4 and p5 , i.e. causes of a causing revision at n to a fixing revision at with pCAUSES 3 = {p3+n 2 P : p3 ! p3+n } = {p4 , p5 }, regard to a weight factor wf as: whereas p4 only causes p5 , i.e. pCAUSES 4 = {p5 }. To take this into account, we define the notion of average To illustrate the first challenge, consider a di↵erent weight (aw) with regard to weight factor wf as: scenario, sketched in Figure 2. In this scenario, there are three files, x, y, and z, two of which are modified tw(at n , wf ) as part of p3 , p4 , p5 on the project level of granularity. aw(at n , wf ) = (6) There are two states at the file level for each state at |aCAUSES t n | the project level of granularity. The naive approach In the example above, this yields aw(p3 , fixes) = would be to simply copy the weights from the project 0.25 and aw(p4 , fixes) = 0.5, respectively. Thus, we level to the file level. With regard to the first challenge, can state that while both p3 and p4 can be considered the question arises whether the states y3 and y4 at the important as causes for the fix in p5 with respect to the file level are contributing at all to the cause for the fix weight factor “fixes”, since p3 is also a cause for p4 , it in p5 , given that in p5 only x and z have been modified. is less important than p4 as it also caused a “neutral” In other words, shall y3 and y4 be assigned any weights change with respect to the weight factor “fixes” in ad- at all? The same is also applicable at the logical level. dition to the fixing change. If we consider the “refac- Even from this simplified example, we can observe tors” weight factor, we observe that the weights are that the naive copy approach can potentially result in distributed di↵erently since it is p4 where the weight a lot of noise since the sets of states of artifacts at a related to that factor is removed (rw(p4 , refactors) = finer level of granularity may vary between the causing 1) and hence p3 is the only identified cause contribut- and the fixing states at the coarser level of granularity. ing all the removed weight (cw(p3 , p4 , refactors) = A more adequate approach is to construct a distinct tw(p3 , refactors) = aw(p3 , refactors) = 1). The cor- cause-fix graph at each layer corresponding to a given responding weighting is also shown in Figure 1. The level of granularity based on the cause-fix relationships weight-related values are calculated for each weight among the states at that level. This enables weight re- factor for each node. Note, that while information distribution within the corresponding layers, yielding about the causing revisions can be considered defini- more accurate weighting for each layer. Consider the tive, information about the fixing revisions is only par- same scenario from Figure 2, where instead of copying tially known. Future revisions may still include fixes the weights from the project layer, we calculate the for existing revisions, thus altering their weights. weights at the file layer based only on the cause-fix relationships at that layer, as illustrated in Figure 3. 4 Layers and Granularities This approach yields more accurate weight distribu- In the examples discussed so far, only the project level tion, taking into account that only x and z were mod- of granularity was considered. In practice, a revision ified as part of the fix in p5 . Hence, the corresponding at the project level of granularity can be decomposed states x3 and z4 carry the full responsibility for caus- to revisions at the file and logical levels of granular- ing the fix in p5 and thus shall be assigned the corre- ity, where multiple related artifacts at these levels are sponding weights, whereas the states y3 and y4 can be changed together as part of a development activity. In considered neutral in this case and shall be assigned this case, the challenge of transferring weights between no weights at all. the di↵erent levels arises. Furthermore, while a set of This brings us to the second challenge, which can related artifacts may be changed within a causing revi- be exemplified in the given scenario as follows: given sion, only a subset of these artifacts and possibly a set that both states x5 and z5 at the file level are con- of additional artifacts may be changed within a cor- sidered as part of the fix in p5 at the project level, responding fixing revision. Thus, the causes and fixes are both x5 and z5 contributing equally to the fix for a revision of an artifact at a finer level of granu- in p5 ? So far, states at finer levels of granularity larity may be a subset of the causes and fixes for the simply inherited the removed weights from the con- containing artifact. Consequently, the weight distribu- taining state at a coarser level of granularity, that is tion may vary across the di↵erent levels of granularity. rw(x5 , fixes) = rw(z5 , fixes) = rw(p5 , fixes). Inher- This raises two fundamental challenges: iting the removed weights from the containing state does not take into account potential dilution of the • Given a revision that is the cause for a fix, where contribution of each individual state at the finer level the cause a↵ects multiple artifacts at a finer level of granularity. If there is a single state at the finer level of granularity, are all of these artifacts contribut- of granularity, it can be considered solely responsible ing equally to the cause for the fix? for the fix, but if there are a large number of states at • Given a revision that is considered a fix, which the finer level of granularity, each one of them may be a↵ects multiple artifacts at a finer level of granu- contributing only a small part to the fix. larity, are all these artifacts equally important for Even in this simple artificial scenario, we need to the fix? account for both the number of states at a finer level causes causes causes Project Layer fixes p3 p4 p5 time fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.0 Copy Approach fixes.aw = 0.25 fixes.aw = 0.5 fixes.aw = 0.0 File Layer x3 y3 y4 z4 x5 z5 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.rw = 1.0 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.0 fixes.tw = 0.0 fixes.aw = 0.25 fixes.aw = 0.25 fixes.aw = 0.5 fixes.aw = 0.5 fixes.aw = 0.0 fixes.aw = 0.0 Logical Layer Figure 2: Copy approach for distributing weights across di↵erent levels of granularity of granularity involved in a fix and potentially also at a coarser level of granularity, we need to take di↵er- other characteristics of each state in order to obtain a ent aspects into account, such as the number of states more accurate picture. This raises some concerns that at the finer level of granularity involved in the fix, the need to be taken into account, such as the following: type and size of the corresponding artifacts, as well as the amount of change to each corresponding artifact. • Does the number of states of artifacts at a finer To address these concerns, we exemplify four weight level of granularity involved in a fix dilute the con- distribution strategies. Additional strategies may be tribution of each individual state to the fix? added to emphasise the importance of other character- istics of corresponding artifacts, such as their complex- • Do states of certain types of artifacts contribute ity, documentation availability, etc. The weight distri- more to a fix than others (e.g. states of code vs. bution strategies refine the notion of removed weight image artifacts)? (rw) to distributed removed weight (drw). The dis- • Do states of larger artifacts contribute more to a tributed removed weight according to a distribution fix than states of smaller artifacts? strategy ds for a state at of artifact a contained in a state ct of containing artifact c is defined based on the • Do states of artifacts containing larger changes following expression: contribute more to a fix than states of artifacts containing smaller changes? drw(at , wf, ds) = rw(ct , wf ) · df (at , ds) (7) In order to take these concerns into account in the weighting approach, we define di↵erent weight distri- where the distribution factor for a distribution strat- bution strategies, which distribute removed weights egy ds (df (ds)) determines the proportion of the re- in fixing states across artifact states at finer levels of moved weight from the containing state ct allocated granularity depending on their contribution to a fix. to the contained state at according to the distribution Consequently, the weights calculated for the causing strategy of choice. As a baseline, the distribution fac- states are also updated according to the strategy be- tor for the inherit strategy discussed in Section 4 and ing used. shown in Figure 3 can be defined as: 5 Weight Distribution Strategies df (at , inherit) = 1 (8) As noted in Section 4, when we consider the contri- bution of each state of an artifact at a finer level of Substituting the removed weight with the dis- granularity to a fix in a state of a containing artifact tributed removed weight in the calculation of the con- causes causes causes Project Layer fixes p3 p4 p5 time fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.0 Layer Approach fixes.aw = 0.25 fixes.aw = 0.5 fixes.aw = 0.0 File Layer x3 y3 y4 z4 x5 z5 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.rw = 1.0 fixes.tw = 1.0 fixes.tw = 0.0 fixes.tw = 0.0 fixes.tw = 1.0 fixes.tw = 0.0 fixes.tw = 0.0 fixes.aw = 1.0 fixes.aw = 0.0 fixes.aw = 0.0 fixes.aw = 1.0 fixes.aw = 0.0 fixes.aw = 0.0 Logical Layer Figure 3: Layer approach for distributing weights across di↵erent levels of granularity tributed weights enables the support for distributed re- drw(x5 , fixes, shared) = drw(z5 , fixes, shared) = 0.5. moved weights according to a given strategy through- Consequently, the total and average weights of the cor- out the approach. responding causing states at the file level of granularity are also adjusted. Thus, the dilution of the contribu- 5.1 Shared Strategy tion of each state at the finer level of granularity to the The shared strategy takes into account number of fix is also extended to the total and average weights of states of artifacts at a finer level of granularity in- the corresponding causing states. volved in a fix based on the assumption that a large While we exemplify only the application of the number of states dilutes the contribution of each indi- strategy to the project and file levels of granularity, vidual state to the fix. This strategy distributes the this strategy is also applicable at di↵erent logical levels removed weight equally, assuming that each state at a of granularity. Note, however, that it shall be applied finer granularity contributes equally to the fix. As a at each logical level of granularity (e.g. Class, Method, consequence, the more states contributing to a fix the Function, etc.) separately, which makes its application less impact each individual state has. Given the set at that level more similar to the type strategy. of states at a finer level of granularity contained in a state ct , defined as: contains cCONTENTS t = {at : ct ! at } (9) 5.2 Type Strategy the distribution factor for the shared strategy is de- fined as: The type strategy takes into account how much states of artifacts at a finer level of granularity contribute to a 1 fix based on the artifact type (at) of the corresponding df (at , shared) = (10) artifact. This strategy distributes the removed weight |cCONTENTS t | equally among states of artifacts of a selected type The application of the shared strategy to the run- (indicated as a parameter), while states of artifacts of ning example from Figures 2–3 and the resulting other types do not get any removed weight assigned. weight redistribution is shown in Figure 4. Since It can be used to emphasise the importance of states two states at the file level of granularity are in- of code artifacts and de-emphasise the importance of volved in the fix at the project level of granularity, image artifacts, for example. The distribution factor the df (x5 , shared) = df (z5 , shared) = 0.5 and hence for the type strategy for a given type T is defined as: causes causes causes Project Layer fixes p3 p4 p5 time fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.0 Shared Strategy fixes.aw = 0.25 fixes.aw = 0.5 fixes.aw = 0.0 File Layer x3 y3 y4 z4 x5 z5 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.5 fixes.rw = 0.5 fixes.tw = 0.5 fixes.tw = 0.0 fixes.tw = 0.0 fixes.tw = 0.5 fixes.tw = 0.0 fixes.tw = 0.0 fixes.aw = 0.5 fixes.aw = 0.0 fixes.aw = 0.0 fixes.aw = 0.5 fixes.aw = 0.0 fixes.aw = 0.0 Logical Layer Figure 4: Shared strategy for distributing removed weights across layers egy at the file level of granularity applied at the logical levels of granularity. df (at , type:T ) ( 1 |{st 2cCONTENTS :at(st )=T }| if at(at ) = T (11) 5.3 Size Strategy = t 0 otherwise The size strategy emphasises the impact of the size of an artifact (as) in a given state that is considered as where {st 2 cCONTENTS t : at(st ) = T } denotes the set a part of a fixing state at a coarser level of granular- of states of artifacts of type T contained in ct . ity. The underlying assumption is that larger artifacts The application of the type strategy for the type require more time and e↵ort to maintain [ABJ10] and code to the running example from Figures 2–4 and the thus more emphasis shall be placed on such artifacts resulting weight redistribution is shown in Figure 5. and their contribution to the occurrence of an event Of the two states at the file level of granularity in- of interest, such as a fix. Hence, if there is weight volved in the fix at the project level of granularity, to be removed in a fix, the chunk of that weight to be only x5 is of type code, hence df (x5 , type:code) = 1, removed from a given artifact is assumed to be propor- whereas df (z5 , type:code) = 0 since at(z5 ) = image. tional to the size of the artifact. The size of an artifact Consequently, drw(x5 , fixes, type:code) = 1, whereas is generally measured in terms of lines of code, however drw(z5 , fixes, type:code) = 0. The total and average other measures may be used as well. The distribution weights of the corresponding causing states at the file factor for the size strategy is defined as: level of granularity are adjusted respectively. Thus, the emphasis on the contribution of states of code arti- facts to the fix is also extended to the total and average as(at ) weights of the corresponding causing states. df (at , size) = (12) as(ct ) This strategy can be applied multiple times for dif- ferent types of artifacts, essentially resulting in a dis- The application of the size strategy to the running tribution of removed weights “within type”, i.e. the example from Figures 2–5 and the resulting weight removed weight of a fixing state at the project level of redistribution is shown in Figure 6. Given the ar- granularity is distributed once among all states of code tifact sizes as(x5 ) = 40 and as(z5 ) = 60, the cor- artifacts, then again independently among all states of responding distribution factors are df (x5 , size) = 0.4 test artifacts, and so on. In a similar manner, it can and df (z5 , size) = 0.6, which are also identical to the also be applied at the di↵erent logical levels of granu- respective distributed removed weights for x5 and z5 . larity (e.g. Class, Method, Function, etc.) individually The total and average weights of the corresponding in order to obtain the equivalent of the shared strat- causing states at the file level of granularity are also causes causes causes Project Layer fixes p3 p4 p5 time fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.0 Type Strategy fixes.aw = 0.25 fixes.aw = 0.5 fixes.aw = 0.0 File Layer at(x5) = code x3 y3 y4 z4 x5 z5 at(z5) = image fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.rw = 0.0 fixes.tw = 1.0 fixes.tw = 0.0 fixes.tw = 0.0 fixes.tw = 0.0 fixes.tw = 0.0 fixes.tw = 0.0 fixes.aw = 1.0 fixes.aw = 0.0 fixes.aw = 0.0 fixes.aw = 0.0 fixes.aw = 0.0 fixes.aw = 0.0 Logical Layer Figure 5: Type strategy for distributing removed weights across layers adjusted respectively, emphasising the impact of the If a fixing state at the project level includes states of size of the corresponding artifacts in the fixing state artifacts of di↵erent types, e.g. code and test, and we on their contribution to the fix as indicated by the are interested primarily in artifacts of type code, the removed weight assigned to them, and also on the to- typed size strategy distributes the removed weight ac- tal and average weights of the corresponding causing cording to the size of code artifacts only. Thus, even states. if the fixing state contains large test artifacts, they Similar to the shared strategy, the size strategy will have no impact on the weight distribution among shall be applied at each logical levels of granularity the code artifacts. Similar to the type strategy, the (e.g. Class, Method, Function, etc.) separately, which typed size strategy can be applied multiple times for e↵ectively results in a refinement of the size strategy di↵erent types of artifacts, essentially resulting in a that also integrates the type strategy. In that case, the distribution of removed weights “within type”. size strategy takes a parameter T denoting the type of artifacts it shall be applied to. Given the typed artifact 5.4 Churn Strategy size (tas) for a state of an artifact ct and an artifact The churn strategy emphasises the impact of the type T defined as the sum of the sizes of all artifacts amount of change (churn) of an artifact (ac) in a given of type T in the states contained in ct : state that is considered as a part of a fixing state at a coarser level of granularity. The underlying assump- X tion is that larger changes in artifacts require more tas(ct , T ) = as(at ) (13) time and e↵ort to perform and potentially contribute at 2cCONTENTS t :at(at )=T more to the occurrence of an event of interest, such as the size strategy is refined by integrating the tas in a fix. Hence, if there is weight to be removed in a fix, the distribution factor resulting in: the chunk of that weight to be removed from a given artifact is assumed to be proportional to the amount ( of change that needed to be performed in the artifact. as(at ) tas(ct ,T ) if at(at ) = T The distribution factor for the churn strategy is de- df (at , size:T ) = (14) 0 otherwise fined as: Apart from the application at the logical levels of ac(at ) granularity, this refinement also combines the empha- df (at , churn) = (15) sis on the type and the size of the artifact. When ac(ct ) applied at the file level of granularity, only the size of The application of the churn strategy to the run- artifacts of the given type is taken into consideration. ning example from Figures 2–6 and the resulting causes causes causes Project Layer fixes R3 R4 R5 time fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.0 Size Strategy fixes.aw = 0.25 fixes.aw = 0.5 fixes.aw = 0.0 File Layer as(A5) = 40 A3 B3 B4 C4 A5 C5 as(C5) = 60 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.4 fixes.rw = 0.6 fixes.tw = 0.4 fixes.tw = 0.0 fixes.tw = 0.0 fixes.tw = 0.6 fixes.tw = 0.0 fixes.tw = 0.0 fixes.aw = 0.4 fixes.aw = 0.0 fixes.aw = 0.0 fixes.aw = 0.6 fixes.aw = 0.0 fixes.aw = 0.0 Logical Layer Figure 6: Size strategy for distributing removed weights across layers weight redistribution is shown in Figure 7. Given and emphasising the states of artifacts that contribute that ac(x5 ) = 4 and ac(z5 ) = 1, the correspond- both to events of interest and to their likely causes ing distribution factors are df (x5 , churn) = 0.8 and based on the relative importance of these states with df (z5 , churn) = 0.2, which are also identical to the re- respect to the e↵ort involved in understanding them. spective distributed removed weights for x5 and z5 . On the other hand, if the amount of change in states The total and average weights of the corresponding of artifacts is considered more critical with respect to causing states at the file level of granularity are also the e↵ort involved in maintenance and development adjusted respectively. This emphasises the impact of tasks, then the churn strategy will be more adequate. the amount of change in the states of the correspond- The states of artifacts that contribute both to events of ing artifacts in the fixing state on their contribution interest and to their likely causes can be identified and to the fix. Their contribution is indicated by the re- emphasised based on their relative importance with moved weight assigned to them. By extension, this respect to the e↵ort involved in modifying them. also emphasises the impact of the amount of change There are di↵erent kinds of churn measures de- on the total and average weights of the corresponding scribed in the literature [KAG+ 96, KS94, MGP13, causing states. NB05]. We consider a rather simple absolute measure Contemplating the application of both the size and of churn defined as the sum of additions and removals the churn strategies, as illustrated in Figure 6 and in terms of lines (churned lines of code in [NB05]), Figure 7, respectively, we may observe a contradiction where a modification is considered both a removal and in the weight distributions. The size strategy indicates an addition of one or more lines that are part of the that z5 is contributing more to the fix in p5 due to its modification. Other notions of churn can also be used larger size and hence its causing state z4 is the more in the churn strategy, however if a relative churn mea- likely cause for the fix in p5 . On the other hand, the sure is used, such as the ones described in [NB05], the churn strategy indicates that x5 is contributing more distribution factor may need to be adjusted as well. to the fix in p5 due to the larger amount of change in x5 Similar to the shared and the size strategy, the and hence its causing state x3 is the more likely cause churn shall be applied at each logical levels of granu- for the fix in p5 . The di↵erent strategies ultimately larity (e.g. Class, Method, Function, etc.) separately, enable emphasising di↵erent characteristics of events which e↵ectively results in a refinement of the churn of interest. Which one is to be used depends on the strategy that also integrates the type strategy, anal- application context and the assessment task. If the ogous to the size strategy. In that case, the churn size of artifacts is perceived as resulting in more e↵ort strategy takes a parameter T denoting the type of ar- involved in maintenance and development tasks, then tifacts it shall be applied to. Given the typed artifact the size strategy will be more adequate for identifying churn (tac) for a state of an artifact ct and an artifact causes causes causes Project Layer fixes R3 R4 R5 time fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 1.0 fixes.tw = 0.5 fixes.tw = 0.5 fixes.tw = 0.0 Churn Strategy fixes.aw = 0.25 fixes.aw = 0.5 fixes.aw = 0.0 File Layer ac(A5) = 4 A3 B3 B4 C4 A5 C5 ac(C5) = 1 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.0 fixes.rw = 0.8 fixes.rw = 0.2 fixes.tw = 0.8 fixes.tw = 0.0 fixes.tw = 0.0 fixes.tw = 0.2 fixes.tw = 0.0 fixes.tw = 0.0 fixes.aw = 0.8 fixes.aw = 0.0 fixes.aw = 0.0 fixes.aw = 0.2 fixes.aw = 0.0 fixes.aw = 0.0 Logical Layer Figure 7: Churn strategy for distributing removed weights across layers type T defined as the sum of the churn of all artifacts 6 Related Work of type T in the states contained in ct : Existing approaches are typically based on some form of origin analysis [GT02], involving line tracking and X tac(ct , T ) = ac(at ) (16) annotation graphs [KZPW06], line histories [CC06], at 2cCONTENTS :at(at )=T line mapping [MHC14], as well as refinements to t these [WS08, CCDP09] in order to map and track en- tities across revisions. Historage [HMK11] is an ap- the churn strategy is refined by integrating the tac in proach for tracing fine-grained artifact histories in- the distribution factor resulting in: cluding renaming changes. The approach presented in this chapter builds on top of these approaches, ap- ( plying origin analysis to events of interest in order to as(at ) tac(ct ,T ) if ac(at ) = T determine their potential causes and then quantifying df (at , churn:T ) = (17) 0 otherwise the cause-fix relationships by means of weights. Our approach also considers di↵erent levels of granularity. Apart from the application at the logical levels of Any of the existing approaches can be used as a foun- granularity, this refinement also combines the empha- dation and generally the accuracy of the weighting de- sis on the type of the artifact and the amount of change pends in part on the quality of the results from the in the artifact. When applied at the file level of gran- underlying origin analysis approach. ularity, only the churn of artifacts of the given type is Di↵erent applications for the existing approaches taken into consideration. If a fixing state at the project have been discussed in the literature, ranging from level includes states of artifacts of di↵erent types, e.g. finding fix-inducing changes [SZZ05] and understand- code and test, and we are interested primarily in arti- ing the role of authorship on implicated code [RD11] to facts of type code, the typed churn strategy distributes defect-insertion circumstance analysis [PP14]. While the removed weight according to the churn of code ar- in a sense such applications do serve a similar purpose tifacts only. Thus, even if the fixing state contains — identifying potential causes for events of interest, large changes to test artifacts, they will have no im- they are more focused on identifying such causes before pact on the weight distribution among the code arti- the event of interest has occurred. Such applications facts. Similar to the type and the typed size strategy, generally require sufficient information about known the typed churn strategy can be applied multiple times causes for events of interest, which serves as training for di↵erent types of artifacts, essentially resulting in data in order to build pattern recognition models that a distribution of removed weights “within type”. are then used to identify potential causes for events of interest. Both, the training and the validation of emphasising di↵erent characteristics of the states of such pattern recognition models requires data anno- artifacts involved in an event of interest, such as their tated with known causes for events of interest. The type, size, or the amount of change they have under- approach discussed in this chapter can be applied to gone. The emphasis on di↵erent characteristics allows produce such data emphasising di↵erent characteris- us to account for the importance of these character- tics across multiple levels of granularity for di↵erent istics in the e↵ort involved in performing an activity kinds of events of interest. that leads to an event of interest or its causes. Further The challenge of “tangled changes” [HZ13] is some- weight distribution strategies may be defined in order what related to topic of this chapter, where the au- to emphasise other characteristics or combinations of thors study the prevalence of such changes that are characteristics of events of interest. unrelated or loosely related to events of interest and apply a multi-predictor approach to untangle them, There are di↵erent related approaches described in based on di↵erent confidence voters. The approach the literature, which seek to establish relationships be- discussed in this article relies on weighting and di↵er- tween fixes and their likely causes. However, none ent weight distribution strategies to emphasise certain of them have incorporated quantification of the ex- characteristics of changes related to events of inter- tent to which a likely cause contributes to a subse- est, that are considered to be of importance in a given quent fix, especially across multiple levels of granular- context. It can further benefit from a more sophisti- ity. The presented approach builds on top of these cated untangling approach, such as the one described approaches and generally any of them can serve as a in [HZ13], which can be incorporated as an additional foundation, providing the relationships between fixes weight distribution strategy to refine the distribution and their likely causes. Based on these relationships, of weights among fixing and causing states of artifacts the proposed approach can be used to calculate the across the di↵erent levels of granularity. corresponding weights and quantify the cause-fix rela- To the best of our knowledge none of the existing tionships. There are also di↵erent related applications approaches has incorporated quantification of the ex- discussed in the literature which can be used for simi- tent to which a change in one state contributes to a lar purposes. However, their scope and focus is mostly subsequent fix in a later state of an artifact. Also, none on identifying potential causes for events of interest, of the approaches has explored how to apply cause-fix where the event of interest has not yet occurred. The analysis across multiple levels of granularity. approach discussed in this article can be applied to provide necessary information for the configuration, validation, and refinement of such applications. 7 Conclusion In this article, we explored a weight-based approach While the set of revisions identified as causes for a for finding potential causes for events of interest in given revision is definitive, meaning that no additional software repositories. An event of interest can be any causes may be added for that revision, the set of revi- occurrence that may be of relevance for an assess- sions identified as fixes for a given revision reflects the ment task, such as fixing issues and problems, improv- state of knowledge at a given point in time, meaning ing properties, adding features and functionality, and that future revisions may also fix issues introduced in refactoring code. The approach adds quantitative in- that revision. This a↵ects the reliability of the calcu- formation on top of existing approaches for origin anal- lated weights. In future work, a suitable cut-o↵ point ysis, such as ones based on line tracking. The quan- in time needs to be defined, after which the calculated titative information is in the form of weights, where weights for causing states can be considered unreliable. an event of interest regarded as a fix is considered to Such a cut-o↵ point may be based on release tags, or be removing a weight, and the potential causes for the on the distance between causing and fixing states with event of interest are considered to be contributing to respect to a particular factor, or on the distance be- the presence of that weight. Distinct weights can be tween causing and fixing states in general. calculated across di↵erent dimensions, based on the kind of event of interest, such as a bug fix, refactoring, Establishing the real causes for events of interest etc., designated by a distinct factor for each kind of is a hard task. The presented approach provides a interest. The approach accommodates weight redistri- foundation for the quantification of potential causes. bution across multiple layers corresponding to di↵er- The next step is to investigate the extent to which the ent levels of granularity in order to provide more ac- presented approach can be used to determine the real curate information at these levels of granularity. We causes for events of interest, and in particular the role outlined di↵erent strategies for weight redistribution of di↵erent weight distribution strategies and combi- across the di↵erent levels of granularity, which enable nations of strategies towards that goal. References Software Engineering, 2006. ASE ’06. 21st IEEE/ACM International Conference on, [ABJ10] Erik Arisholm, Lionel C. Briand, and pages 81–90, 2006. Eivind B. Johannessen. A systematic and comprehensive investigation of methods to [MGP13] Philip Makedonski, Jens Grabowski, and build and evaluate fault prediction models. Florian Philipp. Quantifying the evolution J. Syst. Softw., 83(1):2–17, 2010. of TTCN-3 as a language. International Journal on Software Tools for Technology [CC06] G. Canfora and L. Cerulo. Fine grained Transfer, 16(3):227–246, July 2013. indexing of software repositories to sup- port impact analysis. In Proceedings of [MHC14] P. Marinescu, P. Hosek, and C. Cadar. the 2006 international workshop on Min- Covrig: A Framework for the Analysis ing software repositories, pages 105–111, of Code, Test, and Coverage Evolution Shanghai, China, 2006. ACM. in Real Software. In Proceedings of the 2014 International Symposium on Soft- [CCDP09] G. Canfora, L. Cerulo, and M. Di Penta. ware Testing and Analysis, ISSTA 2014, Tracking Your Changes: A Language- pages 93–104, New York, NY, USA, 2014. Independent Approach. Software, IEEE, ACM. 26(1):50 –57, February 2009. [NB05] N. Nagappan and T. Ball. Use of relative [GT02] M. Godfrey and Q. Tu. Tracking struc- code churn measures to predict system de- tural evolution using origin analysis. In fect density. In 27th International Confer- Proceedings of the international workshop ence on Software Engineering, 2005. ICSE on Principles of software evolution - IW- 2005, pages 284–292. IEEE, May 2005. PSE ’02, page 117, Orlando, Florida, 2002. [PP14] L. Prechelt and A. Pepper. Why Software [HMK11] Hideaki Hata, Osamu Mizuno, and Tohru Repositories Are Not Used for Defect- Kikuno. Historage: Fine-grained Version insertion Circumstance Analysis More Of- Control System for Java. In Proceed- ten: A Case Study. Inf. Softw. Technol., ings of the 12th International Workshop 56(10):1377–1389, October 2014. on Principles of Software Evolution and the 7th Annual ERCIM Workshop on Soft- [RD11] F. Rahman and P. Devanbu. Ownership, ware Evolution, IWPSE-EVOL ’11, pages experience and defects: a fine-grained 96–100, New York, NY, USA, 2011. ACM. study of authorship. In Proceedings of the 33rd International Conference on Soft- [HZ13] Kim Herzig and Andreas Zeller. The im- ware Engineering, ICSE ’11, pages 491– pact of tangled code changes. MSR ’13, 500, New York, NY, USA, 2011. ACM. page 121130, Piscataway, NJ, USA, 2013. IEEE Press. [SZZ05] J. Sliwerski, T. Zimmermann, and A. Zeller. When do changes induce fixes? [KAG+ 96] T.M. Khoshgoftaar, E.B. Allen, N. Goel, In Proceedings of the 2005 international A. Nandi, and J. McMullan. Detection workshop on Mining software repositories, of software modules with high debug code pages 1–5, St. Louis, Missouri, 2005. churn in a very large legacy system. In ACM. Seventh International Symposium on Soft- ware Reliability Engineering, 1996. ISSRE [WS08] C. Williams and J. Spacco. SZZ revisited: 1996, pages 364–371, October 1996. verifying when changes induce fixes. In Proceedings of the 2008 workshop on De- [KS94] T.M. Khoshgoftaar and R.M. Szabo. Im- fects in large software systems, DEFECTS proving code churn predictions during ’08, pages 32–36, New York, NY, USA, the system test and maintenance phases. 2008. ACM. ACM ID: 1390826. In International Conference on Software Maintenance, 1994. ICSM 1994, pages 58– 67, September 1994. [KZPW06] S. Kim, T. Zimmermann, K. Pan, and E.J. Whitehead. Automatic Identification of Bug-Introducing Changes. In Automated