Design Metrics

&

Dolores Zage Wayne Zage&

Sponsored by

Status Report

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?

&

Design Metrics Analyses of P3

• There were three design metrics analyses– UML class diagrams– Java implementation– matched design measures to the Java

implementation design.

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

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%

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

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

Clones, Non-clones and average changes

clonenon-clone

UML 4.2 13.3Java 17.0 38.9

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

The six variants of class implementation Clone 2019 (1-3)

1

2

3

class implementation clone

4

5

6

class implementation clone The six variants of class implementation Clone 2019 (4-6)

UML Design Metrics Highlighting

• De correctly classified 89% of the non-clone UML classes

• De correctly classified 93% of the clone UML classes

• Di correctly classified 89% of the UML classes

• Classes highlighted by both De and Di correctly classified 93%

• Classes highlighted by both De or Di correctly classified 91%

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.

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.

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.

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.

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 De 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.

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.

&