1. Design Metrics & Dolores Zage Wayne Zage & Sponsored by Status Report

3. Objectives of To determine how the before stress points (calculated from UML designs) correspond to the after stress points (calculated from Java) in larger industrial programs To what degree of confidence does this matching occur? What other insights can be obtained? &

4. Design Metrics Analyses of P3 There were three design metrics analyses –UML class diagrams –Java implementation –matched design measures to the Java implementation design.

6. One class or method is a clone of another if both possess exactly the same values for all of the metrics considered.

7. Software Clones Not all cloning is bad, if done purposefully –Example: at the architectural level, n-version programming, strategy in which redundancy is purposefully and consciously used to implement reliable systems –Used to disentangle development units On studies reporting code duplication, percentages of duplicated code range from 7-23%, with an extreme of 53%

8. UML Class Clones 381 classes Collected 48 metrics 237 clones grouped into 29 clusters A unique number was assigned to each (2000-2028) 15 of the 29 clone groups possessed classes with different change order values

9. Java Clones 1244 modules 12 metrics 954 clones grouped into 89 clusters A unique number was assigned to each (1000-1088) 63 of the 89 clone groups possessed modules with different change order values

10. Clones, Non-clones and average changes clone non- clone UML4.213.3 Java17.038.9

11. UML Classes matched with Java Modules Uncovered entire class patterns 86 class patterns were grouped into 9 larger clusters To distinguish individual class clones and Java module clones, a label of class implementation clone was given to a set of modules

12. The six variants of class implementation Clone 2019 (1-3) 1 2 3 class implementation clone

13. 4 5 6 The six variants of class implementation Clone 2019 (4-6)

14. UML Design Metrics Highlighting D e correctly classified 89% of the non-clone UML classes D e correctly classified 93% of the clone UML classes D i correctly classified 89% of the UML classes Classes highlighted by both D e and D i correctly classified 93% Classes highlighted by both D e or D i correctly classified 91%

15. Java COs The granular level of change is documented at the class level. –For example, if a class had a CO value of 10 and this class consisted of 4 internal methods, the four method records for that class would each have a CO value of 10 recorded. Because the individual count of COs for the methods is not available, the class highlighting will be used as a marker for highlighting modules within classes. –We would expect that classes with higher CO counts (COs>= 20) would contain a higher concentration of highlighted modules and that modules with less CO counts (COs<20) would contain fewer.

16. Java Design Metrics Highlighting Of the 44 classes with COs >=20, 89% (39) of classes with COs >= 20 had at least one highlighted Java module.

17. Matching UML and Java 381 UML classes 1244 Java modules mapped to 167 UML classes 214 “empty” classes None of the empty classes were highlighted in the UML analysis.

18. Using the UML class highlighting as a classifier, the resulting highlighted and not highlighted methods were correctly classified 87% of the time for the classes that do not exhibit class implementation clone patterns.

19. Highlighting Revelations For classes with COs >= 20, the average number of highlighted methods per class was 3.5. For classes with COs < 20 this average is.6. A relationship exists between the number of COs per class and either the number of highlighted methods per class or the highest Java method D e values. Eighteen of the twenty-two non-clone classes with COs >= 20 highlighted by both the UML class and method(s) contained multiple highlighted methods. The non-clone classes with COs >= 20 highlighted by methods alone (7 of them), possessed multiple highlighted methods within the class.

20. Summary In this study, we have not only reaffirmed the design metrics ability to identify change-prone modules, but also presented their effectiveness for the evaluation of design to implementation, allowing for continuous assessment. These results also imply that early class categorization can correctly identify problem methods later in development. Our direction is to use metrics analyses in a predictive, proactive process. This study emphasizes that much can be learned from metrics and also much can be expected from their use.

21. &