Empirische Softwaretechnik Kosten und Nutzen von UML in der Wartung Dr. Victor Pankratius Andreas Höfer Wintersemester 2009/2010

Transkript

1 Empirische Softwaretechnik Dr. Victor Pankratius Andreas Höfer Wintersemester 2009/2010 IPD Tichy, Fakultät für Informatik

2 Pflichtlektüre hierzu: Dzidek, Arisholm, Briand, A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance, IEEE Transactions on Software Engineering, 34(3), Mai/Juni 2008,

3 Warum UML? Eingesetzt zur Spezifikation und Dokumentation von objekt-orientierter Software. UML soll das Verständnis von großen Systemen erleichtern, höhere Qualität ermöglichen, Architekturverfall in der Wartung verhindern helfen, bessere Kommunikation im Team und von Entwicklern zu Wartungspersonal herstellen. UML wird universell gelehrt, aber die Effektivität von UML wird auch angezweifelt (zus. Kosten, ohne wesentliche Vorteil)

4 Kontrolliertes Experiment zu UML Teilnehmer: 20 professionelle Entwickler (Berater, durchschnittlich 5 Jahre Erfahrung mit Java) Aufgabe: 5 Wartungsaufgaben, die in 1-2 Wochen durchgeführt wurden. Keine Zeitbegrenzung. 10 Entwickler führen die Aufgabe ohne UML durch. 10 Entwickler führen die Aufgabe mit UML-Dokumentation durch (und müssen die UML-Dokumentation nachführen) Abhängige Variablen: Aufwand, funktionale Korrektheit, Entwurfsqualität. UML-Subjekte bekamen einen Auffrischungskurs für UML (1 Tag) und UML-Werkzeug Borland Together for Eclipse

5 Abhängige Variablen T: Zeit zur Durchführung der Änderungen, ohne Diagramm-Modifikation. T : Zeit zur Durchführung der Änderungen mit Diagramm- Modifikation. C: Anzahl von abgegebenen Lösungen mit Fehlern (Experimentator führt Akzeptanztest durch). Q: Entwurfsqualität nach bestimmten Kriterien

6 Hypothesen Bis auf die zweite Hypothese waren alle einseitig. Bei T ist unklar, ob die Diagramm-Modifikation zu einer Zeitersparnis führt

7 Bearbeitete Software: BESTWeb BESTWeb ist ein Datenbank-Klient in Java mit der Struts- Bibliothek. BestWeb gibt Zugang zu Zeitschriftenartikel über Kostenund Aufwandsschätzung für Software, die in einer Datenbank nach gewissen Kriterien kategorisiert sind. Umfang: 6 Pakete, 50 Klassen, 2900 Zeilen Java, 275 Methoden, 17 Java Server Pages, max. Vererbungstiefe 3. BESTWeb ist ausführlich dokumentiert, auch ohne UML (Benutzerhandbuch, Architekturbeschreibung, Datenbankschema, Javadoc.) BESTWeb war allen Teilnehmern unbekannt

8 Zusätzliche UML-Dokumentation Klassendiagramme für die 6 Pakete 16 Anwendungsfälle, mit Sequenzdiagramm für jeden Anwendungsfall (zw. 2 und 30 Botschaften pro Sequenzdiagramm) Zustandsdiagramme werden erwähnt, aber nicht wie viele

9 Ablauf

10 Akzeptanztest Durchgeführt durch den Experimentator Bei funktionalen Änderungen basierte der Testplan auf den Sequenzdiagrammen; alle Botschaften, alle Ausnahmesituationen und alle Fallunterscheidungen wurden überprüft. Bei neuen Funktionen wurde nach Prüflisten vorgegangen, die von der funktionalen Spezifikation abgeleitet waren. Damit wurde funktionale Korrektheit und Vollständigkeit aller endgültigen Lösungen erreicht

11 Aufgabenkomplexität

12 Entwurfsqualität Aufgaben wurden in Teilaufgaben zerlegt und jede Teilaufgabe als akzeptabel oder inakzeptabel bewertet. Folgende Eigenschaften führten zu Bewertung inakzeptabel : Code-Duplikation, anstatt den Code direkt aufzurufen, Hinzufügen überflüssiger Elemente (z.b. Hinzufügen einer Klasse, obwohl eine geeignete vorhanden war), Falsche Zuordnung von Code zu einer Klasse Verteilung von Logik über die gesamte Anwendung, obwohl ein Ort gereicht hätte; Try/catch-Mechanismus benutzt für normale Fälle, anstatt für Ausnahmen

13 Analyse des Aufwands (in Min.) (NoUML-UML)/UML p-werte

14 Zeitbedarf für UML Deutlicher Lerneffekt von Task 1 bis Task 5 (System wird vertraut). Außerdem wird der Umgang mit den Werkzeugen zur UML-Nachführung schneller

15 Analyse funktionale Korrektheit

16 Analyse Entwurfsqualität

17 Zusammenfassung Ergebnisse Insgesamt ist die UML-Gruppe ohne UML-Nachführung 1,4 % schneller (praktisch unbedeutend, auch nicht stat. signifikant) Mit UML-Nachführung ist die UML-Gruppe 14% langsamer (auch das nicht stat. signifikant). Korrektheit besser in allen Aufgaben, um 50%-100% (stat. signifikant). (beachte Korrektheitsmaß). D.h. bei nicht-uml muss mehr in Test investiert werden. Entwurfsqualität besser, insbes. in erster Aufgabe (wo System noch unbekannt ist). Möglicherweise wird durch UML einem Architekturverfall entgegengewirkt

18 Kritik Realistisch, wegen professioneller Entwickler (auch sehr teuer: 3 Jahre Durchführungszeit, aber wichtig für Praktiker) Analyse unterschätzt den Unterschied beim Aufwand, da die Zeit für Qualitätssicherung nicht erfasst wurde. Sie ist ohne UML höher, da mehr Lösungen abgegeben wurden. Betrifft nur Wartung, und hier nur Erweiterungen. Was passiert bei Erstenwicklung?