Der Vortrag beschäftigt sich mit der Bedeutung und Nutzung von Softwaremetriken, insbesondere unter Verwendung von Open-Source-Tools, um Transparenz zu gewährleisten und die Qualität der Software zu verbessern. Er erörtert, welche positiven Effekte Metriken auf Projekte haben können, und stellt verschiedene Werkzeuge zur Erstellung und Analyse von Metriken vor. Zudem wird betont, dass die Auswahl der Metriken gut durchdacht sein sollte und diese im Entwicklungsprozess integriert werden müssen.

1. Die Macht der Zahlen
Software-Metriken mit Open Source Werkzeugen
Gerrit Beine
mail@gerritbeine.com
1

2. Ziel des Vortrags
● Pro und Contra von Softwaremessungen abwägen
● Vorstellungen vermitteln, darüber
● was Metriken im positiven Sinne bewirken können und
● was Metriken in Projekten anrichten können
● Einige Tools vorstellen, die sich gut zur Erstellung von Metriken eignen
● Einen Überblick schaffen und zum Einsatz von Metriken motivieren
● Was nicht im Vortrag behandelt wird
● Laufzeitmetriken, Testmetriken und Anforderungsmetriken
● Details zu den vorgestellten Metriken
● Details zu den vorgestellten Tools
2

3. Wie alles begann...
3

4. Wie alles begann...
● Gegeben sei ein Projekt mit relativ hoher Mitarbeiterfluktuation
● Neue Mitarbeiter benötigen lange, um sich einzuarbeiten
● Die erste Frage: Warum?
● Die Antwort: Weil alles so kompliziert ist!
● Die Lösung: Wir dokumentieren!
● Aber Moment...
● Dokumentieren ist aufwändig und kostet Zeit
● Niemand macht es gerne
● Die bessere Lösung: Wir dokumentieren nur die Public API!
4

5. Und dann geschah Folgendes...
1 // ...
2
3 /**
4 * Delegates to privateMethod
5 */
6 public void doSomething() {
7 this.doSomethingReally();
8 }
9
10 private void doSomethingReally() {
11
12 }
13
14 // ...
5

6. Wir geben nicht auf
● Die Erkenntnis: So wird das nix!
● Der nächste Schritt: alle Methoden müssen dokumentiert werden!
● Aber Moment...
● Die 80/20 Regel sagt, dass wir eh nur 80% schaffen!
● Die bessere Lösung: 80% aller Methoden müssen dokumentiert werden!
6

7. Jetzt passierte dies:
1 // ...
2
3 /**
4 * Return X
5 */
6 public int getX() {
7 return this.x;
8 }
9
10 /**
11 * Return Y
12 */
13 public int getY() {
14 return this.Y;
15 }
16
17 // ...
18
19 public void doSomethingExtremeComplex() {
20
21 }
22
23 // ...
7

8. Was lernen wir daraus?
Wer nur 80% anstrebt erreicht davon auch nur 80%!
(Insgesamt sind das dann 64%)
8

9. Wie es weiter ging...
● Beschluss, dass alle Klassen, Schnittstellen, Methoden und Attribute zu 100%
dokumentiert werden müssen.
● Aber Moment...
● Auf den Inhalt kommt es an!
● Was eine Methode macht, kann ein Entwickler selbst sehen.
● Das Warum ist entscheidend
● Also statt Prosa-Text einen Link auf die User Story oder das Requirement, die die Methode,
Klasse... begründen
● Erreicht: 93% Dokumentation (gemessen)
● Neue Entwickler waren nach zwei Wochen fit
9

10. Warum nur Open Source Werkzeuge?
10

11. Warum nur Open Source Werkzeuge?
● Der wichtigste Grund: Transparenz
● Außerdem: Verfügbarkeit
● Metriken, die nicht verstanden werden (können), werden in Frage gestellt
● Metriken, die nicht jeder selbst anwenden kann, sind zu schwerfällig
● Open Source Werkzeuge sind frei verfügbar und machen transparent was sie tun
11

12. Der Maintainability Index
Die Formel ● MI < 65: sehr schlechte Qualität
● 65 < MI < 85: mittlere Qualität
● 85 < MI: sehr gute Qualität
MI=
171 − 5, 2 × ln(aveV ) ● Für ein Projekt ermittelter Wert (mit
− 0, 23 × aveVG2 proprietärem Tool): 165
− 16, 2 × ln(aveLOC)
● Das muss ein gutes Projekt sein!
● Von Hand berechnet: 28
12

13. Maintainability Index
● Die Anwendung enthält nur 35 Entitäten
● Die Sicht links ist die Package-Ebene
● Die durchschnittliche Anzahl von
Abhängigkeiten pro Package ist 35
● Was ist der Maintainability-Index in dem
Fall wert?
● Das Bild versteht jeder, die 165 nicht!
13

14. Tools & Tipps
14

15. Tools & Tipps
● Vergesst die LOC – Lines of Code interpretiert jeder anders!
● Stattdessen besser: NCSS – Non Commenting Source Statements als Meßgrundlage
● Interessante Fakten
● avg NCSS / Klasse
● avg NCSS / Methode
● avg Complexity / Methode
● avg Warnings / NCSS
● avg Errors / NCSS
● Abdeckungsgrad der API-Dokumentation
● Wichtig dabei sind die Trends!
● Metriken immer mit Code Reviews verbinden
15

16. Wie ermittelt man diese Werte?
● Unter Java
● PMD (http://pmd.sourceforge.net/)
Source Code Analyse, Regelbasiert, Komplexität und Fehlersuche
● FindBugs (http://findbugs.sourceforge.net/)
Byte Code Analyse, Musterbasiert, Fehlersuche
● JavaNCSS (http://www.kclee.de/clemens/java/javancss/)
Source Code Analyse, Fakten sammeln
● CheckStyle (http://checkstyle.sourceforge.net/)
Source Code Analyse, Regelbasiert, Komplexität und Konventionen
● JDepend (http://clarkware.com/software/JDepend.html)
Byte Code Analyse, Abhängigkeiten, Martin-Metriken
● OOMetrics & DependencyFinder (http://depfind.sourceforge.net/)
Byte Code Analyse, Abhängigkeiten, Martin-Metriken, Chidamber & Kemerer
● Sonar (http://www.sonarsource.org/)
Qualitäts-Management, integriert etliche der genannten Werkzeuge
16

17. Wie ermittelt man diese Werte?
● Unter PHP
● PHP Depend (http://pdepend.org/)
Pendant zu JDepend
● PHP Mess Detector (http://phpmd.org/)
Pendant zu PMD bzw. CheckStyle, haupsächlich an PMD angelehnt
● PHP_CodeSniffer (http://pear.php.net/package/PHP_CodeSniffer)
Pendant zu CheckStyle
● Unter Perl
● use strict; use warnings;
● Perl::Critic (siehe Vortrag von Renée Bäcker aus dem letzten Jahr)
● Perl::Metrics, Perl::Metrics::Lite, Perl::Metrics::Simple
17

18. Beispiel einer PMD-Regel
18

19. new DateTime() mit PMD verbieten
1 <rule name="DontUseNewDateTime"
2 message="Use of new DateTime() is not allowed"
3 class="net.sourceforge.pmd.rules.XPathRule">
4 <description>
5 New DateTime object should be created using DateTimeFactory
6 </description>
7 <properties>
8 <property name="xpath">
9 <value>
10 <![CDATA[
11 //VariableDeclarator[../Type[@Array='false']]
12 //AllocationExpression/ClassOrInterfaceType[@Image='DateTime'] |
13 //Statement//AllocationExpression/ClassOrInterfaceType[@Image='DateTime']
14 ]]>
15 </value>
16 </property>
17 </properties>
18 <priority>3</priority>
19 <example>
20 <![CDATA[
21 /* example code */
22 ]]>
23 </example>
24 </rule>
19

20. Beispiel Martin-Metriken
20

21. Verteilung der Abstraktheit
21

22. Verteilung der Instabilität
22

23. Martin-Distanz
23

24. Auswählen von Metriken
24

25. Auswählen von Metriken
● Auswahl ist im Allgemeinen nicht trivial
● Nicht jede Metriken passt zu jedem Projekt oder Entwickler
● Gute Strategie ist GQM (Goal – Question – Metric)
● Zuerst Ziel festlegen
● Dann konkrete Frage(n) formulieren
● Schließlich Metrik(en) auswählen, die diese formale Antwort gibt
● Eine gute Einführung liefert Wikipedia:
http://de.wikipedia.org/wiki/Goal_Question_Metric
25

26. Kommunikation & Anwendung von Metriken
26

27. Kommunikation & Anwendung von Metriken
● Metriken bieten Chancen und bergen Gefahren
● Metriken müssen abgestimmt und verstanden sein
● Metriken liefern immer nur Indizien
● Metriken, die mit absoluten Zahlen arbeiten, sollten immer im Trend betrachtet werden
● Abweichungen identifizieren und begründen – oder eliminieren
● Es gibt nur drei Arten von Problemen
● Bedrohende – für die gilt Null-Toleranz
● Unschönheiten – für die gilt eine Obergrenze, z.B. 8% der NCSS
● Egales – das sollte unbedingt ignoriert werden
● Tools sollten in den Entwicklungsprozess integriert werden
● Continuous Integration z.B. in Jenkins & Co.
● Ins Source Code Repository, z.B. über den pre-commit Hook von Subversion
27

28. Viel Spaß noch!
Gerrit Beine
Stadtparking 18
08523 Plauen
http://www.gerritbeine.com/
28