Vorlesung 4: Grundsätze für den Architekturentwurf Flashcards
Was sind architektonisch relevante Prinzipien?
▪ Ein Prinzip ist eine grundlegende Idee / Regel / Überzeugung, die erklärt oder kontrolliert, wie etwas strukturiert ist / funktioniert
▪ Eine strikte Anwendung von Prinzipien kann in bestimmten Szenarien zu einem unnötigen Mehraufwand führen
- Konkrete Anforderungen sollten höher gewichtet werden als Prinzipien
- Prinzipien bauen auf jahrelanger Erfahrung auf und sollten nicht einfach aufgegeben werden
▪ Prinzipien existieren auf verschiedenen Abstraktionsebenen
- Prinzipien auf Architektur-Ebene
- Prinzipien auf Code-Ebene
- Viele Dinge, die sich nicht einfach einem der beiden Bereiche zuordnen lassen
▪ Prinzipien können aus verschiedenen Disziplinen entstehen
- Direkt als Best-Practice aus dem Systems Engineering
- Als Ableitung aus einem verwandten Gebiet (z.B. aus der kognitiven Psychologie)
▪ Generell gilt: konkrete Anforderungen sollten höher gewichtet werden als Prinzipien!
Was haben Prinzipien aus der kognitiven Psychologie mit Softwarearchitektur zu tun?
Einige Prinzipien stammen aus dem Bereich der kognitiven Psychologie
▪ Softwareentwickler und -architekten verbringen viel Zeit mit dem Lesen und Verstehen von bestehendem
Quellcode
▪ Der Anteil der Wartungskosten, der auf das Verständnis des Quellcodes zurückzuführen ist: ~50 %
▪ Daher müssen die inneren Strukturen eines Systems (d. h. die Organisation des Quellcodes) auch nach langer Zeit leicht
auch nach längerer Zeit noch verständlich sein
▪ Die kognitive Psychologie hilft zu verstehen, welche Art von Strukturen leichter zu verstehen sind und welche nicht
▪ Im Wesentlichen lassen sich aus drei kognitiven Prozessen Prinzipien für die Softwarearchitektur ableiten:
- Chunking
- Erstellung von Schemata
- Erstellung von Hierarchien
Beschreibe den kognitiven Prozess des Chunking
▪ Der Mensch ist mit einer Vielzahl von Informationen konfrontiert, die verarbeitet werden müssen.
▪ Deshalb werden Wissenseinheiten verdichtet, gruppiert und abstrahiert
▪ Das Verdichten und Gruppieren von Wissenseinheiten wird Rekodierung genannt
▪ Der gesamte Prozess wird als Chunking bezeichnet
▪ Chunking ermöglicht es dem Menschen, komplexe Sachverhalte mit Hilfe seines
Kurzzeitgedächtnis zu analysieren (d.h. Zugang zu allen notwendigen Informationen zu haben)
▪ Softwareentwickler und -architekten verwenden automatisch Chunking, wenn sie
ein neues System mit einem Bottom-up-Ansatz analysieren:
- Quellcode wird im Detail gelesen / verstanden
- Gesammeltes Wissen über das System wird aggregiert, bis ein allgemeines Verständnis
der Strukturen vorhanden ist
▪ Chunking wird auch verwendet, wenn neues Wissen leicht zu bereits vorhandenen “Chunks” hinzugefügt werden kann
Im Zusammenhang mit Chunking, was ist das Prinzip der Modularität?
Das Prinzip der Modularität, formuliert von David Parnas, besagt, dass ein Modul eine in sich geschlossene Einheit ist, die ihre inneren Strukturen und zusammenhängende Funktionalitäten kapselt. Dabei sind folgende Aspekte zentral:
Chunking: Nur sinnvoll zusammenhängende Funktionalitäten und Strukturen werden in einem Modul gekapselt. Eine zufällige Gruppierung ist nicht sinnvoll.
Verbergen von Informationen:
Ein Modul sollte genau eine Entwurfsentscheidung verbergen.
Datenstrukturen, die diese Entscheidung betreffen, sollten gekapselt werden.
Separation of Concerns:
Verschiedene Teile einer größeren Aufgabe sollten durch verschiedene Elemente einer Lösung repräsentiert werden.
Einheiten, die zu groß sind und für zu viele Dinge verantwortlich sind, sollten zerlegt werden.
Hohe Kohäsion:
Kohäsion bezieht sich auf den Grad der Zusammengehörigkeit der Elemente einer Einheit und sollte hoch sein.
Verschiedene Arten von Kohäsion (von niedrig bis hoch): logisch, zeitlich, prozedural, kommunikativ, sequenziell, funktional.
Prinzip der einzigen Verantwortung (SRP):
Eine Einheit sollte nur eine definierte Aufgabe haben und keine Funktionalitäten enthalten, die nicht zu dieser Aufgabe gehören.
Es sollte nie mehr als einen Grund geben, diese Einheit zu ändern.
Zusammenfassend sollte eine modulare Architektur aus kohärenten, minimal gekoppelten Einheiten bestehen, die jeweils eine klare und begrenzte Verantwortung haben. Dies fördert die Übersichtlichkeit, Wartbarkeit und Flexibilität des Systems.
Erkläre Kognitive Prozesse: Erstellung von Schemata.
▪ Schemata sind mentale Konzepte, die kognitive Prozesse und Verhalten steuern (Schema-Theorie)
- Informieren den Menschen darüber, was er aufgrund von Erfahrungen und Situationen erwarten kann
- strukturieren komplexe Wissenseinheiten, die aus abstrakten und konkreten Informationen bestehen
- Enthalten typische Eigenschaften mit Wertebereichen (abstrakte Ebene) und Beispielen (konkrete Ebene)
▪ Entsteht durch Erfahrung, Veränderungen der definierten Eigenschaften sind schwer (stellt wahrscheinlich das ganze Schema in Frage)
ganze Schema in Frage stellen)
▪ Schemata und Chunking werden oft in Kombination verwendet:
- Eine Situation wird auf der Grundlage eines bestimmten Schemas bewertet
- Die Information wird dann als Chunk verarbeitet
▪ Der Rückgriff auf bestehende Schemata ermöglicht es (Experten), eine neue Situation (z. B. eine zu analysierende Softwarearchitektur)
(z.B. eine zu analysierende Softwarearchitektur) durch deduktives Denken schneller zu beurteilen
▪ Patterns sind ein Beispiel aus der Softwareentwicklung:
- Patterns sind eine abstrakte Beschreibung einer Lösung mit verschiedenen Beispielen
- Sobald ein Muster verstanden ist, können Architekten und Entwickler es leicht im Quellcode erkennen und so das Verständnis erleichtern
zum Kognitive Prozesse: Erstellung von Schemata: Erkläre die Verwendung von Mustern zur Nutzung von Schemata.
Typen von Mustern im Software Engineering:
Design Patterns: Auf Entwicklungsebene (z.B. Singleton, Observer).
Architekturstile: Auf Systemebene (z.B. Client-Server, Layered Architecture).
Korrekte Nutzung von Mustern:
Vorteile:
Schnelleres Verständnis ohne detaillierte Analyse (auf Annahmen basierend).
Ermöglicht einen Top-Down-Ansatz zum Systemverständnis.
Nachteile bei falscher Nutzung:
Falsche Annahmen führen zu Problemen.
Quelle von Fehlern durch Missverständnisse.
Konsistenz:
Komponenten sollten den Spezifikationen der Gesamtarchitektur folgen.
Muster müssen konsistent verwendet werden.
Fehlen oder unbekannte Muster:
Ebenso problematisch wie falsch verwendete Muster.
Können zu erheblichen Verzögerungen und Fehlerquellen führen.
Pattern-Sprachen:
Definition: Architekturstile, die den Gebrauch von Mustern in der Gesamtarchitektur definieren.
Aspekte:
Verantwortlichkeiten: Klare Definition der Verantwortlichkeiten jedes Elements.
Interaktionen: Erlaubte Interaktionen zwischen den Elementen.
Benennung: Einheitliche Namenskonventionen.
Beispiel: Domain Driven Design (DDD) als eine solche Pattern-Sprache.
Projektspezifische Sprachen: Oft basierend auf genutzten Frameworks und Technologien entwickelt.
Durch die korrekte und konsistente Anwendung bekannter Muster können Softwarearchitekten und -entwickler von Schemata profitieren, was das Verständnis und die Effizienz bei der Entwicklung und Wartung von Systemen verbessert.
Erkläre Kognitive Prozesse: Bildung von Hierarchien.
▪ Der Mensch kann sich Wissen leichter aneignen, wenn es hierarchisch strukturiert ist
hierarchisch strukturiert ist (baumartige Strukturen)
▪ Hierarchien und Chunking werden oft in Kombination verwendet: Chunks werden typischerweise
in Hierarchien gespeichert
▪ Hierarchien sollten sich immer in der Software-Architektur widerspiegeln
- Top-down-Verständnis auf Basis von Hierarchien ist schneller als Bottom-up-Ansätze
- Softwareentwickler / Architekten können bestimmte Ebenen / Teile eines Systems ignorieren und so
Komplexität reduzieren
▪ In der Praxis sind baumartige Strukturen oft nicht in reiner Form vorhanden
▪ Stattdessen finden sich azyklisch gerichtete Graphen
▪ Was verhindert werden muss, sind zyklische Abhängigkeiten zwischen Komponenten:
- Zyklen vermindern die Modifizierbarkeit
- Zyklen verringern die Testbarkeit (Isolation wird schwierig)
- Zyklen erhöhen die Fehleranfälligkeit
- Zyklen verringern die Möglichkeit, Komponenten unabhängig voneinander einzusetzen
- Zyklen erschweren das Verständnis bestehender Strukturen
▪ Zyklen sind oft ein Ergebnis von misslungener Modularität und falsch verwendeten Mustern
▪ Umgekehrt führt die Anwendung der vorgegebenen “Regeln” für Modularität und Musterkonsistenz zu einer zyklenfreien Architektur
▪ Die Verwendung von Mustersprachen verhindert Zyklen
Sieh dir die Abbildung an zu Fehlende Hierarchien in einer modularen Architektur
Was sind die Prinzipien aus der Softwaretechnik?
Prinzipien aus der Softwareentwicklung:
Überlappen mit Prinzipien der kognitiven Psychologie (z.B. modulare Architekturen, Schemata, Hierarchien).
Im Detail: Prinzipien wie Interface Segregation Principle und Single Responsibility Principle.
Ebenen der Prinzipien:
Methoden (Wie arbeiten wir zusammen?).
Strukturen (Wie werden Dinge umgesetzt?).
1.DRY (Don’t Repeat Yourself):
Reduzierung von Code-Wiederholungen.
Jedes Wissenselement sollte eine eindeutige, maßgebliche Repräsentation im System haben.
Vorteile: Weniger Code, höhere Wartbarkeit, geringere Kosten.
Achtung: Manche Redundanzen können die Wartbarkeit verbessern.
Gegenkonzept: WET (Write Everything Twice).
2.KISS (Keep it Simple, Stupid):
Systeme so einfach wie möglich halten.
Erleichtert das Lesen und Verstehen von Code und erhöht die Wartbarkeit.
Unterschiedliche Systeme benötigen unterschiedliche Komplexitätsgrade.
KISS zielt darauf ab, unnötige Komplexität (accidental complexity) zu reduzieren.
3.YAGNI (You Ain’t Gonna Need It):
Vermeidung unnötiger Funktionalitäten.
Keine Vorarbeit für eventuell zukünftig benötigte Funktionen leisten.
Spart Zeit und Geld.
Ein gutes Qualitätsszenario hilft, das wirklich Notwendige zu identifizieren.
4.SOLID-Prinzipien:
Single Responsibility Principle (SRP): Eine Einheit sollte nur einen Grund für eine Änderung haben.
Open-Close Principle (OCP): Eine Einheit sollte für Erweiterungen offen, aber für Änderungen geschlossen sein.
Liskov Substitution Principle (LSP): Subklassen sollten prinzipiell für ihre Elternklassen verwendbar sein.
Interface Segregation Principle (ISP): Kundenspezifische Schnittstellen statt großer universeller Schnittstellen.
Dependency Inversion Principle (DIP): Abhängigkeit von Abstraktionen/Schnittstellen statt von konkreten Implementierungen.
Diese Prinzipien helfen dabei, Softwarearchitekturen effizient und verständlich zu gestalten und die Wartbarkeit zu erhöhen.
