Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten aus Softwareprojekten zur Unterstützung der Wartbarkeitsoptimierung langlebiger Softwaresysteme

Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten aus Softwareprojekten zur Unterstützung der Wartbarkeitsoptimierung langlebiger Softwaresysteme

Entscheidern in Softwareunternehmen fehlen für eine wirtschaftlich sinnvolle Verbesserung der Wartbarkeit oft die geeigneten, handlungsunterstützenden Informationen zur Ableitung zielgerichteter Maßnahmen. Diese Arbeit versucht, durch die automatisierte Analyse von Softwaredaten (wie Quellcodedateien oder Fehlermeldungen) eine fundierte Entscheidungsgrundlage für die Optimierung der Wartbarkeit langlebiger Softwaresysteme zu schaffen.

Dies stellt sich jedoch als äußerst schwierig heraus. Kernprobleme stellen die unzuverlässige Datenbasis und die kontextabhängige Aussagekraft der gewonnenen Ergebnisse dar. Zusätzlich lassen sich aus der technischen Messung der Quellcodewartbarkeit auf Grund der Informationsflut keine wirtschaftlich sinnvollen Maßnahmen direkt ableiten.

Daher wird mit Hilfe der Softwaredatenanalyse der gesamte Quellcode in bewertbare Teilbereiche zusammengefasst, die es Entscheidern erlauben, situationsangemessene Maßnahmen zur Verbesserung der Wartbarkeit abzuleiten. Zudem können durch den eingeschränkten Betrachtungsraum die kontextabhängigen Ergebnisse sowie die zugrundeliegende Datenbasis manuell bewertet werden. Dadurch wird die faktenbasierte Priorisierung von Verbesserungsmaßnahmen unterstützt.

Markus Harrer

May 24, 2015
Tweet

More Decks by Markus Harrer

Other Decks in Research

Transcript

  1. Ergebnisse Masterarbeit Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten

    aus Softwareprojekten zur Unterstützung der Wartbarkeitsoptimierung langlebiger Softwaresysteme Markus Harrer 24.03.2015 (firmenunabhängige Version)
  2. Grundlegendes Vorhaben Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten

    aus Softwareprojekten zur Unterstützung der Wartbarkeitsoptimierung langlebiger Softwaresysteme (das klappt ja schließlich auch bei Unternehmensdatenanalysen...)
  3. Grundlegendes Ziele (generisch) Wo liegen die Möglichkeiten und Grenzen von

    Softwaredatenanalysen? Wie kann damit die Verbesserung der Wartbarkeit unterstützt werden? Wie weit ist bereits der praktische Einsatz möglich?
  4. Softwaredatenanalyse Grundidee Ausgangsbasis Jeder Schritt in der Entwicklung und Verwendung

    von Software erzeugt wertvolle Daten Ziel Neues, handlungsunterstützendes Wissen gewinnen • automatisiert mit Hilfe statistischer Methoden • aus vorhandenen Daten Weg (ohne das Rad neu zu erfinden) Unternehmensdaten Softwaredaten Data Mining Mining Software Repositories Business Intelligence Software Intelligence Data Analytics Software Analytics Predictive Analytics Recommendation Systems
  5. Softwaredatenanalyse Auswertebasis Softwaredaten Artefakte Produkt Machbarkeitsstudien Softwareanforderungen Grobentwürfe Implementierungsdokument Namenskonventionen

    Quellcode Lebenszyklus Kommunikationsdaten Software von Dritten Entwicklungsumgebungsdaten Programmnutzungsstatistiken Ausführungsaufzeichnungen Internet Metadaten Autor Erstellungsdatum Änderungsdatum Änderungsvermerk Verlinkte Ressourcen Digital verfügbare Softwaredaten aus Versionskontrollsystemen, Fehlerdatenbanken, Dateifreigaben, E-Mail-Archiven, Online-Foren etc.
  6. Softwaredatenanalyse Möglichkeiten • Welche meiner Komponenten sollte ich am sorgfältigsten

    testen? • Habe ich meinen Quellcode richtig strukturiert? • Wenn ich Funktion foo() ändere, muss ich dann noch mehr ändern? • Wie verwenden Benutzer typischerweise meine Software? • Welche Bestandteile der Software sind beim Kunden am beliebtesten?
  7. Softwaredatenanalyse Knackpunkt Softwaredaten sind selbst nicht auswertbar Verwendung von Softwaremetriken

    notwendig • Drücken bestimmte technische Eigenschaften von Softwaredaten in Zahlen aus • Sind aber nur Heuristiken
  8. Softwaredatenanalyse Limitationen Unzureichende Qualität der Datenbasis • Datenbasis kann falsch,

    unvollständig, unglaubwürdig, veraltet etc. sein Kontextabhängigkeit von Auswertungen • Ergebnisse meist nicht übertragbar • Teils widersprüchliche Aussagen (Statistische Unzulänglichkeiten) • Shotgun Surgery • Missachtete Einflussfaktoren (Korrelationen, Effektgrößen) • ...
  9. Softwaredatenanalyse Was nun? „Keine auf Empirie basierende Untersuchung kann ein

    „allumfassendes Ergebnis“ liefern.“ Betrand Meyer ⇒ Ende des Vortrags? Nein! Aktives Gegensteuern durch:  Einschränkung der kontextabhängigen Messergebnisse  Möglichkeit der manuellen Datenbewertung
  10. Wartbarkeitsoptimierung Was ist das? Definition Wartbarkeit „Software-Wartbarkeit ist ein Maß

    für die Leichtigkeit, mit der sich Programme korrigieren, ändern und erweitern lassen.“ Harry M. Sneed Maßnahmen zur Optimierung der Wartbarkeit • Softwaresanierung • Reengineering • Rewriting • Replacing • Redesign oder Refactoring
  11. Wartbarkeitsoptimierung „State of the Art“ Wartbarkeitsmessung Wir haben 5309 Methoden,

    die zu komplex sind! Wir haben 51021 Zeilen undokumentierten Code! Ja und? Entwickler Entscheider ExpressionParser hat eine zyklomatische Komplexität von 1967!
  12. Wartbarkeitsoptimierung Lösungsvision Entwickler Entscheider Analyst NetMAPI.cpp hat eine zyklomatische Komplexität

    von 47! Zukünftige Änderungen an der E-Mailfunktion können teuer werden OK, aber das Risiko gehe ich ein!
  13. Wartbarkeitsoptimierung Portfolioanalyse der Wartbarkeit Entwickler Entscheider Keine Wartbarkeits- optimierungen Niedrig

    priorisierte Wartbarkeits- optimierungen Ersetzung durch kommerzielle Produkte Kandidaten für Wartbarkeits- optimierungen Wartbarkeit Nutzen hoch hoch Kosten Qualität = Herstellung + Erhalt der Qualität Bewertbare Quellcode- bereiche notwendig!
  14. Wartbarkeitsoptimierung Lösungsidee Bewertbare Bereiche aus dem Quellcode extrahieren Bezeichner wie

    die Namen von • Klassen • Instanzen • Methoden • Variablen • Konstanten etc. enthalten semantische Informationen. Mehrere Quelltexte können daher semantisch ähnlich zueinander sein Wie lassen sich diese begrifflich abgeschlossenen Bereiche anhand von Quellcodebezeichnern extrahieren?
  15. Wartbarkeitsoptimierung Belange Belange sind begrifflich zusammengehörige Quellcodeteile, welche einen bestimmten

    Zweck in der Software realisieren. „...anything that stakeholders of a software project may want to consider as a conceptual unit.” Beispiele • Funktionalität • Geschäftsregeln • Übergreifende Programmfunktionen • Architektur- oder Entwurfsmuster
  16. Wartbarkeitsoptimierung Lösungsumsetzung Wartbarkeit Wartbarkeit Wartbarkeit Nutzen Wartbarkeit Wartbarkeit pro Quellcodedatei

    niedrig hoch niedrig hoch niedrig hoch hoch hoch Überprüfte Wartbarkeit pro Belang Wirtschaftliche Priorisierung der Wartbarkeitsoptimierungen Rechnungs- erstellung Kunden- verwaltung Fehlerproto- kollierung Messung der Wartbarkeit Begriffliche Gruppierung Manuelle Bewertung Priorisierung nach Nutzen Wartbarkeit pro Belang Hohe Datenqualität Niedrige Datenqualität Niedrige Datenquantität Hohe Datenquantität Bei Gelegenheit weiter verbessern Nichts tun Refactorings durchführen Fehlerproto- kollierung Kunden- verwaltung Rechnungs- erstellung Rechnungs- erstellung Kunden- verwaltung Fehlerproto- kollierung
  17. Wartbarkeitsoptimierung Zusammenfassung Bewertung der Wartbarkeit in begrifflich abgeschlossenen Bereichen 

    Nutzenbewertung der Wartbarkeit nach Belangen (=Kontexte)  Einschränkung der kontextabhängigen Messergebnisse  Möglichkeit der manuellen Datenbewertung
  18. Fallstudie Übersicht Umsetzung 3/3 Wartbarkeit nach Belangen Priorisierung nach Nutzen

    Wartbarkeitsoptimierung sofort durchführen Wartbarkeitsoptimierung nach hinten stellen Kunden- verwaltung Fehlerproto- kollierung „Fehler, Protokoll, speichern“ Fallspezifische Bewertung „Kunde, laden, speichern“ „Fehler, Protokoll, speichern“ „Kunde, laden, speichern“
  19. Fallstudie Übersicht Umsetzung 3/3 Wartbarkeit nach Belangen Priorisierung nach Nutzen

    Wartbarkeitsoptimierung sofort durchführen Wartbarkeitsoptimierung nach hinten stellen Kunden- verwaltung Fehlerproto- kollierung „Fehler, Protokoll, speichern“ Fallspezifische Bewertung „Kunde, laden, speichern“ „Fehler, Protokoll, speichern“ „Kunde, laden, speichern“
  20. Fallstudie Untersuchtes Produkt Softwareprodukt Merkmal DropOver Typ Webanwendung Entstehungsjahr 2013

    Programmiersprachen Java Quellcodedateien 206 Quellcodezeilen 9.781
  21. Fallstudie Quellcodedatei package at.dropover.comment.interactor; ... public class GetComments implements... {

    private final CommentGateway commentGateway; private final CommentRequestValidator requestValidator; private final CommentResponseBuilder commentDataBuilder; @Inject public GetComments(CommentGateway commentGateway, CommentRequestValidator validator) { this.commentGateway = commentGateway; this.requestValidator = validator; this.commentDataBuilder = new CommentResponseBuilder(); } ...
  22. Fallstudie Bezeichneridentifikation package at.dropover.comment.interactor; ... public class GetComments implements... {

    private final CommentGateway commentGateway; private final CommentRequestValidator requestValidator; private final CommentResponseBuilder commentDataBuilder; @Inject public GetComments(CommentGateway commentGateway, CommentRequestValidator validator) { this.commentGateway = commentGateway; this.requestValidator = validator; this.commentDataBuilder = new CommentResponseBuilder(); } ...
  23. Fallstudie Bezeichnerextraktion comment interactor util list util locale comment boundary

    get comments request model comment boundary get comments response model comment entity comment comment entity gateway comment gateway comment interactor validation comment request validator framework boundary synchronous delivery interactor boundary com google inject inject get comments synchronous delivery interactor boundary get comments request model get comments response model comment gateway comment gateway comment request validator request validator comment response builder comment data builder inject get comments comment gateway comment gateway comment request validator validator comment gateway comment gateway request validator validator comment data builder comment response builder override get comments response model sync get comments request model request request validator sync request list comment comments comment gateway read request site name locale locale request locale comment data builder get comments comments locale
  24. Fallstudie Semantische Analyse Topic-Modeling • Erkennt semantische Struktur aus einer

    Menge von Dokumenten • Dokumente bestehen aus Mischungen von Themen • Themen bestehen aus Mischungen von Wörtern • Zugehörigkeit von Dokumenten zu Themen lässt dann auf die semantische Ähnlichkeit schließen Latent-Dirichlet-Allocation • Einfacher, probabilistisch generativer Topic-Modeling-Ansatz • Probabilistisch: Mischungen sind diskrete Wahrscheinlichkeitsverteilungen • Generativ: Grundidee, dass jedes Dokument aus einer Dokument-Themen-Verteilung bzw. jedes Thema aus einer Thema-Wörter-Verteilung generiert wird.
  25. Fallstudie Ähnlichkeitsberechnung 0 1 2 0 0,00 0,44 0,93 1

    0,44 0,00 0,76 2 0,93 0,76 0,00 Verteilungen Abstand zwischen Verteilungen Abstandsberechnung mit Hellinger-Distanz Abstand zwischen zwei diskreten Wahrscheinlichkeitsverteilungen ⇒semantische Ähnlichkeit zwischen zwei Quellcodedateien
  26. /comment/boundary/AddCommentRequestModel.java /comment/boundary/ChangeCommentRequestModel.java /comment/boundary/CommentData.java /comment/boundary/GetCommentRequestModel.java /comment/boundary/GetCommentResponseModel.java ... /todo/boundary/AddTodoRequestModel.java /todo/boundary/ChangeTodoRequestModel.java /todo/boundary/DeleteTodoListRequestModel.java /todo/boundary/DeleteTodoListResponseModel.java

    /todo/boundary/DeleteTodoResponseModel.java ... /comment/boundary/AddCommentRequestModel.java 0,00 0,13 0,39 0,02 0,10 ... 0,63 0,68 0,55 0,49 0,43 ... /comment/boundary/ChangeCommentRequestModel.java 0,13 0,00 0,34 0,10 0,03 ... 0,67 0,72 0,60 0,56 0,51 ... /comment/boundary/CommentData.java 0,39 0,34 0,00 0,37 0,34 ... 0,73 0,77 0,68 0,65 0,62 ... /comment/boundary/GetCommentRequestModel.java 0,02 0,10 0,37 0,00 0,08 ... 0,63 0,69 0,56 0,50 0,44 ... /comment/boundary/GetCommentResponseModel.java 0,10 0,03 0,34 0,08 0,00 ... 0,66 0,71 0,59 0,54 0,49 ... Fallstudie Ähnlichkeitsmatrix
  27. Fallstudie Ähnlichkeitsmatrizen mail/... framework/... file/... creator/... comment/... scheduling/... site/... todo/...

    mail/... framework/... file/... creator/... comment/... site/... todo/... Quellcodedateien nach Pfad alphabetisch sortiert Quellcodedateien nach Pfad alphabetisch sortiert DropOver scheduling/...
  28. Fallstudie Bildung von Belangen Identifizierte Cluster Abstand zwischen Verteilungen 0

    1 2 ... 0 0,00 0,44 0,93 ... 1 0,44 0,00 0,76 ... 2 0,93 0,76 0,00 ... ... ... ... ... ... Abstände in 2D
  29. Identifikation der Cluster Erstellung der Punktordnung a) Datenobjekte im zwei-

    dimensionalen Raum c) Cluster b) Erreichbarkeitsplot d) Cluster Fallstudie Bildung von Belangen Prinzip des dichtebasierten Clustering-Verfahrens OPTICS-Xi
  30. Fallstudie Bildung von Belangen DropOver Evaluationstabelle Belang-Cluster-Plot ID Top 5

    Bezeichner Beschreibung Präzision Treffer- quote 0 request comment model response gateway Schnittstelle und Use-Cases für Kommentare 91,67% 57,89% 1 todo request model list response Schnittstelle und Use-Cases für Todo-Liste 96,55% 93,33% 2 scheduling request model response gateway Schnittstelle und Use-Cases für Terminplaner 100,00% 73,08% 3,6 request model file gateway response Schnittstelle, Use-Cases und Entitäten für Datei-Upload 88,89% 94,12% 4 exception creator site utils invalid Nicht eindeutig, meist Fehlerbehandlung 66,67% 33,33% 5 site location date creator description Schnittstelle, Use-Cases und Entitäten für Seitenerstellung 100,00% 45,00% 7 request scheduling model response javax REST-Webschnittstelle 90,00% 94,74% Durchschnitt 90,54% 70,21%
  31. Fallstudie Umsetzung 3/3 Wartbarkeit nach Belangen Priorisierung nach Nutzen Wartbarkeitsoptimierung

    sofort durchführen Wartbarkeitsoptimierung nach hinten stellen Kunden- verwaltung Fehlerproto- kollierung „Fehler, Protokoll, speichern“ Fallspezifische Bewertung „Kunde, laden, speichern“ „Fehler, Protokoll, speichern“ „Kunde, laden, speichern“
  32. Fallstudie Umsetzung 3/3 Wartbarkeit nach Belangen Priorisierung nach Nutzen Wartbarkeitsoptimierung

    sofort durchführen Wartbarkeitsoptimierung nach hinten stellen Kunden- verwaltung Fehlerproto- kollierung „Fehler, Protokoll, speichern“ Fallspezifische Bewertung „Kunde, laden, speichern“ „Fehler, Protokoll, speichern“ „Kunde, laden, speichern“
  33. Fallstudie Bewertung von Belangen Beispiel 1: Komplexität „Kommentarfunktion“ DropOver Super!

    Entwickler Entscheider Die Kommentarfunktion ist total einfach gestrickt.
  34. Fallstudie Bewertung von Belangen Beispiel 2: Komplexität „REST-Schnittstelle“ DropOver Genehmigt!

    Entwickler Entscheider Wir müssen etwas bei unserer technischen Schnittstelle vereinfachen.
  35. Fallstudie Bewertung von Belangen Beispiel 3: Komplexität „Datenpersistenz“ (auch ohne

    Belang sind Klassen bewertbar) DropOver Egal, kommt bald raus! Entwickler Entscheider Der Teil für die Datenspeicherung ist komplex!
  36. Handlungsempfehlungen Belastbare Erkenntnisse Aus dem theoretischen Teil • Technologie kein

    Problem • Softwareentwicklungswerkzeuge zusammen mit Data-Mining, Business-Intelligence, Data-Science, Big-Data etc. bieten ausreichend Unterstützung • Pauschale Auswertungen nicht sinnvoll • Datenqualität zu unsicher • Messungen immer kontextabhängig Aus der Fallstudie • Nutzen der Belang-Cluster-Bildung ist fraglich • Einige „Hot-Spots“ erkannt, aber viele Quellcodeteile nicht erfasst • Belang-Cluster bereits sehr stark ähnlich der Ordnerstruktur • Ähnlichkeitsmatrizen können zur Architekturbewertung dienen • Implizite und explizite „Konzepte“ erkennbar
  37. Handlungsempfehlungen Ausblick • Extraktion von Features statt Belangen • Feingranulare

    Messungen z. B. nach Use-Cases • Begrifflicher Abstand als Metrik für Programmverständlichkeit? • Vorsicht bei Datenschutz und Betriebsrat! • Weitere Testprojekte nur mit anonymisierten Datenmaterial aufwandsmäßig vertretbar
  38. Zusammenfassung • Softwaredatenanalyse bringt frischen Wind in die Softwareentwicklung •

    Aber keine ultimative Methode möglich • Daher gezielte Eingrenzung des Betrachtungskontextes vornehmen, um belastbare Aussagen zu schaffen • Wirtschaftliche Bewertung der Wartbarkeit nach Belangen durch Entscheider prinzipiell machbar • Extraktion von Belangen aber nur Symptombekämpfung • Besser: Quellcode nach begrifflicher Zusammengehörigkeit strukturieren, dann nach „Verzeichnissen“ (bzw. Modulen oder Packages) bewerten • Insgesamt große Ernüchterung