Academia.eduAcademia.edu

Figure 6 – uploaded by Tim Menzies

See full PDFdownloadDownload figure
Fig. 7: A count of number of test instances where the developer changes overlaps a planner recommendation. The overlaps (in the x-axis) are categorized into four ranges for every dataset (these are 0 < Overlap < 25, 26 < Overlap < 50,51 < Overlap < 75, and 76 < Overlap < 100). For each of the overlap ranges, we count the the number of instances in the validation set where overlap between the planner’s recommendation and the developers changes fell in that range. Note: Higher counts for larger overlap is better, e.g., Count([75, 100]) > Count(([0, 25)) is considered better. RQ1: How well do planners recommendations match developer actions?

Figure 7 A count of number of test instances where the developer changes overlaps a planner recommendation. The overlaps (in the x-axis) are categorized into four ranges for every dataset (these are 0 < Overlap < 25, 26 < Overlap < 50,51 < Overlap < 75, and 76 < Overlap < 100). For each of the overlap ranges, we count the the number of instances in the validation set where overlap between the planner’s recommendation and the developers changes fell in that range. Note: Higher counts for larger overlap is better, e.g., Count([75, 100]) > Count(([0, 25)) is considered better. RQ1: How well do planners recommendations match developer actions?

Related Figures (14)

The work in this paper is gudeied by the following research questions. Fig. 1: Relationship of this paper to our prior research.
The work in this paper is gudeied by the following research questions. Fig. 1: Relationship of this paper to our prior research.
Table 1: Sample static code attributes.
Table 1: Sample static code attributes.
Learning Actionable Analytics from Multiple Software Projects Fig. 2: The figure lists defect datasets used in this paper.
Learning Actionable Analytics from Multiple Software Projects Fig. 2: The figure lists defect datasets used in this paper.
Fig. 3: An example of how developers might use XTREE to reduce software defects.
Fig. 3: An example of how developers might use XTREE to reduce software defects.
(b) A sample of possible actions developers can take. Here a ‘+’ represents an increase, a ‘— represents a decrease, and an empty cell represents no-change. Taken from Stroggylos and Spinellis (2007); Du Bois (2006); Kataoka et al. (2002); Bryton and e Abreu (2009); Elish and Alshayeb (2011, 2012). The action highlighted in gray shows an action matching XTREE’s recommendation from Figure 3.A.
(b) A sample of possible actions developers can take. Here a ‘+’ represents an increase, a ‘— represents a decrease, and an empty cell represents no-change. Taken from Stroggylos and Spinellis (2007); Du Bois (2006); Kataoka et al. (2002); Bryton and e Abreu (2009); Elish and Alshayeb (2011, 2012). The action highlighted in gray shows an action matching XTREE’s recommendation from Figure 3.A.
Fig. 4.4: To determine which of metrics are usually changed together, we use frequent itemset mining. Our dataset is continuous in nature (see (a)) so we first discretize using Fayyad- Irani (Fayyad and Irani, 1993); this gives us a representation shown in (b). Next, we convert these into “transactions” where each file contains a list of discretized OO-metrics (see (c)). Then we use the F'P-growth algorithm to mine frequent itemsets. We return the maximal frequent itemset (as in (d)). Note: in (d) the row in |§fé@i) is the maximal frequent itemset. Fig. 4.B: To build the decision tree, we find the most informative feature,i.e., the feature which has the lowest mean entropy of splits and construct a decision tree recursively in a top-down fashion as show below.
Fig. 4.4: To determine which of metrics are usually changed together, we use frequent itemset mining. Our dataset is continuous in nature (see (a)) so we first discretize using Fayyad- Irani (Fayyad and Irani, 1993); this gives us a representation shown in (b). Next, we convert these into “transactions” where each file contains a list of discretized OO-metrics (see (c)). Then we use the F'P-growth algorithm to mine frequent itemsets. We return the maximal frequent itemset (as in (d)). Note: in (d) the row in |§fé@i) is the maximal frequent itemset. Fig. 4.B: To build the decision tree, we find the most informative feature,i.e., the feature which has the lowest mean entropy of splits and construct a decision tree recursively in a top-down fashion as show below.
Fig. 4.C: For ever test instance, we pass it down the decision tree constructed in Fig. 4.B. The node it lands is called the “start”. Next we find all the “end” nodes in the tree, i.e., those which have the lowest likelihood of defects (labeled in below). Finally, perform a random-walk to get from “start” to “end”. We use the mined itemsets from Fig. 4.A to guide the walk. When presented with multiple paths, we pick the one which has the largest overlap with the frequent items. e.g., in the below example, we would pick path (b) over path (a).
Fig. 4.C: For ever test instance, we pass it down the decision tree constructed in Fig. 4.B. The node it lands is called the “start”. Next we find all the “end” nodes in the tree, i.e., those which have the lowest likelihood of defects (labeled in below). Finally, perform a random-walk to get from “start” to “end”. We use the mined itemsets from Fig. 4.A to guide the walk. When presented with multiple paths, we pick the one which has the largest overlap with the frequent items. e.g., in the below example, we would pick path (b) over path (a).
Fig. 4: XTREE Framework
Fig. 4: XTREE Framework
Fig. 5: A simple example of computing overlap. Here a ‘-’ represents no-change. Columns shaded in gray indicate a match between developer’s changes and planner’s recommendations. Learning Actionable Analytics from Multiple Software Projects
Fig. 5: A simple example of computing overlap. Here a ‘-’ represents no-change. Columns shaded in gray indicate a match between developer’s changes and planner’s recommendations. Learning Actionable Analytics from Multiple Software Projects
Fig. 6: Sample charts to illustrate the format used to present the results.
Fig. 6: Sample charts to illustrate the format used to present the results.
Fig. 8: A count of total number defects reduced and defects increased as a result each planners recommendations. The overlaps are again categorized into four ranges for every dataset (denoted by min < Overlap < maz). For each of the overlap ranges, we count the total number of defects reduced and defects increased in the validation set for the classes that were defective in the test set as a result of overlap between the planner’s recommendation and the developers changes that fell in the given range
Fig. 8: A count of total number defects reduced and defects increased as a result each planners recommendations. The overlaps are again categorized into four ranges for every dataset (denoted by min < Overlap < maz). For each of the overlap ranges, we count the total number of defects reduced and defects increased in the validation set for the classes that were defective in the test set as a result of overlap between the planner’s recommendation and the developers changes that fell in the given range
Fig. 9: A count of total number defects reduced and defects increased as a result each planners recommendations. The overlaps are again categorized into four ranges for every dataset (denoted by min < Overlap < maz). For each of the overlap ranges, we count the total number of defects reduced and defects increased in the validation set for the classes that were defective in the test set as a result of overlap between the planner’s recommendation and the developers changes that fell in the given range Learning Actionable Analytics from Multiple Software Projects
Fig. 9: A count of total number defects reduced and defects increased as a result each planners recommendations. The overlaps are again categorized into four ranges for every dataset (denoted by min < Overlap < maz). For each of the overlap ranges, we count the total number of defects reduced and defects increased in the validation set for the classes that were defective in the test set as a result of overlap between the planner’s recommendation and the developers changes that fell in the given range Learning Actionable Analytics from Multiple Software Projects
Rahul Krishna, Tim Menzies
Rahul Krishna, Tim Menzies
(a) Defects Reduced. Higher defect reduction for larger Overlap is considered better. Fig. 10: A count of total number defects reduced and defects increased as a result each planners recommendations. The overlaps are again categorized into four ranges for every dataset (denotec by min < Overlap < maz). For each of the Overlap ranges, we count the total number o: defects reduced and defects increased in the validation set for the classes that were defective ir the test set as a result of Overlap between the planner’s recommendation and the developers changes that fell in the given range
(a) Defects Reduced. Higher defect reduction for larger Overlap is considered better. Fig. 10: A count of total number defects reduced and defects increased as a result each planners recommendations. The overlaps are again categorized into four ranges for every dataset (denotec by min < Overlap < maz). For each of the Overlap ranges, we count the total number o: defects reduced and defects increased in the validation set for the classes that were defective ir the test set as a result of Overlap between the planner’s recommendation and the developers changes that fell in the given range
Related topics:
Empirical Software Engineering
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved