Softwarequalität - Metriken
-
Upload
gerrit-beine -
Category
Documents
-
view
4.027 -
download
0
description
Transcript of Softwarequalität - Metriken
![Page 1: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/1.jpg)
1
Die Macht der Zahlen
Source Code Metriken
Gerrit Beine, [email protected]
Prof. Dr. Wolfgang [email protected]
![Page 2: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/2.jpg)
2
Einige ausgewählte Metriken
![Page 3: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/3.jpg)
3
McCabes zyklomatische Komplexität
![Page 4: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/4.jpg)
4
McCabes zyklomatische Komplexität
● Literatur: A Complexity Measure; Thomas J. McCabe● IEEE Transactions on Software Engineering, Vol. SE-2, No.4, December 1976
● http://www.literateprogramming.com/mccabe.pdf
● Die zyklomatische Komplexität basiert auf der Graphentheorie● Ursprünglich für FORTRAN erdacht● Auf alle strukturierten und prozeduralen Sprachen anwendbar● Entscheidungen im Programm werden zu Knoten im Graph● Programmlogik wird als Kanten des Graphs interpretiert
● Zyklomatische Komplexität: ● e = edges, Kanten im Graph
● n = nodes, Knoten im Graph
● p = parts, (unabhängige) Teile des Graph
v(G)=e−n+2∗p
![Page 5: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/5.jpg)
5
Algorithmische Ermittlung der zyklomatischen Komplexität
● Theorem: v(G) ist gleich der Anzahl der unabhängigen Zyklen des Graph.
● Ermittlung durch Zweigüberdeckung:● Übertragung des Graphen in einen
Baum
● Jeder Pfad im Graph entspricht einem Pfad im Baum
● Anwendung der Tiefensuche
● Es werden nur Knoten untersucht, die noch nicht besucht wurden
● Wurde ein Knoten besucht, ist ein neuer unabhängiger Kreis entdeckt
● Vorgehen liefert gleichzeitig Testfälle für den Graph
A
B C D
E
FA
B
E
B A F
C D
F C
A
![Page 6: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/6.jpg)
6
Anwendung der zyklomatischen Komplexität auf objektorienten Code
● Methodenbasiert● Es werden die Kontrollstrukturen innerhalb von Methoden untersucht
● Mögliche Ergebnisse:
● v(G) für konkrete Methode, avg v(G) pro Methode / Klasse / Package (sinnfrei)
● Prozessbasiert● Sämtliche für einen Prozess relevanten Methoden werden als unabhängige
Teilgraphen (Components) betrachtet
● e sind die Kanten der Kontrollstrukturgraphen aller Methoden
● n sind die Knoten der Kontrollstrukturgraphen aller Methoden
● p ist die Anzahl der beteiligten Methoden
● Berechnung ist aufwändig (abhängig von Kopplung)
● Algorithmus liefert aber sehr interessante Aussagenu.a. über die Gesamtkomplexität von Prozessen
![Page 7: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/7.jpg)
7
Die Halstead-Metriken
![Page 8: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/8.jpg)
8
Die Halstead-Metriken
● Literatur: Elements of Software Science; Maurice H. Halstead● Elsevier Science Inc., New York, 1977
● Halsteadt definierte eine Reihe von Metriken zur Komplexitäts- und Aufwandsschätzung● Program vocabulary (n)
● Program length (N)
● Calculated program length
● Program volume (V)
● Program difficulty level (D)
● Program level (L)
● Effort to implement (E)
● Time to implement (T)
● Number of delivered bugs (B)
![Page 9: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/9.jpg)
9
Berechnung der Halstead-Metriken
● Unique Operators and Operands: n1, n2● Total amount of Operators and Operands: N1, N2● Program vocabulary:● Program length:● Calculated program length:● Program volume:● Program difficulty level:● Program level:● Effort to implement:● Time to implement:● Number of delivered bugs:
N̂=n1∗log2(n1)+n2∗log2(n2)
N=N1+N2
n=n1+n2
V=N∗log2(n)
D=(N12
)∗(n22
)
L=1D
E=V∗D
T=E18
B=E
23
3000oder neu :B=
V3000
![Page 10: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/10.jpg)
10
Kritik an Halsteadts Metriken
● Definition von Operator und Operand ist nicht festgelegt● Fenton, N., Software Measurement: A Necessary Scientific Basis. In IEEE Transactions on
Software Engineering, 1004, vol. 20(3), pp. 199-206.● Halsteads Metriken liefern keine Aussagen zur Komplexität, werden aber oft dafür
herangezogen
● Al-Qutaish, R.E., and Abran, A., An analysis of the design and definitions of Halstead’s metrics, In 15th Int. Workshop on Software Measurement, 2005, pp. 337-352.
● Die Unklarheit von Halsteads Definitionen führt zu verschiedenen Interpretationen
● Die Anwendbarkeit auf moderne Programmiersprachen ist nicht festgelegt
● Beser, N., Foundations and experiments in software science. In Selected Papers of the 1982 ACM SIGMETRICS Workshop on Software Metrics: Part 2, 1982, pp. 48-72. undDavies, G., and Tan, A., A note on metrics of Pascal programs. In ACM SIGPLAN Notices, 1987, vol. 22(8), pp. 39-44.
● Die Formel für N überschätzt die Länge kleiner Programme und unterschätzt die Länge großer Programme
![Page 11: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/11.jpg)
11
Der Maintainability Index
![Page 12: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/12.jpg)
12
Der Maintainability Index
● Literatur: Oman, P., Hagemeister, J.: Metrics for assessing Software System Maintainability● IEEE Int. Conference on Software Maintenance, 1994, S. 337
● Zusammenhang zwischen Codeeigenschaften und Wartungsaufwand● Basiert auf anderen Metriken
● Aufwand nach Halstead (E)
● Zyklomatische Komplexität nach McCabe (G)
● Modulgröße (LOC)
● In einer Überarbeitung kam noch hinzu● Kommentierungsgrad (CMT) prozentualer Anteil an den LOC
● Halstead-Volumen (V) alternativ zum Aufwand nach Halstead (E)
![Page 13: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/13.jpg)
13
Der Maintainability Index
● 1992: ursprüngliche Formel
● 1994: Berücksichtigung von Kommentaren
● Interpretation
● MI > 85: gute Wartbarkeit
● 65<MI<85: mittlere Wartbarkeit
● MI<65: schlechte Wartbarkeit
● Normalisierter MI von Microsoft
● Interpretation
● 0-9 = Rot
● 10-19 = Gelb
● 20-100 = Grün
MI=171−5,2∗ln (E)−0,23∗ln (G)−16,2∗ln (LOC )
MI=171−5,2∗ln (V )−0,23∗ln (G)−16,2∗ln (LOC )+50∗sin√2,4∗CMT
MI=MAX (0,(171−5,2∗ln (V )−0,23∗ln (G)−16,2∗ln (LOC ))∗100 /171)
![Page 14: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/14.jpg)
14
Kritik am Maintainability Index
● Korrektheit von MI wurde nur über Korrelation mit subjektivem Empfinden von Wartbarkeits-Experten geprüft (0,81-0,93)
● Reduzieren von Software auf einen einzigen Wert ist nur als Trend aussagekräftig● Beschränkung auf spezifische Metriken reduziert die Anwendbarkeit auf moderne
Programmiersprachen● Sneed, H.: “Software muss messbar werden”, Zeitschrift für Information Management, Nr.
4, 1991, S. 39● Nur 40% der Wartungskosten werden von MI tangiert, der Rest teilt sich zwischen
Wartungspersonal und Wartungsumgebung auf
![Page 15: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/15.jpg)
15
Die Robert C. Martin-Metriken
![Page 16: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/16.jpg)
16
Die Robert C. Martin-Metriken
● Literatur: OO Design Quality Metrics; An Analysis of Dependencies; By Robert Martin● http://www.objectmentor.com/resources/articles/oodmetrc.pdf
● Die Martin-Metriken zielen auf folgende Clean Code Prinzipien ab● Single Responsibility Principle (SRP)
● Separation of Concerns (SOC)
● Interface Segregation Principle (ISP)
● Dependecy Inversion Principle (DIP)
● Information Hiding Principle (IHP)
● Open Closed Principle (OCP)
![Page 17: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/17.jpg)
17
Instabilität
● Ca: Afferent Couplings: Anzahl der Klassen außerhalb der Kategorie, die von Klassen innerhalb der Kategorie abhängen – eingehende Abhängigkeiten
● Ce: Efferent Couplings: Anzahl der Klassen außerhalb der Kategorie, von denen Klassen innerhalb der Kategorie abhängen – ausgehende Abhängigkeiten
● Eselsbrücke: Inversion Ca = eingehend, Ce = ausgehend
● Instability:
● Keine ausgehenden Abhängigkeiten:Hohe Stabilität, Tendenz ist I = 0
● Keine eingehenden Abhängigkeiten:Hohe Instabilität, Tendenz ist I = 1
● Grenzwertbetrachtungen:
I=Ce
Ca+Ce, I∈[0,1]; ∑
Kategorien
Ce= ∑Kategorien
Ca
limCe→ 0
CeCa+Ce
=0 limCe→∞
CeCa+Ce
=1 limCa→ 0
CeCa+Ce
=1 limCa→∞
CeCa+Ce
=0
![Page 18: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/18.jpg)
18
Instabilität
● Hohe Stabilität (I nahe 0) ist erforderlich für● System-Kerne
Komponenten, um die eine Software herum gebaut wird.
● Datenmodelle
Ein gutes Beispiel sind EJB3 Entities. Diese sollten von keinen anderen Komponenten einer Software abhängen.
● Hohe Instabilität (I nahe 1) entsteht bei● Implementierung von externen Schnittstellen
Als Beispiel kann die Implementierung eines WebService dienen, der Funktionalität nach außen zur Verfügung stellt.Von solchen Komponenten darf innerhalb des Systems nichts abhängen.
● komplexen User Interfaces
User Interfaces führen oftmals viele Komponenten zusammen.Somit entstehen hohe Werte für ausgehende Abhängigkeiten.
![Page 19: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/19.jpg)
19
Instabilität
● Keine Pakete mit I=0 →● Kein Systemkern
● Zyklische Abhängigkeiten vorhanden
● Viele Pakete mit I=1 →● Hohe Wartungsaufwände bei kleinen
Änderungen
● Prinzip:Je mehr Pakete mit höherer Instabilität, desto größer ist der Domino-Effekt bei Änderungen.
● Ziel:Möglichst viele stabile Pakete.Software neigt leider dazu, sich entgegengesetzt zu entwicklen.
![Page 20: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/20.jpg)
20
Abstraktion
● NoAC: Number of Abstract Classes: Alle abstrakten Klassen eines Paketes● NoCC: Number of Concrete Classes: Alle nicht abstrakten Klassen eines Paketes● NoI: Number of Interfaces: Alle Schnittstellen eines Paketes● NoC: Number of Classes = NoAC+NoCC: Alle Klassen eines Paketes
● Abstractness
● Keine abstrakten Klassen und Schnittstellen:Niedrige Abstraktion, Tendenz ist A = 0
● Ausschließlich abstrakte Klassen und Schnittstellen:Hohe Abstraktion, Tendenz ist A = 1
● Grenzwertbetrachtungen:
A=NoAC+NoI
NoCC+NoAC+NoI=NoACINoCI
=, A∈[0,1]
limNoAC+NoI→ 0
NoAC+NoINoCC+NoAC+NoI
=0
limNoCC→∞
NoAC+NoINoCC+NoAC+NoI
=0
limNoAC+NoI→∞
NoAC+NoINoCC+NoAC+NoI
=1
limNoCC→0
NoAC+NoINoCC+NoAC+NoI
=1
![Page 21: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/21.jpg)
21
Abstraktion
● Keine Pakete mit A=1 →● Schnittstellen nicht einzeln
distributierbar
● Viele Pakete mit A=0 →● Erweiterungen (OCP) nicht möglich
● Prinzip:Abstrakte Pakete sind entsprechend des OCP leichter zu erweitern als nicht abstrakte Pakete.
● Ziel:Definierte abstrakte Pakete, um Schnittstellen zu separieren. Gute Abstraktion benötigt viel Zeit.
![Page 22: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/22.jpg)
22
Distanz
● Pakete sollten ausschließlich von stabileren Paketen (idealerweise auch abstrakteren Paketen) abhängen. (ISP)
● Das ist die Grundlage für Inversion of Control bzw. Dependency Injection
● Zusammenhänge zwischen Abstraktion und Instabilität● Abstrakte Pakete (A=1) sollten stabil sein (I=0), d.h. keine ausgehenden
Abhängigkeiten besitzen. Damit sind sie offen für Erweiterungen und geschlossen gegenüber Modifikationen. (OCP)
● Instabile Pakete (I=1) sollten nicht abstrakt (A=0) sein. Sie sind nicht mehr erweiterbar, unterliegen aber eine hohe Änderungswahrscheinlichkeit.
● Pakete mit balancierter Abstraktion (A=0,5) und Instabilität (I=0,5) sind noch teilweise erweiterbar, unterliegen allerdings schon einer gewissen Änderungswahrscheinlichkeit.
● Abstraktion und Instabilität sollten ausbalanciert sein.
![Page 23: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/23.jpg)
23
Distanz
● Balance zwischen A und I ergibt einen Graphen, der folgender Formel genügt:
● Distance: ● Pakete, die sich nahe der Main Sequence
befinden, sind ausbalanciert.● Je weiter ein Paket von der Main
Sequence entfernt ist, desto schwieriger wird seine Verwendung (Area of Uselessness bei A=1 und I=1) oder seine Wartung (Area of Pain bei A=0 und I=0)
● Ziel:Optimale Pakete befinden sich an einem der Endpunkte der Main Sequence, die Entfernung zur Main Sequence (=Distanz) sollte minimal sein.
Dn=∣A+I−1∣, Dn∈[0,1]
Quelle: http://www.objectmentor.com/resources/articles/oodmetrc.pdf
![Page 24: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/24.jpg)
24
Einige ausgewählte Metriken
Chidamber & Kemerers OO-Metriken
![Page 25: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/25.jpg)
25
Chidamber & Kemerers OO-Metriken
● Literatur: S. R. Chidamber, C.F. Kemerer, A Metrics Suite for Object Oriented Design● IEEE Transactions on Software Engineering, 20(6), 1994, S. 476-493
● Sammlung von Metriken zur Bewertung objektorientierter Systeme● Weighted Method Count (WMC)
● Coupling Between Object Classes (CBO)
● Depth of Inheritance Tree (DIT)
● Number of Children (NOC)
● Response For a Class (RFC)
● Lack of Cohesion in Methods (LCOM)
![Page 26: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/26.jpg)
26
Weighted Method Count (WMC) / Coupling Between Object Classes (CBO)
WMC
● Formel:● Als Komplexitätsfunktion kann z.B. die
zyklomatische Komplexität dienen● Kann als Wartungsmaß dienen, da eine
größere Anzahl komplexer Methoden höhere Wartungsaufwände verursachen kann
● Bei Vererbung führen hohe Werte von WMC zu engen Kopplungen
● Kritik: Attribute von Klassen werden nicht berücksichtigt
● Clean-Code-Prinzip: SRPSingle Responsibility Principle
CBO
● Anzahl der Klassen, die von einer Klasse benutzt werden
● Ein hoher Wert für CBO deutet auf Änderungsaufwände hin
● Entspricht dem Ce der Martin-Metrik auf Klassenebene
● Je höher der Wert von CBO, desto höher der Wert der Instability
● Fokus auf Struktur
WMC=∑i=1
n
c i
![Page 27: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/27.jpg)
27
Number of Children (NOC) / Depth of Inheritance Tree (DIT)
NOC
● Maß für die Anzahl unmittelbar abgeleiteter Klassen
● Ein hoher Wert für NOC ist ein Indiz für häufige Wiederverwendung
● Änderungsaufwand für Klassen mit hohem Wert für NOC ist hoch
● Testaufwand für Klassen mit hohem NOC ist sehr hoch
● Clean-Code-Prinzip: FCoIFavour Composition over Inheritance
● Clean-Code-Prinzip: OCPOpen Closed Principle
DIT
● Tiefe der Verbungshierarchie einer Klasse● Anzahl geerbter Eigenschaften steigt mit
höherer DIT● Klassen mit hoher DIT können nicht
isoliert betrachtet werden● Als Maximalwert für den DIT wird im
Allgemeinen 7 angesehen● Clean-Code-Prinzip: FCoI
Favour Composition over Inheritance● Clean-Code-Prinzip: IHP
Information Hiding Principle● Clean-Code-Prinzip: OCP
Open Closed Principle
![Page 28: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/28.jpg)
28
Response For a Class (RFC) / Lack of Cohesion in Methods (LCOM)
RFC
● Response Set: Alle Methoden einer Klasse und die von den Methoden benutzten Methoden anderer Klassen
● Hoher Wert für RFC deutet auf schlechtes Design hinsichtlich der Separation of Concerns hin
● RFC und CBO korrellieren im Allgemeinen● Fokus auf Interaktion● Clean-Code-Prinzip: SRP
Single Responsibility Principle● Clean-Code-Prinzip:
Tell, don't ask
LCOM
● Maß für die gemeinsame Nutzung von Attributen einer Klasse durch ihre Methoden
● Ein hoher Wert von LCOM weist auf schlechtes Design im Sinne der Separation of Concerns hin
● Klassen mit hohem LCOM sollten geteilt werden
● Clean-Code-Prinzip: SRPSingle Responsibility Principle
![Page 29: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/29.jpg)
29
Fragen und Antworten
![Page 30: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/30.jpg)
30
Das Problem mit der Kopplung
![Page 31: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/31.jpg)
31
Das Problem mit der Kopplung
● Reale Anwendung● Anwendung enthält rund 35 Entitäten● Durchschnittliche Kopplung liegt bei
mehr als 30!
● Wartung nahezu unmöglich
● Unglücklicherweise sagt der Maintainability Index: 165
![Page 32: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/32.jpg)
32
Welche Metriken sind wichtig und weit verbreitet?
![Page 33: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/33.jpg)
33
Welche Metriken sind wichtig und weit verbreitet?
● Am weitesten verbreitet sind mit Sicherheit die Metrik der Lines of Code, die zyklomatische Komplexität und der Maintainability Index
● Die Verbreitung sagt aber nichts über den Nutzen einer Metrik in einem konkreten Projekt aus
● Oft werden weit verbreitete Metriken völlig falsch angewendet und damit mehr Schaden produziert, als Nutzen geschaffen
● Wichtig sind immer genau die Metriken, die die Antworten auf die Fragen liefern, die sich aus dem Ziel eines Projektes ergeben
● Es sollte nie nur eine Metrik herangezogen werden, sondern idealerweise Metriken, die orthogonal zueinander messen
● Gut ist auch der Ansatz, immer zwei Metriken zu nutzen, die die gleiche Frage beantworten: Ist die Antwort identisch, ist sie mit höherer Wahrscheinlichkeit richtig
![Page 34: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/34.jpg)
34
Welche Tools können verwendet werden?
![Page 35: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/35.jpg)
35
Welche Tools können verwendet werden?
● Unter Java● JDepend: Martin
● DependencyFinder & OOMetrics: Martin, Chidamber & Kemerer
● PMD: Zyklomatische Komplexität, NPath
● CheckStyle: Zyklomatische Komplexität, NPath
● Unter PHP● PHP Mess Detector: Zyklomatische Komplexität, NPath
● PhpDepend: Martin
● Unter .NET● Dependometer: Chidamber & Kemerer
![Page 36: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/36.jpg)
36
Wie würde ein ausbalanciertes Klassendesign aussehen (z.B. I = 0.5 und A=0.5)?
![Page 37: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/37.jpg)
37
Wie würde ein ausbalanciertes Klassendesign aussehen?
● Balanciert ist das Design nicht nur bei I=0,5 und A=0,5, sondern entlang der gesamten Main Sequence
● Der Idealzustand ist, dass jedes Paket entweder bei I=1 und A=0 oder I=0 und A=1 anzusiedeln ist.
● Praktisch ist das nicht zu realisieren (im Sinne einer wirtschaftlichen Entwicklung), allerdings ist es nicht das Ziel, I=0,5 und A=0,5 zu erreichen.
● Das Abstract-Stable-Principle besagt, dass ein Paket so stabil wie abstrakt sein soll:
A≃1−I
![Page 38: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/38.jpg)
38
Wie würde ein ausbalanciertes Klassendesign aussehen?
Ca Ce I A
Bild 1
Model 2 0 0 0
Interfaces 1 1 0,5 1
Implementierung 0 3 1 0
Exceptions 1 0 0 0
Bild 2
Model 2 0 0 0
Interfaces 1 2 0,66 1
Implementierung 0 3 1 0
Exceptions 2 0 0 0
IF
IM
M E
IF
IM
M E
![Page 39: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/39.jpg)
39
Wie würde ein ausbalanciertes Klassendesign aussehen?
Ca Ce I A
Bild 3
Model 3 0 0 0
Interfaces 2 1 0,33 1
Implementierung 0 3 1 0
Exceptions 2 0 0 0
Model 2 1 0,33 0
Interfaces 1 1 0,5 1
Implementierung 0 5 1 0
Exceptions 1 0 0 0
IF
IM
M E
IF
IM
M E
![Page 40: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/40.jpg)
40
Wann ist es sinnvoll die Komplexität zu verteilen, bereits während der Programmierung oder erst beim
Refactoring?
![Page 41: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/41.jpg)
41
Wann ist es sinnvoll die Komplexität zu verteilen,bereits während der Programmierung oder erst beim Refactoring?
● Refactoring ist Programmierung● Im Sinne des Test Driven Development
● Zunächst Funktionalität realisieren
● Danach Komplexität reduzieren
![Page 42: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/42.jpg)
42
Stellt die "Auslagerung" der Komplexität (z.B. einer Methode) nicht einen Widerspruch hinsichtlich der
Wartbarkeit dar?
![Page 43: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/43.jpg)
43
Stellt die "Auslagerung" der Komplexität (z.B. einer Methode)nicht einen Widerspruch hinsichtlich der Wartbarkeit dar?
● Frage wurde bezüglich der zyklomatischen Komplexität gestellt● Widersprucht besteht nicht im Sinne der Separation of Concerns
● Inhaltlich verschiedenes voneinander Trennen schafft Übersichtlichkeit
● In objektorientierten Sprachen Polymorphismus als Ersatz für Kontrollstrukturen verwenden führt zum Verschwinden von Knoten aus dem Graph
● Polymorphe Methoden bearbeiten jeweils nur einen konkreten Typ:Daraus resultierende Vereinfachung leuchtet ein :-)
![Page 44: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/44.jpg)
44
Wie wirkt sich die Verteilung der Komplexität auf das Laufzeitverhalten (und den Speicherverbrauch)
von Programmen aus?
![Page 45: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/45.jpg)
45
Wie wirkt sich die Verteilung der Komplexität auf das Laufzeitverhalten(und den Speicherverbrauch) von Programmen aus?
● Im besten Falle positiv, manchmal gar nicht und hin und wieder negativ.● Sichtweise 1: Dynamisches Laden von Programmteilen
● Es werden nur die Klassen überhaupt geladen, die auszuführenden Code beinhalten(z.B. Perl, PHP, teilweise auch Java)
● Sichtweise 2: Wie wirken Kontrollstrukturen im Vergleich zu Methodenrufen?● Auf der niedrigsten Ebene (Prozessor) wirken Kontrollstrukturen ebenso wie
Methodenaufrufe wie ein GOTO: Die Ausführung des Programms wird an einer anderen Adresse fortgesetzt.
● Einziger Unterschied: Beim Methodenaufruf wird die Rücksprungadresse auf dem Stack gesichert
● Der Zugriff auf Daten benötigt einen Schritt mehr, nämlich das Auslesen der Parameter von Stack
● Auswirkungen zeigen hier vor allem komplexe Datenstrukturen, die Call-by-Value übergeben werden
![Page 46: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/46.jpg)
46
Ist die zyklomatische Komplexität auch in funktionalen Programmiersprachen einsetzbar?
![Page 47: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/47.jpg)
47
Ist die zyklomatische Komplexität auch infunktionalen Programmiersprachen einsetzbar?
● Prinzipiell: Ja, denn der Kontrollfluss existiert auch in funktionalen Sprachen● Schwierig ist die Definition der Kontrollstrukturen
● If, Else etc. sind klar
● Stellen Listenoperationen Kontrollstrukturen dar?
● Die zyklomatische Komplexität berücksichtigt Rekursion nicht – ein Methodenaufruf ist keine Kontrollstruktur
1 val twoThree = List(2, 3) 2 val oneTwoThree = 1 :: twoThree 3 4 myList.count(s => s.length == 4) 5 myList.sort((s, t) => s.charAt(0).toLowerCase < t.charAt(0).toLowerCase)
![Page 48: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/48.jpg)
48
Was ist unter "Nichtäquivalenz der Interaktion" zu verstehen?
![Page 49: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/49.jpg)
49
Was ist unter "Nichtäquivalenz der Interaktion" zu verstehen?
● Gegeben sind drei Klassen: P, Q und R● Metriken liefern für P und Q die gleichen Werte: ● Sowohl P als auch Q interagieren mit R● Metriken für P+R und Q+R muss nicht gleich sein
μ(Q)=μ(P)
![Page 50: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/50.jpg)
50
Sollte man die Metrikwerte für jedes Projekt spezifisch normieren?
![Page 51: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/51.jpg)
51
Sollte man die Metrikwerte für jedes Projekt spezifisch normieren?
● Nein!
● Nicht für jedes Projekt, damit wäre kein Vergleich möglich● Metriken gewinnen an Wert durch Verwendung in verschiedenen Projekten
● Erfahrungspotential der Entwickler ginge verloren
● Aber: Technologische Einflüsse auf Metriken müssen berücksichtigt werden● Programmiersprachen
● Konzepte (z.B. Aspektorientierte Programmierung, Lombok)
● Wichtig ist, den Berechnungsweg der Metriken transparent zu machen
![Page 52: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/52.jpg)
52
Wie viel Metriken sollte man in einem Projekt auf einmal betrachtet?
![Page 53: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/53.jpg)
53
Wie viel Metriken sollte man in einem Projekt auf einmal betrachtet?
● 42
● So wenig wie möglich, so viele wie nötig● Zu viele Metriken verwirren Entwickler und stören sich u. Ust. Gegenseitig● Aber: verschiedene Metriken beleuchten unterschiedliche Aspekte● Empfehlung für Objektorientierte Softwareentwicklung
● Martin Metriken liefern Überblick
● Chidamber & Kemerer liefern Detailsicht
● Zyklomatische Komplexität für Methoden
![Page 54: Softwarequalität - Metriken](https://reader033.fdocument.pub/reader033/viewer/2022052323/558c187bd8b42ad8718b466d/html5/thumbnails/54.jpg)
54
Verwendung dieser Unterlagen
● Wir stellen diese Unterlagen unter der Creative Commons Lizenz CC-BY-NC-SA zur allen am Thema Interessierten Verfügung.
● Es ist erlaubt, die Unterlagen unter gleichen Bedingungen zu● kopieren
● verteilen
● übertragen und
● adaptieren, wenn
● die ursprünglichen Autoren genannt werden und● die Verwendung nicht zu kommerziellen Zwecken stattfindet.
● Details zur Lizenz sind hier zu finden:http://creativecommons.org/licenses/by-nc-sa/3.0/