Nutzung bewährten Architekturwissens Flashcards
Definition: Framework
Ein Framework ist ein partiell vollständiges Softwaresystem (oder Teilsystem), das noch angepasst und instanziiert werden muss. Es definiert die Architektur für eine Familie von Systemen/Teilsystemen und spezifiziert diejenigen Stellen, an denen Anpassungen für spezifische Funktionalitäten vorgenommen werden müssen.
Definition: Klassenbibliotheken
Klassenbibliotheken sind komplexe Systeme von Klassen und Frameworks, die allgemeinen, applikationsunabhängigen Charakter haben und wiederverwendbares Wissen der objektorientierten Softwareentwicklung darstellen.
Entwurfsmuster (“Design Patterns”)
- Bewährte Lösungsmuster für immer wieder auftretende Aufgaben im Softwareentwurf
- Zielen auf implementierungsnahe Fragestellungen im Feinentwurf und in der Implementierung
Anwendung von Entwurfsmustern
Gebräuchliche Arten von Mustern:
- Implementierung: Object-Oriented Patterns, Idiome
- Softwarearchitektur: Architectural Patterns
- Entwurf: Entwurfsmuster, Design Patterns
- Analyse: Anaysis Patterns
Erzeugungsmuster: Das Prototype Pattern
- Liefert eine Objektinstanz, die auf Basis einer Vorlage erstellt wurde
- Verwendet, wenn sich zu erzeugende Objekte stark ähneln
- Oft verwendet in Klassenbibliotheken (z.B. Java Interface Cloneable)
Strukturmuster: Decorator Pattern
- Dient dazu, die Struktur einer Klasse zu verändern ohne jedoch eine
exzessive Bildung von Unterklassen zu verwenden
-> Alternative zu Vererbungsstrukturen - Ermöglicht die Modifikation von vorhandenen, nicht mehr veränderbaren
Funktionen, auch ohne Quellcode der genutzten Klasse - Grundlegende Idee: Zerlege die komplexe Funktionalität einer
Komponente in kleine Funktionsbündel (die dann flexibel kombinierbar
sind)
Umsetzung des Decorator Pattern:
1. Definiere die Basisfunktioalität eines Elements.
2. Die Schnittstelle Element wird durch den Decorator aufgegriffen.
3. Für jede Basisfunktionalität wird nun ein eigener Decorator gebildet.
Kritische Bewertung:
* Möglichkeit, ein System flexibel zu gestalten
* Das dekorierte Objekt kennt die dekorierenden Objekte nicht
* Verwendet z.B. für die File-I/O-Schnittstelle in Java
* Kann jedoch zu komplexen Laufzeitstrukturen führen
* Aufwand bei der Fehlerlokalisierung
* Schnell wachsednde Anzahl der Objekte möglich
Verhaltensmuster: Visitor Pattern (Besucher-Muster)
Trennt die Objekte in einer Objektstruktur von den Operationen, die auf
dieser Objektstruktur ausgeführt werden (Entkopplung von Objektstruktur
und Verhalten)
-> Steigerung der Flexibilität einer Architektur
Grundideen:
* Definition von zwei getrennten Hierarchien für Objekte und Operationen
* Definition eines Extension Points für neue Operationen
* Neue Operationen könen unabhängig und ohne Modifikation der
Objektstruktur festgelegt werden.
Kritische Bewertung:
* Ermöglicht Trennung von Objekten und Verhalten
Algorithmen können getrennt von Objektstrukturen gepflegt werden
* Einsatz muss wohlüberlegt erfolgen
Einführung neuer Typen zieht u.U. umfangreichere Anpassungen nach sich
* Pattern nicht passend, wenn sich Objektstruktur relativ häufig ändert
* Hebelt u.U. die Datenkapsel aus
Architekturmuster (“Architectural Patterns”)
- Beschreiben erprobte Lösungskonzepte für häufig auftretende
Entwurfsprobleme - Zielen auf Grobentwurf (und ggf. frühen Feinentwurf)
-> Grundlegende Entscheidungen hinsichtlich Organisation und
Interaktion von Komponenten im Softwaresystem
Systemstruktur: Pipes-and-Filters Pattern
Beschreibt Struktur von Softwaresystemen, die Datenströme verarbeiten
* Zentrale Komponenten Sender und Empfänger
* Nachrichtenaustausch über Kommunikationskanal (Pipeline)
* Kommunkationskanal aus Filtern (Datenverarbeitungsschritte), die mit Pipes untereinander verbunden sind
PRO:
* Datenverarbeitung zwischen Sender und Empfänger sehr flexibel
* Anpassungen und Erweiterungen einfach möglich
CON:
* Nur passend für Verarbeitung von Datenströmen
Model-View-Controller Pattern (MVC)
- Eines der bekanntesten Muster
- Teilt System auf in Datenmodell (Model), Präsentation (View) und Steuerung (Controller)
Vertreter einer Gruppe von Mustern, die Aufgaben im Systementwurf separieren
- Model-View-Presenter (MVP)
- Model-View-ViewModel (MVVM)
- Presentation-Abstraction-
Controller (PAC)
- …
PRO:
* Daten und ihre Darstellungen sind unabhängig voneinander änderbar
* Verschiedene Repräsentationen derselben Daten unterstützt
CON:
* Erhöhte Komplexität des Codes
Verteilung: Client-Server Architektur
- Trennung von Client und Server
- Teile des Systems werden auf nachfrage von dem Server bereitgestellt
Entwurfsregel S.O.L.I.D.
- Unterstützung bei der Bewertung und Kombination verschiedener
Lösungsansätze für den Entwurf
S.O.L.I.D. als Regel und Methapher für grundsätzlich soliden
Achitekturentwurf unter Berücksichtigung elementarer Prinzipien:
- Single Responsibility Principle
- Open-Closed-Principle
- Liskov’s Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Achtung: Mit Augenmaß einsetzen!
Single Responsibility Principle
- Eine Klasse (ein Modul) hat nur exakt eine Aufgabe.
- > Kohäsion
- Eine Klasse soll nur aus einem Grund geändert werden müssen.
- > Verantwortlichkent (Responsibility)
- Verantwortlichkeiten teilweise schwer zu identifizieren
Open-Closed Principle
Komponenten/Klassen sollen offen für Erweiterungen aber geschlossen für
Modifikationen sein.
Liskov’sches Substitutionsprinzip
Eine Klasse in einem objektorientierten System muss durch eine von ihr
abgeleitete, verfeinerte Kindklasse ersetzbar sein.
=> Schnittstellenabstraktion, Verfeinerung, Kapselung
Gut mit dem Konzept der Polymorphie realisierbar:
* Grunsätzlich: In einer Vererbungshierarchie kann eine Kindklasse dort
eingesetzt werden, wo eine Superklasse zulässig ist.
* Analog für Schnittstellen (Interfaces): Verschiedene Implementierungen
können ausgetauscht werden.
Lösungsansatz:
* Geschickte Wahl und kritisches Hinterfragen von Abstraktionen (vgl.
Open-Closed-Prinzip)
* Abstraktionen so wählen, dass Erhaltung der Eigenschaften und des
Verhaltens gewährleistet ist
* Nach Liskov: In der überschreibenden Klasse dürfen die Vorbedingungen
der Basisklasse nur abgeschwächt werden, die Nachbedingungen nur
verstärkt werden
Interface Segregation Principle (“Schnittstellensegregation”)
Clients dürfen keine Abhängigkeiten zu Operationen haben, die sie nicht benutzen!
Depencency Inversion Principle
Komponenten in “höheren” Schichten sollen nicht direkt von
Implementierungen in “niedrigeren” Schichten abhängen.
-> Entkopplung von Systemen mit Hilfe von Interfaces
