54
1 Die Macht der Zahlen Source Code Metriken Gerrit Beine, M.Sc. [email protected] Prof. Dr. Wolfgang Golubski [email protected]

Softwarequalität - Metriken

Embed Size (px)

DESCRIPTION

Vorlesung Softwarequalität:Die Folien zum Thema Source-Code-Metriken.Inkl. McCabes zyklomatischer Komplexität, Halsteads Komplexitätsmetriken, Uncle Bob's Distance und den C&K OOD Metriken.Die Fragen im zweiten Teil stammen von den Studenten des Master-Studienganges 2012 der Westsächsichen Hochschule Zwickau.

Citation preview

Page 1: Softwarequalität - Metriken

1

Die Macht der Zahlen

Source Code Metriken

Gerrit Beine, [email protected]

Prof. Dr. Wolfgang [email protected]

Page 2: Softwarequalität - Metriken

2

Einige ausgewählte Metriken

Page 3: Softwarequalität - Metriken

3

McCabes zyklomatische Komplexität

Page 4: Softwarequalität - Metriken

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

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

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

7

Die Halstead-Metriken

Page 8: Softwarequalität - Metriken

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

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

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

11

Der Maintainability Index

Page 12: Softwarequalität - Metriken

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

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

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

15

Die Robert C. Martin-Metriken

Page 16: Softwarequalität - Metriken

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

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

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

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

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

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

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

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

24

Einige ausgewählte Metriken

Chidamber & Kemerers OO-Metriken

Page 25: Softwarequalität - Metriken

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

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

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

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

29

Fragen und Antworten

Page 30: Softwarequalität - Metriken

30

Das Problem mit der Kopplung

Page 31: Softwarequalität - Metriken

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

32

Welche Metriken sind wichtig und weit verbreitet?

Page 33: Softwarequalität - Metriken

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

34

Welche Tools können verwendet werden?

Page 35: Softwarequalität - Metriken

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

36

Wie würde ein ausbalanciertes Klassendesign aussehen (z.B. I = 0.5 und A=0.5)?

Page 37: Softwarequalität - Metriken

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

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

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

40

Wann ist es sinnvoll die Komplexität zu verteilen, bereits während der Programmierung oder erst beim

Refactoring?

Page 41: Softwarequalität - Metriken

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

42

Stellt die "Auslagerung" der Komplexität (z.B. einer Methode) nicht einen Widerspruch hinsichtlich der

Wartbarkeit dar?

Page 43: Softwarequalität - Metriken

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

44

Wie wirkt sich die Verteilung der Komplexität auf das Laufzeitverhalten (und den Speicherverbrauch)

von Programmen aus?

Page 45: Softwarequalität - Metriken

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

46

Ist die zyklomatische Komplexität auch in funktionalen Programmiersprachen einsetzbar?

Page 47: Softwarequalität - Metriken

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

48

Was ist unter "Nichtäquivalenz der Interaktion" zu verstehen?

Page 49: Softwarequalität - Metriken

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

50

Sollte man die Metrikwerte für jedes Projekt spezifisch normieren?

Page 51: Softwarequalität - Metriken

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

52

Wie viel Metriken sollte man in einem Projekt auf einmal betrachtet?

Page 53: Softwarequalität - Metriken

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

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/