Post on 05-Apr-2015
transcript
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