VL B

Analyse: Was soll das System tun?

Entwurf: wie kann das System realisiert werden?

Starrheit: Änderungen an Software sind schwierig, viele abhängige Bausteine bei anpassung

Zerbrechlichkeit: Änderung an einer Stelle in Software führt zu Fehlern an einer anderen Stelle

Immobilität: Teile der Software können nur schlecht wiederverwendet werden

Viskosität: Bei Änderungen ist es aufwendig den Entwurf zu folgen (förderungen von hacks, workarounds etc)

Leitfaden für Entwurf

Welche Prinzipen mit welcher gewichtung angewendet werden soll, sollte gegen konkreten Anforderungen abgewogen werden

Modularisierung: Strukturierung eines Softwaresystems in sich geschlossene Bausteine

Separation of Concerns

• Vorteile: Klarere Organisation und Sturktur des SW-Systems

• Verbesserte Änderbarkeit einzelner Aspekte

• Bessere Lokalisierung von Fehlern

Kapslung:

• Benutzerabstraktion: Verwedung von Baustein über schlanke, öffentliche Schnittstelle

• Geheimsnisprinzip: Innere Details werden vervorgen (z.B. Entwurfs-/Implementierungsentscheidungen)

Lose Kopplung:

• Kopplung allgmeine: Maß für Sträke der Beziehung zwischen Bausteine

• z.B. durch Aufruf (Service Operation)

• notwendig, da die Bausteine sonst nicht zusammenarbeiten können

• Starke kopplung führt zu hohe Komplexität und Starrheit

• Vorteile:

  • Verringerung der Komplexität

  • Verbesserung der änderbarkeit

Hohe Kohäsion:

• Kohäsion: Maß für den inneren Zusammenhalt innerhalb eines Bausteins

• Hohe Kohäsion: Elemente eines Bausteins sollten inhaltloch eng zusammen gehörren

• Ziele:

  • Bessere Verstehbarkeit

  • Leichte Änderbarkeit

• Gerine Kohäsion -> Bausteine mehr Modulariseren (SoC)

Jedes Objekt dar nur seinen direkten Nachbar kennen, nicht aber die Nachbarn des Nachbarn (“Dont talk to strangers”)

Ziel: Minimierung der Kopplung

Vorteil: Verringerung der Kopplung

Nachteil:

• Mehraufwand für die Implemetierung von Wrapper-Methoden

• Strukturierung nach Law of Demeter führt ggf. zu Perfmance-Verlust bzw. erhöhtem Speicherbedarf

Auf Ebene von Klassen formuliert, teilweise auch übertragbar auf größere Bausteine

Prinzipen:

1. Single Responsiblility Principle

2. Open-Closed Principle

3. Liskov Substitution Principle

4. Interface Segragation Principle

5. Dependency Inversion Principle

Modul verantwortlich gegenüber einem, und nur einem Akteur

Modul: kohäsive Menge von funktionen und Datenstrukturen (z.B. eine Klasse)

Idee: Aktuere bestimmen die Verantwortlichkeiten eines Moduls und können Änderungsbedarf verursachen

Grob: Dinge, die sich auch verschiedenen gründen ändern können, sollten getrennt werden

Spezialisierung von SoC und Hohe Kohäsion

Vorteile:

• Erhöhung der Kohäsion

• Verbesserung der Modularisierung

Nachteil:

• Gefahr zu starker Modualisierung -> unnötige Erhöhung der Komplexität

Softwarearchitektur soll offen für Erweiterungen, aber geschlossen für Modifkationen sein

Ziel: Erweiterungen ohne Änderungen von bestehendem Quellcode möglich machen

Verringerung von gefahr ungewollter Seiteneffekten (Regression) bei Erweiterungen

z.B. durch Interfaces/Polymophie implementieren

Vorteile:

• Verbesserung der Erweiterbarkeit

• Erhöhung der Stabilität

Nachteil:

• Höherer Abstraktionsgrad erforderlich

Jede Basisklasse soll durch ihre abgeleiteten Klassen (Unterklassen) ersetzbar sein

Ziel: Unterklassen halten stets die Verträge ihrer Oberklassen ein -> Vermeidung von unerwartetem bzw. semantisch falschem Verhalten

Mehrere Schnittstellen oftmals besser als eine große Schnittstelle

Clients sollen nicht gezwungen sein von Methoden abhängig zu sein, die sie gar nicht brauchen

Ziel: Hohe Kohäsion von Schnittstellen -> Verringerung von Abhängigkeiten und Komplexität

Vorteile:

• Verringerung/Abschwächung von Abhängigkeiten

• Bessere Trenung von Zuständigkeiten

Nachteile:

• Erhöhung der Anzahl von Schnittstellen

Abhängigkeiten nur von Abstraktionen (z.B. Interfaces, abstrakte Klassen) erlauben, und nicht von Implementierungen

• Verringerung von Abhängigkeiten

• Austaschbarkeit von Implementierung

definieren einen Rahmen für eine systematische Herangehensweise an den Entwurf

enthalten häufig Mustersprachen

z.B. DDD, WAM-Ansatz

WAM = Werkzeug, Automat, Material

verwendet Entwurfsmetaphern, mit deren Hilfe sich Elemente einer Domäne identifizieren und kategorisieren lassen

Ziel: Entwurf soll durch die Fachsprache und Abläufe der Domäne bestimmt werden (Strukturähnlichkeit)

Fachwerte: Modellieren benutzerdefinierte Werte aus der Domäne, nicht veränderbar, keine Identität, z.B. IBAN, Telefonnummer

Material: Repräsentieren Konzepte aus der Domämne, Veränderbar, besitzen eigene Identität, z.B. Konot, Vetrag

Fachliche Service: Bündeln zusammengehörige Fachliche gegenstände oder Prozesse, Stellen dient zur verfügung, z.B. ZahlungsService

Werkzeuge: Erlauben das interaktive Erledigen von Aufgaben, z.B. Zahlungs-App

Automaten: Automatisierte Folgen von (wiederkehrenden) Arbeitsschritten, z.B. nächtlicher Batchlauf für Überweisungen

Technische Service: Repräsentieren technische Schnitstellen, z.B. lesen der benötigten Materialen und Fachwerte aus einer DB

Prinzipielle Lösungen für wiederkehrende Probleme

Liefern eine Sprache, um über Probleme und deren Lösungen sprechen zu können

Architekturmuster:

• beschreiben Systemstrukturen, die die Gesamtarchitektur eines Systems festlegen

• Spezifizieren, wie Subsysteme zusammenarbeiten

• Makroarchitektur

Entwurfsmuster:

• geben bewährte generische Lösungen für häufig wiederkehrende Entwurfsprobleme an, die in bestimmten Situationen auftreten

• legen struktur von Subsystemen fest

• Mikroarchitektur

Softwaresystem in Schichten aufteilen

Jede Komponenten genau eine Schicht

Jede Schicht abstrahiert von der darunter liegenden Schicht

Typischerweise jede Schicht nur zugruff auf die nächst niedrigere Schicht (lineare Ordnung)

Drei-Schichten Architektur

• Präsentationsschicht

• Fachlogikschicht

• Datenhaltungsschicht

Vorteil:

• Leicht verständlich

• Austauschbarkeit der Implementeierung einer Schicht

Nachteil:

• ggf. schlechtere Performance, besonders bei strikter linearer Ordnung

• Manche Änderungen/Erweitrungen können Anpasung auf allen Schichten nach sich ziehen

Präzisierung des Schichtenansatzes

Grundidee:

• Fachdomäne bildet Kern des Systems

• Fachdomöne ist vollständig unabhhängig von der technischen Infrastruktur

Fachdomäne kapselt alle für die Fachlichkeit relevanten Elemente (Entitäten, Datenstrukturen, Regeln, Funktionen etc)

Fachdomäne kennt keine Details der technischen Infrastuktur, sie dfiniert lediglich Schnittstillen (sekundäre Ports)

technische infrastruktur realisiert diese schnittstelle mittels adaptern -> Anwendung von Dependency Inversion

Clean Architecture:

• gleiches grundprinzip

• fachmodelle (zentrale schale) vollständig unabhängig von der technischen Infrastruktur

Vorteil:

• Fachlicher Code hat keinerlei Abhängigkeiten zur technischen Infrastruktur -> Erleichterte Austauschbarkeit der Infrastruktur

• Hohe Modularisierung des Gesamtsystems

Nachteil:

• Sehr saubere Modellierung bzw. Implementerung der Fachdomäne notwendig

CQRS = Command Query Responsibility Segregation

für verteile Systeme

Ziel:

• Verbesserung der Perfomanz bei verteilten Systemen

• Verhinderung eines ggf. überkomplexen Datenmodells

Grundidee:

• Auftrennung von Schnitstellen in:

  • rein lesenden Operationen (Queries)

  • rein schreibenden Operationen (Commands)

Im unterschied zu Commands sind Queries:

• typischerweise leicht parallelisierbar, da nicht gegenseitig beinflussen

• idempotent (mehrfache ausführen führt zu gleichen ergebnis)

Trennung beschränkt sich nicht auf Schnittstellen

• Auch Datenmodelle und eigentlichte Datenhaltung können entkoppelt werden

  • z.B. bei System in denen viele Lesende und weniger schreibende Zugriffe durchgeführt werden

Auch: Event-Queue

Architekturmuster für ereignisbasierte Systeme

Zwei Arten von Bausteine:

• Sender (Publisher) von Nachrichten

• Empfänger (Subscriber) von Nachrichten

Ziele:

• Entkopplung von Bausteinen

• Integration von unterschiedlicher Systeme?

Erzeugende Muster (creational patterns) -> erzeugen von Objekten

Strukturelle Muster (structural patterns) -> beschreiben die Komposition von Klassen und Objekten

Verhaltensmuster (behavioural patterns) -> kommunikation sowie verteilung von verantwortlichkeiten zwischen Klassen oder Objekten