Die Computerentwicklung unserer heutigen Zeit ist geprägt durch große Fortschritte im Bereich der Hardware. Computer werden immer schneller und leistungsstarker und sind ein zentraler Bestandteil der Organisationen aller Unternehmen. Die Folge aus dieser Entwicklung ist, dass die Implementierung von immer modernen, leistungsfähigeren Softwareanwendungen möglich ist und auch von den meisten Organisationen erwartet wird. Leistungsfähige, qualitativ hochwertige Softwareanwendungen gewinnen in vielen Anwendungsbereichen immer mehr an Bedeutung, da sie zunehmend in vielen Projekten der Faktor sind, der über Erfolg und Misserfolg entscheidet. (Thaller 1994, S.14) In der Softwareentwicklung jedoch, erschweren leistungsfähige Softwaresysteme die einfache und schnelle Erstellung von zuverlässigen und verwaltbaren Code. Nicht selten bestehen Computerprogramme aus tausenden Zeilen von Code und bringen aufgrund ihres großen Umfangs enorme Schwierigkeiten mit sich. So ist unnötig komplexer Code oft Ursache für fehleranfällige Software und damit auch Ursache für eine schlechte Softwarequalität. Zudem kommt es mit steigernder
Komplexität zu einer Erhöhung der Änderbarkeit und Wartbarkeit von Software. Angesicht dieser Komplexitäts- und Umfangssteigerung, nimmt die Bedeutung des Messens von Softwarecode zur Qualitätskontrolle immer mehr zu. (Ligessmeyer 2009, S.232) Auch Tom DeMarco erkannte die Wichtigkeit von Softwaremessung und fasste dessen Bedeutung wie folgt zusammen:
„You can’t manage what you can’t control, and you can’t control what you don’t measure. To be effective software engineers or software managers, we must be able to control software development practice. If we don’t measure it, however, we will never have that control.” (DeMarco 1986)
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1 Einleitung
1.1 Problemstellung
1.2 Ziel dieserArbeit
1.3 Gliederung
2 Begriffsdefinition
2.1 Softwarekomplexität
2.2 Metrik und Maß
3 Software-Metriken
3.1 Definition
3.2 Auswahl geeigneter Software-Metriken
3.2.1 Problematik
3.2.2 GQM Ansatz
3.3 Interpretation der Messergebnisse
3.4 Darstellung der Messergebnisse
4 Für die Messung von Code-Komplexität relevante Metriken
4.1 Traditionelle Produktmetriken
4.1.1 LinesofCode
4.1.2 Halstead Metriken
4.1.3 McCabes zyklomatische Komplexität
4.2 Objektorientierte Produktmetriken
4.2.1 Coupling between Objects
4.2.2 Depth of InheritanceTree
4.2.3 Lack of Cohesion in Methods
5 Werkzeuge zur Ermittlung von statischen Produktmetriken
5.1 Statische Produktmetriken in Visual Studio generieren
5.2 Metrics Plugin fürEclipse
6 Zusammenfassung und Fazit
Literaturverzeichnis
Abbildungsverzeichnis
Abbildung 3.1: Kiviat-Diagramm
Abbildung 3.2: Kiviat-Diagramm mit einem zu hohen LOC Wert
Abbildung 4.1: Beispielcode: Fakultät einerZahl in C#
Abbildung 4.2: Kontrollflussgraph des Beispielcodes aus Abb. 4.1
Abbildung 4.3: Coupling between Objects
Abbildung 4.4: Depth of Inheritance Tree
Abbildung 5.1: Codemetrik-Ergebnisansicht in Visual Studio 2008
Abbildung 5.2: Eclipse Metric Plugin Ergebnisansicht
Tabellenverzeichnis
Tabelle 4.1: Sprachfaktoren ausgewählter Programmiersprachen
Tabelle 4.2: Anzahl der Operanden und Operatoren aus dem Beispielcode
Tabelle 4.3: Halstead Messergebnisse des Beispielcodes aus Abb. 4.1
Tabelle 5.1: Von Visual Studio erhobene Metriken
Tabelle 5.2: Von Eclipse Plugin bereitgestellte Metriken
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
1.1 Problemstellung
Die Computerentwicklung unserer heutigen Zeit ist geprägt durch große Fortschritte im Bereich der Hardware. Computer werden immer schneller und leistungsstarker und sind ein zentraler Bestandteil der Organisationen aller Unternehmen. Die Folge aus dieser Entwicklung ist, dass die Implementierung von immer modernen, leistungsfähigeren Softwareanwendungen möglich ist und auch von den meisten Organisationen erwartet wird. Leistungsfähige, qualitativ hochwertige Softwareanwendungen gewinnen in vielen Anwendungsbereichen immer mehr an Bedeutung, da sie zunehmend in vielen Projekten der Faktor sind, der über Erfolg und Misserfolg entscheidet. (Thaller 1994, S.14) In der Softwareentwicklung jedoch, erschweren leistungsfähige Softwaresysteme die einfache und schnelle Erstellung von zuverlässigen und verwaltbaren Code. Nicht selten bestehen Computerprogramme aus tausenden Zeilen von Code und bringen aufgrund ihres großen Umfangs enorme Schwierigkeiten mit sich. So ist unnötig komplexer Code oft Ursache für fehleranfällige Software und damit auch Ursache für eine schlechte Softwarequalität. Zudem kommt es mit steigernder Komplexität zu einer Erhöhung der Änderbarkeit und Wartbarkeit von Software. Angesicht dieser Komplexitäts- und Umfangssteigerung, nimmt die Bedeutung des Messens von Softwarecode zur Qualitätskontrolle immer mehr zu. (Ligess- meyer 2009, S.232) Auch Tom DeMarco erkannte die Wichtigkeit von Softwaremessung und fasste dessen Bedeutung wie folgt zusammen:
„You can't manage what you can't control, and you can't control what you don't measure. To be effective software engineers or software managers, we must be able to control software development practice. If we don't measure it, however, we will never have that control." (DeMarco 1986)
1.2 Ziel dieser Arbeit
In der Softwareentwicklung kommen zum Messen von Softwarekomplexität sogenannte Software-Metriken zum Einsatz. Das Ziel dieser Arbeit ist es zu zeigen, nach welchen Verfahren und inwieweit Software-Metriken die Komplexität von Softwarequellcode quantifizieren. Dabei wird der Focus in dieser Arbeit auf den Bereich der Metriken gelegt, die sich auf den Quellcode einer Software beziehen indem sie unterschiedliche Eigenschaften des Quellcodes messen.
1.3 Gliederung
Die nachfolgenden Kapitel dieser Arbeit gliedern sich wie folgt:
Das Kapitel 2 dient der Begriffsdefinition. Für das Verständnis von SoftwareMetriken wird in diesem Kapitel erläutert, was unter den Begriffen Softwarekomplexität, Metrik und Maß in der Softwareentwicklung zu verstehen ist. Das anschließende Kapitel 3 beschreibt die Grundlagen von Software-Metriken. Es wird zusätzlich darauf eingegangen wie die Messwerte dargestellt und sinnvoll interpretiert werden können. Der erste Teil von Kapitel 4 stellt einige der bekanntesten quellcodebasierten Software-Metriken kritisch betrachtet vor, während der zweite Teil auf objektorientierte Metriken eingeht, die speziell für die Messung von Software entwickelt wurden, welche mit objektorientierten Programmiersprachen realisiert wurden. Kapitel 5 behandelt einige Werkzeuge mit der Quellcode auf Basis von Software-Metriken untersucht werden können. Kapitel 6 schließt die Arbeit zusammenfassend ab.
2 Begriffsdefinition
2.1 Softwarekomplexität
Für eine adäquate Auseinandersetzung mit der Messung von Code-Komplexität ist es notwendig, dass zunächst darauf eingegangen wird, was unter dem Begriff Komplexität in der Softwareentwicklung verstanden wird.
Nach HÄRTL ist Komplexität als eine Eigenschaft eines Systems oder Modells definiert, welche die Beschreibung seines Gesamtverhaltens in einer beliebigen Sprache erschwert, selbst wenn man über vollständige Informationen über die Einzelkomponenten und ihre Wechselwirkungen verfügt. (2008, S.29) Übertragen auf die Softwareentwicklung, kann das abstrakte Produkt Software als das System oder Modell gesehen werden, dessen Verhalten durch ihre Lesbarkeit, Änderbarkeit und Wartbarkeit beschrieben wird. Softwarekomplexität ist demzufolge eine Eigenschaft einer Software die beschreibt, mit welcher Schwierigkeit Software von einem Software Entwickler verstanden, geändert oder erstellt wird. Softwarekomplexität in diesem Sinne ist nicht die subjektiv empfundene Kompliziertheit der Benutzer beim Arbeiten mit einem Software System und muss daher davon unterschieden werden.
Der Komplexitätsgrad einer Software hat einen direkten Einfluss auf dessen Qualität. Sie steht meistens in einem engen Zusammenhang mit der Robustheit der Software. Software, dessen Quellcodes komplex sind, sind überwiegend fehleranfälliger. Die Fehleranfälligkeit führt wiederum zu höheren Kosten, die sich aufgrund von Aufwand für die Beseitigung von Fehlern ergeben.
Um ungerechtfertigte Erhöhungen von Komplexität zu erkennen, ist es ratsam die Komplexität schon während des Entwicklungsvorgangs zu messen. Durch das Messen soll Transparenz geschaffen werden, damit frühzeitig Gegenmaßnahmen ergriffen werden können. Für die Messung bieten sich sogenannte SoftwareMetriken an, auf die in den folgenden Kapiteln noch ausführlich eingegangen wird.
Zunächst wird aber im Folgenden für das Verständnis von Software-Metriken erläutert, was unter dem Begriff Metrik und Maß zu verstehen ist.
2.2 Metrik und Maß
In der Literatur wird in dem Gebiet der Softwaremessung der Begriff Metrik oftmals als Synonym für den Begriff Maß verwendet. Streng genommen jedoch unterscheiden sich beide Begriffe in ihrer Aussage voneinander.
Metriken stellen bspw. in der Mathematik Eigenschaften eines mehrdimensionalen Raumes dar. Durch die dargestellten Eigenschaften wird die Entfernung zweier Punkte in einem Raum definiert. (Ligessmeyer 2009, S.234) Damit lassen sich die kürzesten Distanzen zwischen den Punkten finden und es lässt sich der nächste Nachbar identifizieren. Die Metrik in der Mathematik definiert also ein Abstandsmaß.
Bei einem Maß dagegen handelt es sich um eine Wertzuordnung zu einer abstrakten Eigenschaft eines Objektes aus einem System. Eine Eigenschaft wird demnach in einen konkreten Wert abgebildet. Die Regeln, wie ein Maß auf ein Objekt anzuwenden ist, müssen definiert sein. Die genaue und ausführliche Definition ist von besonderer Wichtigkeit, da ansonsten subjektive Messergebnise entstehen, die nicht vergleichbar wären. Bei dem Maß „Handschuhgröße eines Menschen" bspw. besagen die Regeln, dass der Daumen bei der Messung des Handumfanges nicht mit einfließen darf oder in welcher Position sich die Hand befinden muss.
Bei der Software Messung definieren Regeln, ähnlich wie bei Maß, welche Bestandteile der Software in die Messung eingehen dürfen. Am Ende der Messung steht ein Messwert, der einer Eigenschaft der Software zugeordnet wird. In diesem Sinne muss man korrekterweise von Maß als von Metrik sprechen. (Ligessmeyer 2009, S.234) Dennoch hat sich in der Praxis der Begriff der Metrik eingeprägt und wird auch in den IEEE-Standards als solches benutzt.
Obwohl gezeigt wurde, dass bei Messung von Software es im Grunde falsch ist von einer Metrik zu sprechen, wird dennoch in dieser Arbeit der Begriff Metrik synonym zum Begriff Maß verwendet, da der Begriff der Metrik in der Literatur seit Jahren eingeführt und etabliert ist.
3 Software-Metriken
3.1 Definition
Der IEEE-Standard 1061 von 1992 definiert eine Software-Metrik als eine Funktion, die eine Software Einheit in einen Zahlenwert abbildet. Der von der Funktion berechnete Wert ist interpretierbar als der Erfüllungsgrad einer Qualitätseigenschaft der Softwareeinheit. (IEEE, 1992) Mit Softwareeinheit ist in den meisten Fällen der zugrunde liegende Quellcode gemeint. Demnach wird gemäß der IEEE-Standard Definition aus der Komplexität des Quellcodes eine Kenngröße abgeleitet und linear auf die Codequalität abgebildet. Anhand der Codequalität kann dann auf die Qualität des Software Produktes als Ganzes geschlossen werden. Zu den Qualitätseigenschaften zählen bspw. Wartbarkeit, Effizienz, Flexibilität und Wiederverwendbarkeit.
Software-Metriken, die sich aus dem Quellcode erheben lassen, gehören den statischen Produktmetriken an. Sie messen die Software direkt anhand ihres Entwurfes und lassen sich zum größten Teil automatisiert ermitteln. Da die vorliegende Arbeit den Fokus auf die Messung des Quellcodes von Software hat, werden die wichtigsten statischen Produktmetriken, die zugleich auch zu den traditionellsten Metriken gehören, in Kapitel 4 ausführlich vorgestellt. Neben den statischen Produktmetriken wird noch zwischen dynamischen Produktmetriken unterschieden. Diese messen Software bei ihrer Ausführung und beurteilen ihre Leistungsfähigkeit und Zuverlässigkeit. Ein Beispiel für eine dynamische Software-Metrik ist die benötigte Ausführungszeit für bestimmte Funktionen oder die Anzahl der bei der Ausführung aufgetretenen Fehler. Sowohl statische, als auch dynamische Produktmetriken machen keine Aussage über den Entwicklungsfortschritt des Produktes. (Wallmüller 2001, S.48)
Neben den Produktmetriken wird noch zwischen Prozess- und Projektmetriken unterschieden. (Popp 2006, S.59) Prozessmetriken beziehen sich auf den gesamten Prozess der Softwareentwicklung, da sie Eigenschaften des Prozesses wie Produktivität oder Fehleranfälligkeit erfassen und auswerten. Die Werte können zur Kontrolle und zur Erkennung von problematischen Prozessschritten dienen. (Ligessmeyer 2009, S.234) Projektmetriken dagegen untersuchen unterschiedliche Merkmale des Projekts. Das können die Anzahl der Entwickler im Team, die Projektkosten oder die Einhaltung des Terminplanes sein.
Trotzt ihrer Unterschiede ist allen drei Kategorien von Software-Metriken gemeinsam, dass sie dem Zweck dienen, das abstrakte Produkt Software durch leichtverständliche Zahlen greifbar und damit vergleichbar zu machen. (Hoffmann 2008, S.248)
3.2 Auswahl geeigneter Software-Metriken
3.2.1 Problematik
Obwohl eine große Anzahl unterschiedlicher Software-Metriken existieren, besteht dennoch das Problem, dass es oft zum Scheitern beim Messen und Bewerten von Software kommt. Der Grund liegt in dem Unvermögen, die geeigneten Metriken zu finden, dessen Ergebnisse sinnvoll verwendet werden können. Viele Metriken führen zu verwendbaren Ergebnissen. Verwendbare Ergebnisse ergeben sich aber nicht, wenn entweder immer die am technisch schwersten oder die am technisch einfachsten zu realisierenden Metriken zum Einsatz kommen. Auch ist es nicht sinnvoll, so viele Metriken wie möglich von den existierenden Metriken anzuwenden, um möglichst viele Messwerte zu gewinnen. Die Qualität der Ergebnisse hängt nicht von der Schwierigkeit der technischen Realisierbarkeit bzw. Berechnung der Metrik ab, sondern zum größten Teil davon, welche Fragestellung mit dem gewonnen Messwerten beantwortet werden soll.
Bei der Auswahl der einzusetzenden Metriken sollte deshalb immer im Hinterkopf behalten werden, welche Ziele mit der Messung verfolgt werden. Die Ziele sollten dabei klar und wohl definiert sein. Diese Zielkonformität ist insofern auch wichtig, weil dadurch unnötige Messungen und die damit verbundenen Kosten von vornherein ausgeschlossen werden. Die Verwendung einiger wenige für die Zielerreichung identifizierten Metriken hilft, eine vielschichtige Sichtweise auf die zu messenden Softwareeinheiten zu erlangen und erhöht damit die Qualität der Messung.
3.2.2 GQM Ansatz
Ein bekannter Ansatz der helfen soll geeignete Metriken zielgerecht zu finden ist, der von Basili und Rombach entwickelte GQM (Goal Question Metric) Ansatz. Der GQM-Ansatz basiert auf einen Top Down Ansatz und sieht in einem ersten Schritt die Definition eines Messzieles vor. Im nächsten Schritt sollen Fragen zu dem Messziel formuliert werden. Diese Fragen helfen ein Verständnis dafür zu bekommen, wann das Messziel erreicht ist. Als letztes werden anhand der Beantwortung der Fragen geeignete Metriken ausgewählt.
3.3 Interpretation der Messergebnisse
Ein weiterer Grund für das Scheitern von Messen und Bewerten von Software liegt in der Schwierigkeit der Interpretation der gewonnen Messwerte. Bei Mes- sen von Software mittels Metriken kann zum größten Teil nicht auf fundierte Erkenntnisse zurückgegriffen werden, wie dies etwa beim Messen von physikalischen Größen der Fall ist. Es existieren keine einheitlichen Grenzwerte mit denen die Messergebnisse verglichen werden können. Welche Werte noch als akzeptabel oder als nicht mehr akzeptabel gelten, müssen aber vor dem Messvorgang feststehen. Existieren keine Vergleichswerte für die Messergebnisse, so ist auch keine sinnvolle Interpretation der Ergebnisse möglich und die Metrik erweist sich als nutzlos. Da durch die Messung unnötiger Aufwand betrieben und Ressourcen verbraucht wurden, ist die Durchführung der Messung zudem auch schädlich für die Software.
Die Ermittlung von Grenzwerten kann z.B. mit Hilfe von Erfahrungswissen, bspw. aus Expertenbefragungen oder durch Beobachtungen von vergleichbaren bereits vergangenen Projekten, erfolgen. Überschreitet der Messwert einer Metrik seinen Grenzwert, ist dies jedoch kein eindeutiges Indiz für das Vorhandensein von entsprechend vielen Fehlern, die zuverlässigkeitsmindernd wirken. Vielmehr sind diese sogenannten Ausreißer Anzeichen für einen nicht optimalen Softwareentwurf und sollten daher näher betrachtet werden. Eine Metrik dient also immer nur als ein Indikator und nicht als ein endgültiger Nachweis bestimmter Fehler. (Ligessmeyer 2009, S.246; Popp 2006, S.64)
3.4 Darstellung der Messergebnisse
Für eine effektive Auswertung der Messergebnisse ist es sinnvoll die Werte in einer übersichtlichen Form zu visualisieren. Die Darstellung der Messergebnisse geschieht in der Regel auf zwei Arten, zu einem in tabellarischer Form und zum anderen in grafischer Form. Der Nachteil der tabellarischen Form liegt in ihrer Unübersichtlichkeit. Die grafische Darstellung der Messwerte hingegen ist für das menschliche Auge überschaubarer. Ausreißer können in einer Grafik schneller und leichter erkannt werden.
In der Softwaremessung wird zur Darstellung der Messergebnisse eine grafische Darstellung durch ein Kiviat-Diagramm bevorzugt, das aufgrund seiner äußeren Gestalt auch als Netz- oder Radardiagramm bezeichnet wird. Ein Kiviat- Diagramm bildet Messergebnisse unterschiedlicher Metriken kombiniert ab. Jede der Metriken wird durch eine separate Achse abgebildet, die alle ihren Anfang im Mittelpunkt des Diagrammes haben und jeweils mit gleichen Winkelabständen nach außen verlaufen. (Hoffmann 2008, S.270) Auf den Achsen werden die unteren und oberen Grenzwerte der jeweiligen Metriken aufgetragen und jeweils die Nachbarwerte durch Linien miteinander verbunden. Auf diese Weise ergeben sich drei Schichten im Diagramm. Die mittlere Schicht definiert die Messwerte die als Normal festgelegt wurden. Die innere und äußere Schicht repräsentiert die Werte, welche die festgelegte Norm je nachdem unter oder überschreiten. Für jede der Metriken wird zudem die ermittelten Messergebnisse auf den jeweiligen Achsen eingetragen und die Messergebnisse ebenfalls durch Linien mit ihren Nachbarwerten verbunden. Der dadurch entstandene Linienzug sollte möglichst in der mittleren Schicht, dem Normalwertbereich, liegen.
Abbildung 3.1 zeigt ein solches Kiviat-Diagramm, in dem die Messergebnisse von fünf kombinierten Produktmetriken im Normallbereich liegen. Der Normallbereich wird in der Abbildung durch die weiße Schicht gekennzeichnet.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.1: Kiviat-Diagramm1
Quelle: in Anlehnung an Ligessmeyer 2006, S. 248
Zum Vergleich zeigt Abbildung 3.2 ein Kiviat-Diagramm in dem nicht alle Messergebnisse der kombinierten Produktmetriken im Normallbereich liegen. Der Messwert der Umfangsmetrik Lines of Code (LOC) liegt außerhalb des Normalbereiches, weil es einen zu hohen Wert besitzt. Der abweichende Wert wird durch die Struktur des Kiviat-Diagramms für den Beobachter leicht ersichtlich gemacht.
[...]
1 Innerhalb der Grafik wurden andere Messwerte der einzelnen Metriken gewählt, so dass sich ein anderes Bild des Kiviat Diagrammes ergibt
-
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X.