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

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

of 18

  • date post

    05-Apr-2015
  • Category

    Documents

  • view

    102
  • download

    0

Embed Size (px)

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

  • Folie 1
  • Folie 1 Software Qualitts Labor Prfkriterien fr objektorientierte Systeme
  • Folie 2
  • Folie 2 Software Qualitts 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 eigenstndige Einheiten betrachtet mit einem Zustand und der Fhigkeit, Nachrichten zu senden/zu verarbeiten Entwurfskonzepte: Bndelung Kapselung Modularitt Vererbung Polymorphismus Ein guter OO-Entwurf nutzt diese Prinzipien zum Vorteil der Entwurfsziele aus Entwurfsziele : -nderbar -verstehbar
  • Folie 3
  • Folie 3 Software Qualitts Labor Betrachtungsebenen Paketebene: jedes Verzeichnis ein Paket Dateiebene Klassenebene Attribute/VariableMethoden/Funktionen Systemebene
  • Folie 4
  • Folie 4 Software Qualitts Labor Bndelung Bndelung von Daten und zugehrigen Operationen in Klassen Enge Verflechtung durch Schreib/Lesezugriffe auf Attribute Aufrufe von Methoden innerhalb der Klasse Nutzen: Wesentliches Strukturmerkmal, hilft eigenstndige Einheiten zu identifizieren Verstndnis der Daten von Algorithmen abhngig und umgekehrt Separat wiederverwendbare Einheiten gute Bndelung bedeutet... 1.Keine globalen Funktionen oder Daten 2.Gute Strukturierung des Systems mit Hilfe von Klassen
  • Folie 5
  • Folie 5 Software Qualitts Labor Kapselung Klassenelemente knnen explizit als ffentlich/privat gekennzeichnet werden Nutzen: Macht Modulschnittstelle explizit Verhindert unerwnschte Kopplung (prfbar!) Verstndnis: Unterscheidung in wichtige/unwichtige Teile Wartbarkeit: nderungen am privaten Teil bleiben lokal
  • Folie 6
  • Folie 6 Software Qualitts Labor Gute Kapselung bedeutet... 3.Wenige Bestandteile einer Klasse sind ffentlich 4.Teile, die sich oft ndern nie ffentlich zugnglich machen 5.Erfahrung: Datenreprsentation ndert sich hufig nur Methoden ffentlich machen 6.Geringe Kopplung zwischen Systemteilen, da anderenfalls viel Information verbreitet wird
  • Folie 7
  • Folie 7 Software Qualitts Labor Modularitt Ein System in separate Einheiten unterteilen Trennung zwischen stabilen und instabilen Systemteilen instabil= Muss oft gendert werden aufgrund neuer Anforderungen Soll separat wiederverwendet werden Ist plattformabhngig Ist technologieabhngig In OO: Module (Klassen) knnen instanziiert werden Module sind auch dynamisch austauschbar Nutzen: Definition von Teilen, die separat entwickelt, referenziert, gewartet, wiederverwendet werden knnen Antizipierte nderungen wirken sich nur lokal aus Untersttzung von Abstraktion: Modulstruktur erlaubt Aufmerksamkeit auf einzelne Teile zu richten
  • Folie 8
  • Folie 8 Software Qualitts Labor Gute Modularitt bedeutet... 7.In OO: Nutzung von Klassen zur Bildung von Modulen 8.Schmale Schnittstellen (wenig ffentliche Methoden, wenig Parameter) 9.Fr groe Module sollten separate Schnittstellenklassen verwendet werden 10.Kommunikation findet ausschlielich ber Schnittstellen statt (keine globale Variable) Lose Kopplung Hohe Kohsion
  • Folie 9
  • Folie 9 Software Qualitts Labor Kopplung Der Grad an Abhngigkeit zwischen Klassen Lose Kopplung bedeutet, es gibt wenig solcher Abhngigkeiten 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: Verstndnis: eng gekoppelte Teile mssen auch verstanden werden Wartbarkeit: nderungen haben viele Seiteneffekte schlecht kontrollierbar Wiederverwendbarkeit: eng gekoppelte Teile lassen sich schlecht herauslsen
  • Folie 10
  • Folie 10 Software Qualitts Labor Lose Kopplung bedeutet... 11.Wenig Abhngigkeiten zwischen Klassen 12.Keine Abhngigkeiten von Implementierungsdetails von Modulen 13.Keine Abhngigkeit von globalen Elementen 14.Keine bidirektionalen Abhngigkeiten 15.Keine Nachrichtendurchschleusung
  • Folie 11
  • Folie 11 Software Qualitts Labor Kohsion Der Grad zu welchem Designelemente aufeinander bezogen sind Tritt auf verschiedenen Ebenen auf: Paketebene: erfllen alle enthaltenen Klassen den Zweck des Pakets? Klassenebene: Hat eine Klasse genau einen Zweck/Verantwortlichkeit? Funktionsebene: Fhrt eine Methode genau eine logisch zusammenhngende Operation aus? Entwurfsprinzip: Eine Einheit = ein Konzept Kohsion 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
  • Folie 12
  • Folie 12 Software Qualitts Labor Hohe Kohsion bedeutet... 16.Nicht zu viele Attribute/Methoden pro Klasse 17.Methoden nutzen gemeinsame Attribute (Klassenebene) 18.Anweisungen beziehen sich auf gemeinsame Variable (Funktionsebene)
  • Folie 13
  • Folie 13 Software Qualitts Labor Vererbung Ausdrcken einer Spezialisierungsbeziehung zwischen Klassen Nutzen: Modellnhe: 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 unbersichtlich Nutzung von Vererbung im Sinne einer Spezialisierung Gemeinsamkeiten von Klassen in eine Oberklasse verlagern Vererbung sinnvoll nutzen bedeutet... 19.Abgeleitete Klassen fgen neue Elemente hinzu 20.Vollstndiges 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
  • Folie 14
  • Folie 14 Software Qualitts 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, abhngig vom Typ des Empfngerobjekts Technisch durch berschreiben von Methoden von Basisklassen realisiert Nutzen: Hohes Abstraktionspotenzial: abstrakte Konzepte in abstrakten Klassen ausdrcken Erhht Wartbarkeit: keine knstlichen Konstanten zur Identifizierung von Objekten und switch -Anweisungen zum Anwenden von Operationen auf diesen Macht Systeme flexibel: Implementierungen zur Laufzeit austauschbar Gefahren: Verteilen der Funktionalitt auf zu viele Basisklassen hohe Kopplung
  • Folie 15
  • Folie 15 Software Qualitts Labor Polymorphismus sinnvoll nutzen bedeutet... 24.Nutzung abstrakter Schnittstellen 25.Methoden werden berschrieben, Funktionalitt erweitert 26.Keine switch -Anweisungen zur Auswahl eines zu rufenden Moduls 27.Geeignete Tiefe der Vererbungshierarchie
  • Folie 16
  • Folie 16 Software Qualitts Labor Codierrichtlinien Neben strukturellen Merkmalen des Entwurfs hat auch der Code Einflsse auf Wartbarkeit, Portierbarkeit 29. wenig Referenzen ber Verzeichnisse hinweg 28. Klare Organisation des Codes in Verzeichnissen 30. Zentrale Haltung von Zeichenketten 31. Einfacher Kontrollfluss
  • Folie 17
  • Folie 17 Software Qualitts 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 zugnglich machen 5.Erfahrung: Datenreprsentation ndert sich hufig 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.Fr groe Module sollten separate Schnittstellenklassen verwendet werden 10.Kommunikation findet ausschlielich ber Schnittstellen statt (keine globale Variable) 11.wenig Abhngigkeiten zwischen Klassen 12.Keine Abhngigkeiten von Implementierungsdetails von Modulen 13.Keine Abhngigkeit von globalen Elementen 14.Keine bidirektionalen Abhngigkeiten 15.Keine Nachrichtendurchschleusung
  • Folie 18
  • Folie 18 Software Qualitts 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 fgen neue Elemente hinzu 20.Vollstndiges 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, Funktionalitt 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