Lade Inhalt...

Messung und Bewertung von Code-Komplexität

Seminararbeit 2010 35 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

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 Fort­schritte im Bereich der Hardware. Computer werden immer schneller und leis­tungsstarker und sind ein zentraler Bestandteil der Organisationen aller Unter­nehmen. 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 brin­gen aufgrund ihres großen Umfangs enorme Schwierigkeiten mit sich. So ist un­nö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 Software­messung 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 meas­ure. To be effective software engineers or software managers, we must be able to con­trol 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 so­genannte 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 Software­Metriken wird in diesem Kapitel erläutert, was unter den Begriffen Software­komplexitä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 be­kanntesten quellcodebasierten Software-Metriken kritisch betrachtet vor, wäh­rend der zweite Teil auf objektorientierte Metriken eingeht, die speziell für die Messung von Software entwickelt wurden, welche mit objektorientierten Prog­rammiersprachen realisiert wurden. Kapitel 5 behandelt einige Werkzeuge mit der Quellcode auf Basis von Software-Metriken untersucht werden können. Kapi­tel 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) Übertra­gen 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 demzu­folge 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 Kompli­ziertheit der Benutzer beim Arbeiten mit einem Software System und muss da­her davon unterschieden werden.

Der Komplexitätsgrad einer Software hat einen direkten Einfluss auf dessen Qua­lität. Sie steht meistens in einem engen Zusammenhang mit der Robustheit der Software. Software, dessen Quellcodes komplex sind, sind überwiegend fehler­anfälliger. Die Fehleranfälligkeit führt wiederum zu höheren Kosten, die sich auf­grund 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 Software­Metriken 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 oft­mals als Synonym für den Begriff Maß verwendet. Streng genommen jedoch un­terscheiden sich beide Begriffe in ihrer Aussage voneinander.

Metriken stellen bspw. in der Mathematik Eigenschaften eines mehrdimensiona­len 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 ab­strakten 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 Defi­nition 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 Be­standteile der Software in die Messung eingehen dürfen. Am Ende der Messung steht ein Messwert, der einer Eigenschaft der Software zugeordnet wird. In die­sem Sinne muss man korrekterweise von Maß als von Metrik sprechen. (Ligess­meyer 2009, S.234) Dennoch hat sich in der Praxis der Begriff der Metrik ein­geprä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 Funk­tion, die eine Software Einheit in einen Zahlenwert abbildet. Der von der Funkti­on berechnete Wert ist interpretierbar als der Erfüllungsgrad einer Qualitätsei­genschaft der Softwareeinheit. (IEEE, 1992) Mit Softwareeinheit ist in den meis­ten 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 wer­den. Zu den Qualitätseigenschaften zählen bspw. Wartbarkeit, Effizienz, Flexibili­tä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 vor­liegende 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 Soft­ware-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 Entwicklungsfort­schritt 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 ge­samten Prozess der Softwareentwicklung, da sie Eigenschaften des Prozesses wie Produktivität oder Fehleranfälligkeit erfassen und auswerten. Die Werte kön­nen zur Kontrolle und zur Erkennung von problematischen Prozessschritten die­nen. (Ligessmeyer 2009, S.234) Projektmetriken dagegen untersuchen unter­schiedliche 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 ge­meinsam, dass sie dem Zweck dienen, das abstrakte Produkt Software durch leichtverständliche Zahlen greifbar und damit vergleichbar zu machen. (Hoff­mann 2008, S.248)

3.2 Auswahl geeigneter Software-Metriken

3.2.1 Problematik

Obwohl eine große Anzahl unterschiedlicher Software-Metriken existieren, be­steht dennoch das Problem, dass es oft zum Scheitern beim Messen und Bewer­ten 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 Er­gebnisse hängt nicht von der Schwierigkeit der technischen Realisierbarkeit bzw. Berechnung der Metrik ab, sondern zum größten Teil davon, welche Fragestel­lung 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 wich­tig, weil dadurch unnötige Messungen und die damit verbundenen Kosten von vornherein ausgeschlossen werden. Die Verwendung einiger wenige für die Ziel­erreichung 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 be­kommen, wann das Messziel erreicht ist. Als letztes werden anhand der Beant­wortung 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 Er­kenntnisse zurückgegriffen werden, wie dies etwa beim Messen von physikali­schen Größen der Fall ist. Es existieren keine einheitlichen Grenzwerte mit denen die Messergebnisse verglichen werden können. Welche Werte noch als akzepta­bel 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 ent­sprechend vielen Fehlern, die zuverlässigkeitsmindernd wirken. Vielmehr sind diese sogenannten Ausreißer Anzeichen für einen nicht optimalen Softwareent­wurf 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 unte­ren 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 Wer­te, welche die festgelegte Norm je nachdem unter oder überschreiten. Für jede der Metriken wird zudem die ermittelten Messergebnisse auf den jeweiligen Ach­sen eingetragen und die Messergebnisse ebenfalls durch Linien mit ihren Nach­barwerten 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 Mess­ergebnisse der kombinierten Produktmetriken im Normallbereich liegen. Der Messwert der Umfangsmetrik Lines of Code (LOC) liegt außerhalb des Normalbe­reiches, 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

Details

Seiten
35
Jahr
2010
ISBN (eBook)
9783640578542
ISBN (Buch)
9783640578238
Dateigröße
753 KB
Sprache
Deutsch
Katalognummer
v147850
Institution / Hochschule
Universität Duisburg-Essen – Fachbereich Wirtschaftswissenschaften
Note
1,3
Schlagworte
Metriken Komplexität Halstead McCabe Lines of code LOC Zyklomatische Kompleität Softwarekomplexität Coupling between Objects Depth of Inheritance Tree Lack of Cohesion in Methods Kiviat Diagramm Objektorientierte Metriken Softwaremaß

Autor

Teilen

Zurück

Titel: Messung und Bewertung von Code-Komplexität