SWC Zwei
Cool
Cool
Was sind EclEmma Features?
1) Instrumentation:
- > Byte Code einbauen
-> Offline und on-the-fly
2) Coverage-Types (Verschiedene Typen können gemessen werden)m -> Classes, Methods, Lines, Basic Blocks
3) Report Types (Verschiedener Output wird generiert) -> txt, html, xml
4) Statistics -> Method, class, package, "all classes"
5) Execution -> ant, cmd, eclipse plugin
Was ist Refractoring?
Refractoring bedeutet:
- bestehenden Code intern verbessern, ohne das äussere Verhalten der Software zu verändern
Also:
- Code wird sauberer
- verständlicher
- wartbarer
- sicherer
Aber für den Benutzer soll die Software gleich funktionieren
Mach ein Beispiel von Refractoring:
Vorher:
if (s.equals("Hallo"))
Problem wenn s == null; -> NullPointrException
Nachher:
if ("Hallo".equals(s)) -> Prüft, ob s = "Hallo"
Was ist das Ziel von Refractoring?
Refractoring verbessert:
- Lesbarkeit
- Struktur
- Wartbarkeit
- Testbarkeit
- Performance (manchmal)
- SIcherheit gegen Fehler
Was versteht man unter Code Smell?
- Ein Hinweis darauf, dass es möglicherweise Probleme im Aufbau oder Design des Codes gibt
Code, der "komisch riecht" und auf schlechte Struktur hindeutet
Wichtig:
- Code Smell ist nicht unbedingt ein Bug -> Code kann funktionieren, aber er ist:
- Schwer wartbar
- Schlecht lesbar
- Fehleranfällig
- unnötig kompliziert
Was sind Beispiele für Code Smells:
- Zu lange Methoden
- Duplicate Code
- Large Class
- Zu viele Parameter
- Deep Nesting / Zu viele verschachtelte Ifs
- God Object -> Eine Klasse kontrolleirt alles
Welche Smell Levels gibt es? Also auf welchen Ebenen treten Code Smells auf?
- Code Level -> Probleme in einzelnen Methoden oder Codezeilen
- Class Design Level -> Probleme im Aufbau einer Klasse
- Architectural Design Level -> Probleme in der gesamten Systemarchitektur (Zyklische Abhängikeiten, stark gekoppelte Module etc).
Wie kann man Code Smells auffinden?
- Sniff out the bad smells in Code
- Code analysieren:
-> Manuell, in dem man den Code durchliest
-> Automatisiert, in dem man Software benutzt -> Checkstyle for Java, Spotbugs for Java, PMD for Java
Was sind die typischen Code Smells?
Warum braucht es Refractoring?
1) Kontext: Man muss existierenden Code anpassen -> extend/adapt/correct
2) (Bad Solutions) -> Just add new Features
3) Konsequenzen -> Design decays /Qualität nimmt ab, Duplizierter Code, Lange Methoden/grosse Klassen
Gute Lösung:
-> Als erstes Code simpler machen, Code auf Komplexität vorbereiten -> Refractor
-> Neue Features hinzufügen
Konsequenz:
-> Code bleibt Simple
-> Codequalität bleibt hoch
Welche Voraussetzungen für Refractoring gibt es?
Automated Measures:
- Version Control System (VCS) (Man kann zurück gehen, falls Bugs entstehen)
- Continous Integration (CI) (Man möchte nach dem Refractoring das ganze System testen)
- Tests (Man will schauen, ob man etwas kaputt gemacht hat oder nicht)
- Coding Standards
Social Measures (Absteigender Reihenfolge):
- Collective Ownership (Jeder kann Code ändern)
- Rules of Simplicity
- Sustainable Pace /Nachhaltige Geschwindigkeit
- Pair programming (Driver -> Programmiert tatsächlich, Reviewer: schaut dden Code des Drivers an)
Was versteht man unter dem Two Hats-Ansatz?
- Wenn man systematisch Code entwickelt, trägt man zwei verschiedene Hüte:
1) Function Hat
2) Refractoring Hat
- Man sollte nicht versuchen den Code aufzuräumen, wenn man den "Function Hat" trägt
- Man sollte keine Features hinzufügen, wenn man den "Refractoring Hat" trägt
Was ist der Refractoring Workflow?
Siehe Bild
Wann macht man Refractoring?
- Bevor oder nachdem man Funktionalität hinzugefügt hat
- Wenn man etwas über den Code gelernt hat
- Als Konsequenz von einem Bug-Fix
- Als Konsequenz von Code Review
Wann macht man kein Refractoring?
- Wenn die Tests nicht vollstädnig durchlaufen (Pass)
- Wenn man den Code re-implementen muss
Was sollte man beim Refractoring beachten?
- Wenn man zu weit geht, Refractoring kann zu unaufhörbarem herumbasteln von Code führen
- Datenbanken können schwierig sein zu refractoren -> Code is easy to change, databases are not
- Refractoring published interfaces können zu Problemen führen für den Code, der das Interface benutzt -> API's sollen nie angepasst werden
Was sind die Vorteile von Refractoring?
- Refractoring verbessert das Design vom System
- Refractoring macht die Software einfacher zu verstehen -> Weil ihre Struktur verbessert wird, weil duplizierter Code entfernt wird
- Refractoring hilft dabei Bugs zu finden -> Weil es ein tiefes Verständnis über den Code fördert
- Refractoring spart Entwicklunsgzeit -> Weil guter Code einfach zu entwickeln ist -> Weil der Code/Das Design robuster ist
Zusätzliche Refractoring Infos:
Siehe Bild
Wozu dient die Verify Methode im Zusammenhang mit Mock Tests?
Verify überprüft ob, wie und welche Methoden eines Mock-Objektes aufgerufen wurden.
Code Smell
Wo?
Unit-Test sollten:
- immer isoliert durchgeführt werden
- die zu testende Klasse (CUT) sollte immer von ihrer Umgebung isoliert sein, dafür macht man mocking tests
Unit-Testing is done:
- auf jedem Modul
- isoliert
- um das Verhalten einer Einheit zu testen
Unit-Tests werden:
- In einer künstlichen Umgebung laufengelassen
- Ergebnisse werden mit Erwartungswerten (Metriken) verglichen
Welcher Code ist schwer zu testen?
- Code mit viel Abhängigkeiten
- Code mit komplexer Abhängigkeiten auf andere Infrastrukturen -> Datenbanken, Netzwerke etc
Wie kann man eine Klasse testen, welche abhängig von anderen Komponenten ist?
Man Muss die unmitelbare Abhängigkeit loswerden und ersetzen durch Objekte, die man genau kontrollieren kann (Mock)
Was ist Test Double
- Ein Double von Klassen, welche eine bereits vorhandene Klasse ersetzt und sie simuliert
Was versteht man unter Test Double?
- Ein Objekt oder Komponent, dass nur während des Tests existiert und nur die dasein berechtigung daraus zieht so zu tun, als ob es das echte Objekt wäre, während eines Tests
Welche Stufen von Test Doubles gibt es?
- Dummy - passed around but never actually used. Usually they just used to fill parameter lists
- Stubs - are minimal implementations of interfaces or base classes. Methods runnning void will typically contain no implementation at all, while methods returning values will typically retun hard-coded values.
- Fates - contains more complex implementations, typically handling interactions between different members of the type it's inheriting
- Mocks - objects pre-programmed with expectations about the methods that will be invoked (aufgerufen)+. The expected arguments for a call and the resulting return valoues or exception.
- Spies - similiar to a mock, but a spy will also record which members were invoked (aufgerufen) so that unit tests can verify that members were invoked as expected (z.B. in welcher Reihenfolge bestimmte Objekte aufgerufen wurden)
Was sind Stubs:
- Stub ist ein dummes Objekt
- Ein Objekt, das immer und immer wieder den gleichen Wert zurückgibt
- Erlaubt implementation von Tests ohne production Code
---
class EmailStub implements EmailService{
void sendMail(String addr, String text){ ...}
Es ist völlig egal, ob die Mail ankommt
Wie können wir etwas isolieren?
Wir wollen nur JukeBox testen:
Wir müssen die echten Song-Objekte durch Stub/Mock ersetzen
Wo kommt SongStub hin (Verzeichnis)?
- In src/test/java
Was ist Mockito?
- Mock Objekte simulieren Teile des Verhaltens des echten Objekts (Gibt nicht einfach immer nur den gleichen Rückgabe wert und macht nix
- Klassen können isoliert getestet werden, in dem alle Abhängigkeiten damit kontrolliert werden -> Dabei helfen Mock-Objekte
- Nimmt Klassesn aus der produktiven Umgebung hinaus und bettet sie in eine wohldefinierte Testumgebung -> Nur noch Mock-Objekte sind um das zu testende Objekt, keine echten mehr
Wann sollte man Mock-Objekte einsetzen? //Intelligente Stub-Objekte generierung
- Wenn das echte Objekt nicht determinantisches Verhalten hat (Also ein zufälliges Verhalten)
- Wenn das echte Objekt schwer aufzusetzen/setup ist (z.B. Datenbank mit Setup)
- Wenn das echte Objekt langsam ist (z.B. durch umfangreiche Berechnungen)
- Wenn das echte Objekt ein user-interface hat (Man möchte nur die Logik anschauen)
- Wenn die Tests das echte Objekt fragen müssen, wie es benutzt wurde (if callback function was called) //Wie häufig in welcher Reihenfolge
- Wenn das echte Objekt noch nicht existiert
Was ist das Mock-Framework-Mockito?
- Mock Objekte zu schreiben und zu warten ist oftmals aufwändig und ist Fehleranfällig
- Mockito ist eine Bibliothek, welche einen einfachen Weg bietet Mock-Objekte zu erstellen und zu benutzen
- Mockito generiert Mock-Objekte dynamisch während der Laufzeit, es muss also kein Code geschrieben werden und es braucht auch keinen generierten Code
Benutzung von Mockito im Beispiel mit getCurrenSoing()-Methode:
Siehe Bild
Wie benutzt man Mockito (Implementierung):
Siehe Bild
Welche Usage Pattern gibt es beim Mock-Testing?
1) Create -> Erstellt ein Mock-Objekt für ein Interface oder Klasse, welche wir gerne simulieren möchten
2) Specify -> Spezifiziert das erwartete Verhalten von einem Mock-Objekt
3) Use -> Benutzt das Mock-Objekt im normalen/standard unit-testing, als ob es ein normales Objekt wäre
4) Verify -> Überprüft, ob das Mock-Objekt wie erwartet verwendet wurde
Was ist Create Mock:
- Methode mock(<Class or Interface>) benutzen
- Das Mock-Objekt kann jetzt benutzt werden
---
import static org.mockito.Mockito.*;
/*
* Create a Mock-Object
*/
Beispiel:
Song mockSong = mock(Song.class);
Specify Methode - Verhalten:
- Mock-Objekt lernt, wie es es bei spezifischem Input reagieren soll
/*
* Rückgabewerte werden definiert, indem ein Methodenaufruf mit when() umuschlossen wird.
* Mit thenReturn() wird festgelegt, welcher Wert zurückgeben werden soll.
*/
Beispiel:
when(mockSong.getTitle()).thenReturn("MySongTitle");
Use Mock-Object:
- Mock-Objekt kann ganz normal benutzt werden
- Methoden "Behaviour Specification" und "use" können in irgendeiner Reihenfolge sein (no need specify everything before first use)
/*
* Execute Tests
*/
box.addSong(MockSong);
box.playSong("Frozen");
asserEquals("Frozen", box.getCurrenSong().getTitle();
-
- 1 / 79
-
Flashcards
Unit-Test sollten:
- immer isoliert durchgeführt werden
- die zu testende Klasse (CUT) sollte immer von ihrer Umgebung isoliert sein, dafür macht man mocking tests
Unit-Testing is done:
- auf jedem Modul
- isoliert
- um das Verhalten einer Einheit zu testen
Unit-Tests werden:
- In einer künstlichen Umgebung laufengelassen
- Ergebnisse werden mit Erwartungswerten (Metriken) verglichen
Welcher Code ist schwer zu testen?
- Code mit viel Abhängigkeiten
- Code mit komplexer Abhängigkeiten auf andere Infrastrukturen -> Datenbanken, Netzwerke etc
Wie kann man eine Klasse testen, welche abhängig von anderen Komponenten ist?
Man Muss die unmitelbare Abhängigkeit loswerden und ersetzen durch Objekte, die man genau kontrollieren kann (Mock)
Was ist Test Double
- Ein Double von Klassen, welche eine bereits vorhandene Klasse ersetzt und sie simuliert
Was versteht man unter Test Double?
- Ein Objekt oder Komponent, dass nur während des Tests existiert und nur die dasein berechtigung daraus zieht so zu tun, als ob es das echte Objekt wäre, während eines Tests
Welche Stufen von Test Doubles gibt es?
- Dummy - passed around but never actually used. Usually they just used to fill parameter lists
- Stubs - are minimal implementations of interfaces or base classes. Methods runnning void will typically contain no implementation at all, while methods returning values will typically retun hard-coded values.
- Fates - contains more complex implementations, typically handling interactions between different members of the type it's inheriting
- Mocks - objects pre-programmed with expectations about the methods that will be invoked (aufgerufen)+. The expected arguments for a call and the resulting return valoues or exception.
- Spies - similiar to a mock, but a spy will also record which members were invoked (aufgerufen) so that unit tests can verify that members were invoked as expected (z.B. in welcher Reihenfolge bestimmte Objekte aufgerufen wurden)
Was sind Stubs:
- Stub ist ein dummes Objekt
- Ein Objekt, das immer und immer wieder den gleichen Wert zurückgibt
- Erlaubt implementation von Tests ohne production Code
---
class EmailStub implements EmailService{
void sendMail(String addr, String text){ ...}
Es ist völlig egal, ob die Mail ankommt
Wie können wir etwas isolieren?
Wir wollen nur JukeBox testen:
Wir müssen die echten Song-Objekte durch Stub/Mock ersetzen
Wo kommt SongStub hin (Verzeichnis)?
- In src/test/java
Was ist Mockito?
- Mock Objekte simulieren Teile des Verhaltens des echten Objekts (Gibt nicht einfach immer nur den gleichen Rückgabe wert und macht nix
- Klassen können isoliert getestet werden, in dem alle Abhängigkeiten damit kontrolliert werden -> Dabei helfen Mock-Objekte
- Nimmt Klassesn aus der produktiven Umgebung hinaus und bettet sie in eine wohldefinierte Testumgebung -> Nur noch Mock-Objekte sind um das zu testende Objekt, keine echten mehr
Wann sollte man Mock-Objekte einsetzen? //Intelligente Stub-Objekte generierung
- Wenn das echte Objekt nicht determinantisches Verhalten hat (Also ein zufälliges Verhalten)
- Wenn das echte Objekt schwer aufzusetzen/setup ist (z.B. Datenbank mit Setup)
- Wenn das echte Objekt langsam ist (z.B. durch umfangreiche Berechnungen)
- Wenn das echte Objekt ein user-interface hat (Man möchte nur die Logik anschauen)
- Wenn die Tests das echte Objekt fragen müssen, wie es benutzt wurde (if callback function was called) //Wie häufig in welcher Reihenfolge
- Wenn das echte Objekt noch nicht existiert
Was ist das Mock-Framework-Mockito?
- Mock Objekte zu schreiben und zu warten ist oftmals aufwändig und ist Fehleranfällig
- Mockito ist eine Bibliothek, welche einen einfachen Weg bietet Mock-Objekte zu erstellen und zu benutzen
- Mockito generiert Mock-Objekte dynamisch während der Laufzeit, es muss also kein Code geschrieben werden und es braucht auch keinen generierten Code
Benutzung von Mockito im Beispiel mit getCurrenSoing()-Methode:
Siehe Bild
Wie benutzt man Mockito (Implementierung):
Siehe Bild
Welche Usage Pattern gibt es beim Mock-Testing?
1) Create -> Erstellt ein Mock-Objekt für ein Interface oder Klasse, welche wir gerne simulieren möchten
2) Specify -> Spezifiziert das erwartete Verhalten von einem Mock-Objekt
3) Use -> Benutzt das Mock-Objekt im normalen/standard unit-testing, als ob es ein normales Objekt wäre
4) Verify -> Überprüft, ob das Mock-Objekt wie erwartet verwendet wurde
Was ist Create Mock:
- Methode mock(<Class or Interface>) benutzen
- Das Mock-Objekt kann jetzt benutzt werden
---
import static org.mockito.Mockito.*;
/*
* Create a Mock-Object
*/
Beispiel:
Song mockSong = mock(Song.class);
Specify Methode - Verhalten:
- Mock-Objekt lernt, wie es es bei spezifischem Input reagieren soll
/*
* Rückgabewerte werden definiert, indem ein Methodenaufruf mit when() umuschlossen wird.
* Mit thenReturn() wird festgelegt, welcher Wert zurückgeben werden soll.
*/
Beispiel:
when(mockSong.getTitle()).thenReturn("MySongTitle");
Use Mock-Object:
- Mock-Objekt kann ganz normal benutzt werden
- Methoden "Behaviour Specification" und "use" können in irgendeiner Reihenfolge sein (no need specify everything before first use)
/*
* Execute Tests
*/
box.addSong(MockSong);
box.playSong("Frozen");
asserEquals("Frozen", box.getCurrenSong().getTitle();
Verify Behaviour:
- Wenn wir das Verhalten spezifizieren, wollen wir auch sicherstellen, dass das Verhalten auch eingetreten/used wurde
- Wurde eine Methode aufgerufen?, Wie oft? Mit welchen Parametern?
- Um sicherzustellen, dass spezifische Verhalten eingetreten sind, muss verify verwendet werden
/*
* verify internal behavior
*/
verify(mockSong).start(); //Überprüft, ob start() aufgerufen wurde
verify(mockSong, times(2)).getTitle();
Was sind die Vorteile von Mockito?
- Keine von handgeschriebenen Klassen für Mock-Objekte nötig
- Supportet "refractoring-sichere" mock-objekte: Änderungen wie Umbennennungen von Methoden werden vom Compiler erkannt und führen nicht erst zur Laufzeit zu fehlern.
- Unterstützt return values und exceptions
- Unterstützt "Überprüfung der Reihenfolge" von Methodenaufrufen, für eines oder mehr Mock-Objekte
- Unterstützt "checking of the numbers of actual calls" des Mock-Objekts
Welche weiteren Konzepte gibt es bei den Mocks?
1) doThrow(...)
doThrow(new IOException())
.when(mockObj)
.save();
Mock wirft eine Exception, wenn save() aufgerufen wird.
2) doAnswer(...)
doAnswer(invocation -> {
System.out.println("called");
return null;
}).when(mock).run();
Damit kann man eigenes Verhalten definieren
3) reset()
Resetet das Mock-Objekt für Wiederverwendung
Welche Konzepte gibt es beim Argument Matches?
1) Benutzt Hamcrest Matches (Von JUnit-Library)
Heute -> any(), eq(), contains(), argThat(),
2) anyInt, anyString
when(userRepo.findUser("Anna"))
.thenReturn(user); Das funktioniert NUR für "Anna"
when(userRepo.findUser(anyString()))
.thenReturn(user); Das funktioniert für alle USER
Welche Counting Invocations gibt es?
- times(count)
- atLeastOnce()
- atLeast(min)
- atMost(max)
- never()
Was sind die Pro's und Kontra's von Mock-Objekten?
Pro's
- Helfen beim isolieren
- Handling von Interfaces mit vielen Methoden, wird einfacher durch Mocks
- "Near-Instant" Testing ist möglich, auch bei Code, welcher resource bound API's wie JDBC verwendet. Also Feedback kommt innerhalb eines Bruchteils
Kontra:
- Mock-Objekte versucht zu nahe das "echte" Objekt zu ersetzen -> Erhöhtes Risiko, dass das Mock-Objekt Bugs enthählt, wenn die Logik zu komplex ist.
- Mocking kann komplex sein mit API's wie JDBC
Was versteht man unter Metrik?
- Wie kann man Qualität definieren und anschliessend auch messen?
-
Was sind die Top 5 Gründe, warum IT-Projekte scheitern?
- Kommunikationsprobleme
- Schlechte Planung/Zu wenig Planung
- Mangel an Ressourcen
- Vorgabe oder Ziele sind nicht klar definiert
- Richtlinien
//Codequalitt ist nicht in der Top 5!
Was ist Softwarequalität?
- Kann nur in fertigen Code-teilen gemessen werden
- Codemetrik sagt uns:
-> Wie gut unser Code ist
-> Wie viel Aufwand notwendig ist, um die Codequalität auf ein bestimmte sLevel zu erhöhen
Codequalität ist ein Indikator für?
- Wartbarkeit
- Änderbarkeit
- Stabilität
- Enwticklungsaufwand
Was versteht man unter Softwarequalität? Welche Qualitätsmerkmale/Eigenschaften gibt es?
1) Functionality/Funktionalität -> Erfüllt die Software ihre Aufgaben korrekt? Suitability, accuracy, interoperability, compliance, securrity
2) Reliability / Zuverlässigkeit -> Wie Zuverlässig/stabil läuft die Software? Maturity, fault tolerance, recoverability
3) Maintainability/Wartbarkeit -> Wie leicht kann die Software geändert werden? Analyzability, changeability, stability, testability
4) Portability/Portabilität -> Wie leicht läuft die Software auf anderen Plattformen? adaptability, installability, conformance, replaceability
5) Usability/Benutzerfreundlichkeit -> Wie einfach ist die Software für Benutzer? understandability, learnability, operability
6) Efficiency/Effizienz -> Wie effizient nutz die Software Ressourcen? time behavior, resource behavior
7) Cost/Kosten -> Ressourcen, Zeit und Geld
Was ist das Iron-Triangle?
- Ein Modell welches zeigt, dass bei Projekten immer bestimmte Ziele in Konkurrenz zueinander stehen ->
Time -> Zeit
Cost -> Kosten/Ressourcen
Scope -> Umfang/Funktionalität
Grundidee: Wenn man eine dieser Grössen verändert, beeinflusst das die anderen!
- Man kann nicht alle 3 erreichen
- Was sind die Prioritäten?
Was ist die Definition von Metrik?
Grundidee:
- Man kann Eigenschaften wie Wartbarkeit, Analysierbarkeit, Komplexität nicht direkt messen -> Es braucht Indikatoren + Metriken
- Eine Messskala und Methode, um einen Wert eines Indikator zu bestimmen von einem Softwareprodukt
- Metrik ist eine konkrete Messmethode/Zahl
Was versteht man unter einem Indikator und welche gibt es?
- Interne Eigenschaften geben Hinweise auf externe Qualitätseigenschaften
- Hinweis darauf, wie gut/schlecht etwas ist
Externe Charakteristiken/Eigenschaft: Analzability
Indikator: Komplexität von Funktionen/Methoden
Metrik: McCabe Zyklomatischekomplexität = 18
Was ist ein Beispiel für Metrik + Indikator?
Indikator: Blutdruck
Metrik: 120/80 mmHg
Was sind die Charakteristiken von guten Metriken?
- Measureable/Messbarkeit: -> Wenn man es nicht messen kann, kann man es auch nicht benutzen
- Independent/Unabhängikeit -> Eine Metrik muss unabhängig vom Einfluss der Projektmitglieder sein -> Wenn die Mitglieder die Metrik manipulieren können, sind sie unnötig!
- Reliable /Zuverlässig -> Zusammenfassung von Metriken müssen plausibel sein, dafür müssen die Rohdaten zuverlässig sein
- Accurate /Akkurat -> Metriken müssen akkurat sein, um nützlich zu sein -> Auch wenn die Präzision variiert.
Warum benutzt man überhaupt Metriken?
- Metriken ist ein wichtiges Tool für die Qualitätsüberprüfung -> You Can't Manage what you can't control and you can't control what you don't measure
- Mach dich nicht zu einem Sklaven der Anzahl Metriken -> Benutze Metriken mit Sinn und Bescheidenheit, Behandle Metriken nicht wie ein absoluter Wert
- Metriken bedarfen immer einer Intepretation -> Die Intepretation muss mit allen Steakholdern geteilt werden und verstanden/nachvollzogen werden
Was genau können wir messen?
Eine simple Metrik ist -> Line of Code (LoC)
-> "Grobe" Idee über die grösse eines Projekts
- > Sehr ungenau, was als "Zeile" defineirt ist
LoC:
ist Abhängig von Coding Conventions, Proigrammiererfahrungen
LoC misst deshalb eher die Menge und nicht die Qualität!
Welche Statische Softwaremetriken gibt es?
Statisch bedeutet: Code wird analysiert, ohne das Programm auszuführen!
1) Size Metrics (Messen die Grösse des Codes) -> Lines of Codes, Anzahl Methoden, Anzahl Klassen, Anzahl Felder, Anzahl Packages
Idee: Wie gross/umfangreich ist das System?
2) Control Flow Metrics (Analysieren den Ablauf/Kontrollfluss im Code) -> Cyclomatic Complexity (Wie viele unterschiedliche Pfade existieren durch den Code), Nesting Depth (Wie tief Code verschachtelt ist), Dead Code Detection, Initialization before use
3) Style Metrics (Prüfen Coding-Style/Formatierung) -> Naming Conventions, Einrückung, Formatierung, Klammerstil etc.
4) OO Metrics (Objektorientierte Metriken) -> Anzahl Klassen/Methoden/Packages, Vererbungstiefe/-breite
5) Coupling Metrics (Messen Abhängigkeiten zwischen Klassen/Packages) WICHTIG FÜR WARTBARKEIT!
-> LCOM (Lack of Cohesion of Methods) Wie stark Methode einer Klasse zusammengehören -> Niedrige Cohesion = Klasse macht zu viele verschiedene Dinge
-> Number of Calling Classes: Wie viele andere Klassen diese Klasse verwenden -> Viele Abhängigkeiten = Änderungen werden riskanter
-> Efferent Coupling (Ce): Von diesem Package ausgehende Abhängigkeiten (Wovon hängt dieses Package ab?)
-> Afferent Coupling (Ca): Eingehende Abhängigkeiten (Wie viele andere Packages hängen von diesem Package ab?) -> Misst Wichtigkeit/Verantwortung
6) Statistische Metriken
-> Instability I = Ce/(Ce+Ca -> Viele ausgehende Abhängigkeiten und wenige eingehende ? instabil
-> Abstraktheit (Wie Abstrakt ist ein Package?) -> Also Anteil von Interfaces, abstrakten Klassen etc
Was ist Zyklomatische Komplexität?
- Metrik, weche die Komplexität von Code messen kann -> Wie viele unabhängige Kontrollfluss-Pfade durhc ein Programm gibt es?
