Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Folie 1 Software Qualitäts Labor Prüfkriterien für objektorientierte Systeme."—  Präsentation transkript:

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

2 Folie 2 Software Qualitäts Labor 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

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

4 Folie 4 Software Qualitäts Labor 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

5 Folie 5 Software Qualitäts Labor 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

6 Folie 6 Software Qualitäts Labor 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

7 Folie 7 Software Qualitäts Labor 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

8 Folie 8 Software Qualitäts Labor 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

9 Folie 9 Software Qualitäts Labor 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

10 Folie 10 Software Qualitäts Labor Lose Kopplung bedeutet 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

11 Folie 11 Software Qualitäts Labor 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

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

13 Folie 13 Software Qualitäts Labor 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 Abgeleitete Klassen fügen neue Elemente hinzu 20.Vollständiges Überschreiben von Methoden vermeiden 21.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

14 Folie 14 Software Qualitäts Labor 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

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

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

17 Folie 17 Software Qualitäts Labor Zusammenfassung der Kriterien 1 1.Keine globalen Funktionen oder Daten 2.Gute Strukturierung des Systems mit Hilfe von Klassen 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 7.In OO: Nutzung von Klassen zur Bildung von Modulen 8.Schmale Schnittstellen (wenig 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) 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

18 Folie 18 Software Qualitäts Labor Zusammenfassung der Kriterien 2 16.Nicht zu viele Attribute/Methoden pro Klasse 17.Methoden nutzen gemeinsame Attribute (Klassenebene) 18.Anweisungen beziehen sich auf gemeinsame Variable (Funktionsebene) 19.Abgeleitete Klassen fügen neue Elemente hinzu 20.Vollständiges Überschreiben von Methoden vermeiden 21.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 24.Nutzung abstrakter Schnittstellen 25.Methoden werden überschrieben, Funktionalität erweitert 26.Keine switch -Anweisungen zur Auswahl eines zu rufenden Moduls 27.Geeignete Tiefe der Vererbungshierarchie 28.Klare Organisation des Codes in Verzeichnissen 29.Wenig Referenzen über Verzeichnisse hinweg 30.Zentrale Haltung von Zeichenketten 31.Einfacher Kontrollfluss


Herunterladen ppt "Folie 1 Software Qualitäts Labor Prüfkriterien für objektorientierte Systeme."

Ähnliche Präsentationen


Google-Anzeigen