Zu dieser Karteikarte gibt es einen kompletten Satz an Karteikarten. Kostenlos!
8
Was ist eine Metrik und welche Softwaremetriken gibt es?
Eine Metrik ist eine Abbildung einer Eigenschaft (z.B. eines Softwaresystems) auf eine skalare oder vektorielle Größe einer vorher festgelegten Skala. Hierbei kann eine Metrik als Modell angesehen werden, da sie Verkürzungs-und Abbildungsmerkmal erfüllt. Metriken sind deskriptiv/präskriptiv (beschreiben Zustand wie er ist bzw. sein soll), diagnostisch/prognostisch (beschreiben bestehenden oder zukünftigen Zustand) und robust bzw. unterlaufbar (d.h. es gibt (k)eine Möglichkeit den Wert der Metrik zu beeinflussen). Eine Pseudometrik ist eine Metrik, die sich aus geschätrzten Werten ergibt, da man sie nicht direkt durch Messen eines Wertes ermitteln kann. Z.B. kann man den BMI nicht direkt messen, sondern benötigt die Hilfsgrößen Größe und Gewicht, um den Wert der Metrik dann zu berechnen. Hier eine kleine Auswahl an Metriken:
Komplexität nach McCabe
Man betrachtet ein Flussdiagramm und berechnet die Komplexität des Programms zu:
wobei e die Zahl der Kanten, n die Zahl der Knoten und p die Zahl der Außenverbindungen ist. Dies entspricht der zyklomatischen Zahl eines Graphen. Die Metrik ist sehr einfach und liefert nicht immer aussagekräftige Werte, da z.B. komplexe Datenstrukturen bei der Berechnung keine Beachtung finden.
Software Science nach Helsted
Hier liegt die Idee zugrunde, dass ein Programm zum größten Teil aus Operanden und Operatoren besteht. Helsted definiert:
Hieraus werden Metriken wie z.B. die Zahl der Elementarentscheidungen eines Programmieres abgeleitet. Die Metriken sind allerdings nicht überprüft und deren Aussagekraft ist somit eher fraglich.
COCOMO
Pseudometrik zum Ermitteln der Kosten eines Softwareprojektes nach Boehm. Die Formeln sind aus großen Mengen archivierter Projektdaten abgeleitet und verifiziert. Einflussfaktoren auf die Projektlaufzeit sind:
- DSI (Delivered Source Instructions, entspricht Lines of Code)
- Art des Projektes (Organic: kleine Projekte, in denen keine Entwicklung von nichttrivialen Algorithmen von Nöten ist, Semidetached: mittlere Projekte, wobei das Entwicklerteam aus erfahrenen und unerfahrenen Mitarbeitern besteht, Embedded: Entwicklungsprojekte für neuen Einsatzbereich in einem großen Projektteam)
- Anforderungen an die Verlässlichkeit der Software
- Komplexität des Produktes
- Erfahrung der Entwickler in der Programmiersprache
- Einsatz von Software Tools
...
Je nach Menge der Daten, die zu einem Projekt vorliegen, kann die Schätzung mit unterschiedlichem Detaillierungsgrad erfolgen. Hier wird zwischen den 3 Schätzungsarten Basic,Intermediate und Detailed unterschieden.
Objektorientierte Metriken
Chidamber und Kemerer definierten 1994 verschiedene Metriken für die objektorientierte Programmierung.
Weighted Methods per Class (WMC)
: Komplexität der Methode
: Zahl der Methoden
Depth of Inheritance (DIT)
Tiefe der Klasse im Vererbungsbaum
Number of Children of a class (NOC)
Anzahl der Unterklassen einer Klasse
Coupling between classes
Anzahl der Klassen, die eine Klasse benutzt
Response for a class (ROC)
Anzahl aller möglichen auszuführenden Methoden einer Klasse (d.h. Anzahl der Methoden der Klasse selbst + Anzahl der Methoden, die über Umwege, also z.B. durch Klassen, die die betrachtete Klasse benutzt, erreicht werden können.
Lack of cohesion in methods (LCOM)
Ermittelt den fehlenden Zusammenhalt der Methoden einer Klasse. Die Zahl sollte möglichst gering sein (am besten 0), da man innerhalb einer Klasse eine hohe Methodenkopplung erwartet (siehe Designprinzipien). Berechnungsvorschrift:
wenn , sonst 0 mit
: Anzahl der Methodenpaare mit keinem gemeinsamen Attribut
: Anzahl der Methodenpaare mit einem oder mehr gemeinsamen Attributen
Komplexität nach McCabe
Man betrachtet ein Flussdiagramm und berechnet die Komplexität des Programms zu:
wobei e die Zahl der Kanten, n die Zahl der Knoten und p die Zahl der Außenverbindungen ist. Dies entspricht der zyklomatischen Zahl eines Graphen. Die Metrik ist sehr einfach und liefert nicht immer aussagekräftige Werte, da z.B. komplexe Datenstrukturen bei der Berechnung keine Beachtung finden.
Software Science nach Helsted
Hier liegt die Idee zugrunde, dass ein Programm zum größten Teil aus Operanden und Operatoren besteht. Helsted definiert:
Hieraus werden Metriken wie z.B. die Zahl der Elementarentscheidungen eines Programmieres abgeleitet. Die Metriken sind allerdings nicht überprüft und deren Aussagekraft ist somit eher fraglich.
COCOMO
Pseudometrik zum Ermitteln der Kosten eines Softwareprojektes nach Boehm. Die Formeln sind aus großen Mengen archivierter Projektdaten abgeleitet und verifiziert. Einflussfaktoren auf die Projektlaufzeit sind:
- DSI (Delivered Source Instructions, entspricht Lines of Code)
- Art des Projektes (Organic: kleine Projekte, in denen keine Entwicklung von nichttrivialen Algorithmen von Nöten ist, Semidetached: mittlere Projekte, wobei das Entwicklerteam aus erfahrenen und unerfahrenen Mitarbeitern besteht, Embedded: Entwicklungsprojekte für neuen Einsatzbereich in einem großen Projektteam)
- Anforderungen an die Verlässlichkeit der Software
- Komplexität des Produktes
- Erfahrung der Entwickler in der Programmiersprache
- Einsatz von Software Tools
...
Je nach Menge der Daten, die zu einem Projekt vorliegen, kann die Schätzung mit unterschiedlichem Detaillierungsgrad erfolgen. Hier wird zwischen den 3 Schätzungsarten Basic,Intermediate und Detailed unterschieden.
Objektorientierte Metriken
Chidamber und Kemerer definierten 1994 verschiedene Metriken für die objektorientierte Programmierung.
Weighted Methods per Class (WMC)
: Komplexität der Methode
: Zahl der Methoden
Depth of Inheritance (DIT)
Tiefe der Klasse im Vererbungsbaum
Number of Children of a class (NOC)
Anzahl der Unterklassen einer Klasse
Coupling between classes
Anzahl der Klassen, die eine Klasse benutzt
Response for a class (ROC)
Anzahl aller möglichen auszuführenden Methoden einer Klasse (d.h. Anzahl der Methoden der Klasse selbst + Anzahl der Methoden, die über Umwege, also z.B. durch Klassen, die die betrachtete Klasse benutzt, erreicht werden können.
Lack of cohesion in methods (LCOM)
Ermittelt den fehlenden Zusammenhalt der Methoden einer Klasse. Die Zahl sollte möglichst gering sein (am besten 0), da man innerhalb einer Klasse eine hohe Methodenkopplung erwartet (siehe Designprinzipien). Berechnungsvorschrift:
wenn , sonst 0 mit
: Anzahl der Methodenpaare mit keinem gemeinsamen Attribut
: Anzahl der Methodenpaare mit einem oder mehr gemeinsamen Attributen
Karteninfo:
Autor: ChristianK
Oberthema: Informatik
Thema: Softwaretechnik
Schule / Uni: RWTH Aachen
Ort: Aachen
Veröffentlicht: 24.04.2010