Software Qualitäts LaborFolie 1

Prüfkriterien für objektorientierte Systeme

Software Qualitäts LaborFolie 2

OO Konzepte OO Programmierung macht viele Strukturmerkmale des Entwurfs

explizit, aber Nutzung der Notation allein macht noch keinen guten OO Entwurf aus

Wesentliche Bestandteile eines Systems sind Objekte beschrieben durch Klassen

Objekte werden als eigenständige Einheiten betrachtet mit einem Zustand und der Fähigkeit, Nachrichten zu senden/zu verarbeiten

Entwurfskonzepte:– Bündelung– Kapselung– Modularität– Vererbung– Polymorphismus

Ein guter OO-Entwurf nutzt diese Prinzipien zum Vorteil der Entwurfsziele aus

Entwurfsziele:- änderbar- verstehbar

Software Qualitäts LaborFolie 3

Betrachtungsebenen

Paketebene: jedes Verzeichnis ein Paket

Dateiebene

Klassenebene

Attribute/Variable Methoden/Funktionen

Systemebene

Software Qualitäts LaborFolie 4

Bündelung Bündelung von Daten und zugehörigen Operationen in

Klassen Enge Verflechtung durch

– Schreib/Lesezugriffe auf Attribute

– Aufrufe von Methoden innerhalb der Klasse

Nutzen:– Wesentliches Strukturmerkmal, hilft eigenständige

Einheiten zu identifizieren

– Verständnis der Daten von Algorithmen abhängig und umgekehrt

– Separat wiederverwendbare Einheiten

gute Bündelung bedeutet...1. Keine globalen Funktionen oder Daten

2. Gute Strukturierung des Systems mit Hilfe von Klassen

Software Qualitäts LaborFolie 5

Kapselung Klassenelemente können explizit als öffentlich/privat

gekennzeichnet werden Nutzen:

– Macht Modulschnittstelle explizit– Verhindert unerwünschte Kopplung (prüfbar!)– Verständnis: Unterscheidung in wichtige/unwichtige Teile– Wartbarkeit: Änderungen am privaten Teil bleiben lokal

Software Qualitäts LaborFolie 6

Gute Kapselung bedeutet...3. Wenige Bestandteile einer Klasse sind öffentlich

4. Teile, die sich oft ändern nie öffentlich zugänglich machen

5. Erfahrung: Datenrepräsentation ändert sich häufig nur Methoden öffentlich machen

6. Geringe Kopplung zwischen Systemteilen, da anderenfalls viel Information verbreitet wird

Software Qualitäts LaborFolie 7

Modularität Ein System in separate Einheiten unterteilen Trennung zwischen stabilen und instabilen Systemteilen – instabil=

– Muss oft geändert werden aufgrund neuer Anforderungen

– Soll separat wiederverwendet werden

– Ist plattformabhängig

– Ist technologieabhängig In OO: Module (Klassen) können instanziiert werden

– Module sind auch dynamisch austauschbar

Nutzen:– Definition von Teilen, die separat entwickelt, referenziert, gewartet,

wiederverwendet werden können

– Antizipierte Änderungen wirken sich nur lokal aus

– Unterstützung von Abstraktion: Modulstruktur erlaubt Aufmerksamkeit auf einzelne Teile zu richten

Software Qualitäts LaborFolie 8

Gute Modularität bedeutet...7. In OO: Nutzung von Klassen zur Bildung von Modulen

8. Schmale Schnittstellen (wenig öffentliche Methoden, wenig Parameter)

9. Für große Module sollten separate Schnittstellenklassen verwendet werden

10. Kommunikation findet ausschließlich über Schnittstellen statt (keine globale Variable) Lose Kopplung Hohe Kohäsion

Software Qualitäts LaborFolie 9

Kopplung „Der Grad an Abhängigkeit zwischen Klassen“ Lose Kopplung bedeutet, es gibt wenig solcher Abhängigkeiten Kopplungsrichtung:

– Efferent: die Fokusklasse benutzt andere Klassen

– Afferent: die Fokusklasse wird von anderen Klassen benutzt

Arten der Nutzung– Aufrufkopplung: aufgrund des Aufrufs von Methoden

– Attributkopplung: aufgrund des Lesens/Schreibens von Attributen

– Vererbungskopplung: aufgrund des Erbens von Eigenschaften

Gefahren durch hohe Kopplung:– Verständnis: eng gekoppelte Teile müssen auch verstanden werden

– Wartbarkeit: Änderungen haben viele Seiteneffekte schlecht kontrollierbar

– Wiederverwendbarkeit: eng gekoppelte Teile lassen sich schlecht herauslösen

Software Qualitäts LaborFolie 10

Lose Kopplung bedeutet...11. Wenig Abhängigkeiten zwischen Klassen

12. Keine Abhängigkeiten von Implementierungsdetails von Modulen

13. Keine Abhängigkeit von globalen Elementen

14. Keine bidirektionalen Abhängigkeiten

15. Keine Nachrichtendurchschleusung

Software Qualitäts LaborFolie 11

Kohäsion „Der Grad zu welchem Designelemente aufeinander bezogen sind“ Tritt auf verschiedenen Ebenen auf:

– Paketebene: erfüllen alle enthaltenen Klassen den Zweck des Pakets?

– Klassenebene: Hat eine Klasse genau einen Zweck/Verantwortlichkeit?

– Funktionsebene: Führt eine Methode genau eine logisch zusammenhängende Operation aus?

Entwurfsprinzip: Eine Einheit = ein Konzept Kohäsion ist eine inhaltliche Forderung, aus Entwurf lassen sich nur

Indikatoren ableiten Auswertung von Strukturmerkmalen, welche eine Ähnlichkeit bzgl. der

Nutzung von Variablen/Attributen/Methoden/Klassen nahelegen

Software Qualitäts LaborFolie 12

Hohe Kohäsion bedeutet...16. Nicht zu viele Attribute/Methoden pro Klasse

17. Methoden nutzen gemeinsame Attribute (Klassenebene)

18. Anweisungen beziehen sich auf gemeinsame Variable (Funktionsebene)

Software Qualitäts LaborFolie 13

Vererbung Ausdrücken einer Spezialisierungsbeziehung zwischen Klassen Nutzen:

– Modellnähe: macht im Anwendungsgebiet existierende Ähnlichkeiten explizit– Wartbarkeit: in Verbindung mit Polymorphismus instabile oder konfigurierbare Teile

ausfaktorisieren Gefahren:

– Kann als Implementierungsvererbung missbraucht werden hohe Kopplung– Mehrfachvererbung von Implementierung ist unübersichtlich

Nutzung von Vererbung im Sinne einer Spezialisierung

Gemeinsamkeiten von Klassen in eine Oberklasse verlagern

Vererbung sinnvoll nutzen bedeutet...19. Abgeleitete Klassen fügen neue Elemente hinzu20. Vollständiges Überschreiben von Methoden vermeiden21. Es werden abstrakte Schnittstellen definiert

22. Keine Codedopplung in Klassen, die von gleichen Klienten benutzt werden ohne gemeinsame Oberklasse

23. Überschriebene Methoden sind inhaltlich ähnlich zur Methode der Basisklasse Substitutionssprinzip

Software Qualitäts LaborFolie 14

Polymorphismus Griechisch: „viele Formen“ Es gibt erschiedene Arten des Polymorphismus, mit OO wird meist der „subtype

polymorphism“ in Verbindung gebrachtEine Nachricht kann an verschiedene Methodenimplementierungen gebunden werden, abhängig vom Typ des Empfängerobjekts

Technisch durch Überschreiben von Methoden von Basisklassen realisiert

Nutzen:– Hohes Abstraktionspotenzial: abstrakte Konzepte in abstrakten Klassen ausdrücken– Erhöht Wartbarkeit: keine künstlichen Konstanten zur Identifizierung von Objekten und

switch-Anweisungen zum Anwenden von Operationen auf diesen– Macht Systeme flexibel: Implementierungen zur Laufzeit austauschbar

Gefahren:– Verteilen der Funktionalität auf zu viele Basisklassen

hohe Kopplung

Software Qualitäts LaborFolie 15

Polymorphismus sinnvoll nutzen bedeutet...

24. Nutzung abstrakter Schnittstellen25. Methoden werden überschrieben, Funktionalität erweitert26. Keine switch-Anweisungen zur Auswahl eines zu rufenden Moduls27. Geeignete Tiefe der Vererbungshierarchie

Software Qualitäts LaborFolie 16

Codierrichtlinien Neben strukturellen Merkmalen des Entwurfs hat auch der Code

Einflüsse auf Wartbarkeit, Portierbarkeit

29. wenig Referenzenüber Verzeichnissehinweg

28. Klare Organisation

des Codes in Verzeichnissen

30. Zentrale Haltung von Zeichenketten

31. EinfacherKontrollfluss

Software Qualitäts LaborFolie 17

Zusammenfassung der Kriterien1

1. Keine globalen Funktionen oder Daten2. Gute Strukturierung des Systems mit Hilfe von Klassen

3. Wenige Bestandteile einer Klasse sind öffentlich4. Teile, die sich oft ändern nie öffentlich zugänglich machen5. Erfahrung: Datenrepräsentation ändert sich häufig nur Methoden öffentlich

machen6. Geringe Kopplung zwischen Systemteilen

7. In OO: Nutzung von Klassen zur Bildung von Modulen8. Schmale Schnittstellen (wenig Methoden, wenig Parameter)9. Für große Module sollten separate Schnittstellenklassen verwendet werden10. Kommunikation findet ausschließlich über Schnittstellen statt (keine globale Variable)

11. wenig Abhängigkeiten zwischen Klassen12. Keine Abhängigkeiten von Implementierungsdetails von Modulen13. Keine Abhängigkeit von globalen Elementen14. Keine bidirektionalen Abhängigkeiten15. Keine Nachrichtendurchschleusung

Software Qualitäts LaborFolie 18

Zusammenfassung der Kriterien2

16. Nicht zu viele Attribute/Methoden pro Klasse17. Methoden nutzen gemeinsame Attribute (Klassenebene)18. Anweisungen beziehen sich auf gemeinsame Variable (Funktionsebene)

19. Abgeleitete Klassen fügen neue Elemente hinzu20. Vollständiges Überschreiben von Methoden vermeiden21. Es werden abstrakte Schnittstellen definiert22. Keine Codedopplung in Klassen, die von gleichen Klienten benutzt werden ohne

gemeinsame Oberklasse23. Überschriebene Methoden sind inhaltlich ähnlich zur Methode der Basisklasse

24. Nutzung abstrakter Schnittstellen25. Methoden werden überschrieben, Funktionalität erweitert26. Keine switch-Anweisungen zur Auswahl eines zu rufenden Moduls27. Geeignete Tiefe der Vererbungshierarchie

28. Klare Organisation des Codes in Verzeichnissen29. Wenig Referenzen über Verzeichnisse hinweg30. Zentrale Haltung von Zeichenketten31. Einfacher Kontrollfluss