Prüfkriterien für objektorientierte Systeme

Präsentation zum Thema: "Prüfkriterien für objektorientierte Systeme"—  Präsentation transkript:

1 Prüfkriterien für objektorientierte Systeme
Software Qualitäts Labor

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 Entwurfsziele: änderbar verstehbar Ein guter OO-Entwurf nutzt diese Prinzipien zum Vorteil der Entwurfsziele aus Software Qualitäts Labor

3 Betrachtungsebenen Systemebene Paketebene: jedes Verzeichnis ein Paket
Dateiebene Klassenebene Attribute/Variable Methoden/Funktionen Software Qualitäts Labor

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... Keine globalen Funktionen oder Daten Gute Strukturierung des Systems mit Hilfe von Klassen Software Qualitäts Labor

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 Labor

6 Gute Kapselung bedeutet...
Wenige Bestandteile einer Klasse sind öffentlich Teile, die sich oft ändern nie öffentlich zugänglich machen Erfahrung: Datenrepräsentation ändert sich häufig  nur Methoden öffentlich machen Geringe Kopplung zwischen Systemteilen, da anderenfalls viel Information verbreitet wird Software Qualitäts Labor

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 Labor

8 Gute Modularität bedeutet...
In OO: Nutzung von Klassen zur Bildung von Modulen Schmale Schnittstellen (wenig öffentliche Methoden, wenig Parameter) Für große Module sollten separate Schnittstellenklassen verwendet werden Kommunikation findet ausschließlich über Schnittstellen statt (keine globale Variable) Lose Kopplung Hohe Kohäsion Software Qualitäts Labor

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 Labor

10 Lose Kopplung bedeutet...
Wenig Abhängigkeiten zwischen Klassen Keine Abhängigkeiten von Implementierungsdetails von Modulen Keine Abhängigkeit von globalen Elementen Keine bidirektionalen Abhängigkeiten Keine Nachrichtendurchschleusung Software Qualitäts Labor

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 Labor

12 Hohe Kohäsion bedeutet...
Nicht zu viele Attribute/Methoden pro Klasse Methoden nutzen gemeinsame Attribute (Klassenebene) Anweisungen beziehen sich auf gemeinsame Variable (Funktionsebene) Software Qualitäts Labor

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 Vererbung sinnvoll nutzen bedeutet... Abgeleitete Klassen fügen neue Elemente hinzu Vollständiges Überschreiben von Methoden vermeiden Es werden abstrakte Schnittstellen definiert Keine Codedopplung in Klassen, die von gleichen Klienten benutzt werden ohne gemeinsame Oberklasse Überschriebene Methoden sind inhaltlich ähnlich zur Methode der Basisklasse Nutzung von Vererbung im Sinne einer Spezialisierung Gemeinsamkeiten von Klassen in eine Oberklasse verlagern Substitutionssprinzip Software Qualitäts Labor

14 Polymorphismus Griechisch: „viele Formen“
Es gibt erschiedene Arten des Polymorphismus, mit OO wird meist der „subtype polymorphism“ in Verbindung gebracht Eine 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 Labor

15 Polymorphismus sinnvoll nutzen bedeutet...
Nutzung abstrakter Schnittstellen Methoden werden überschrieben, Funktionalität erweitert Keine switch-Anweisungen zur Auswahl eines zu rufenden Moduls Geeignete Tiefe der Vererbungshierarchie Software Qualitäts Labor

16 Codierrichtlinien Neben strukturellen Merkmalen des Entwurfs hat auch der Code Einflüsse auf Wartbarkeit, Portierbarkeit 28. Klare Organisation des Codes in Verzeichnissen 30. Zentrale Haltung von Zeichenketten 29. wenig Referenzen über Verzeichnisse hinweg 31. Einfacher Kontrollfluss Software Qualitäts Labor

17 Zusammenfassung der Kriterien1
Keine globalen Funktionen oder Daten Gute Strukturierung des Systems mit Hilfe von Klassen Wenige Bestandteile einer Klasse sind öffentlich Teile, die sich oft ändern nie öffentlich zugänglich machen Erfahrung: Datenrepräsentation ändert sich häufig  nur Methoden öffentlich machen Geringe Kopplung zwischen Systemteilen In OO: Nutzung von Klassen zur Bildung von Modulen Schmale Schnittstellen (wenig Methoden, wenig Parameter) Für große Module sollten separate Schnittstellenklassen verwendet werden Kommunikation findet ausschließlich über Schnittstellen statt (keine globale Variable) wenig Abhängigkeiten zwischen Klassen Keine Abhängigkeiten von Implementierungsdetails von Modulen Keine Abhängigkeit von globalen Elementen Keine bidirektionalen Abhängigkeiten Keine Nachrichtendurchschleusung Software Qualitäts Labor

18 Zusammenfassung der Kriterien2
Nicht zu viele Attribute/Methoden pro Klasse Methoden nutzen gemeinsame Attribute (Klassenebene) Anweisungen beziehen sich auf gemeinsame Variable (Funktionsebene) Abgeleitete Klassen fügen neue Elemente hinzu Vollständiges Überschreiben von Methoden vermeiden Es werden abstrakte Schnittstellen definiert Keine Codedopplung in Klassen, die von gleichen Klienten benutzt werden ohne gemeinsame Oberklasse Überschriebene Methoden sind inhaltlich ähnlich zur Methode der Basisklasse Nutzung abstrakter Schnittstellen Methoden werden überschrieben, Funktionalität erweitert Keine switch-Anweisungen zur Auswahl eines zu rufenden Moduls Geeignete Tiefe der Vererbungshierarchie Klare Organisation des Codes in Verzeichnissen Wenig Referenzen über Verzeichnisse hinweg Zentrale Haltung von Zeichenketten Einfacher Kontrollfluss Software Qualitäts Labor