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
