Upload
byron-lucas
View
225
Download
2
Tags:
Embed Size (px)
Citation preview
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.
&