Softwaretechnik
Lesson 5
Architektur
Was ist Architektur?
Es gibt eine Unzahl an Definitionen.
Ein erheblicher Teil davon redet von Komponenten, Struktur und Beziehungen.
Das ist aber nur ein Aspekt, wenn auch ein wichtiger.
Definitionen mit denen ich mich anfreunden kann
Architektur ist die Summe aller signifikaten Entscheidungen, die ein Projekt zum scheitern bringen, wenn sie falsch getroffen werden. ( P. Kruchten, "The Rational Unified Process: An Introduction")
Architektur ist das gemeinsame Verständnis des System Designs durch die Besten Entwickler. (Ron Jonson, auf RUP Mailing List)
D.h.
Architektur ist mehr als ein UML Diagram. Es ist auch mehr als ganz viele UML Diagramme.
Basis der Architektur sind immer Entscheidungen. Zur Architekturdokumentation gehört daher nicht nur wie etwas ist, sondern auch was die Alternativen waren und warum man sich für diese entschieden hat.
Architektur Ziele
Ziel bewusster Architekturentscheidungen ist es Nicht-Funktionale Anforderungen zu erfüllen. Also Dinge wie
-
Wartbarkeit
-
Performance
-
Skalierbarkeit
-
Durchsatz
-
Verfügbarkeit
-
Betreibbarkeit
- Flexibilität
Warum ist Flexibilität so entscheidend?
Beispiel Persistenz:
Was sind meine Anforderungen?
-
Konsistenz
-
Durchsatz
-
Skalierbarkeit (horizontal/vertikal)
-
Performance
-
Einzelne Datensätze via ID
-
Komplexe Strukturen
-
Komplexe Reports?
-
Viel/Wenig Schreiben/Lesen
-
Nur Neu Schreiben vs Viele Updates/Deletes
-
Brauche ich überhaupt Persistenz?
Big Design Up Front
Viele dieser Anforderungen werden erst nach einiger Zeit im Projekt klar.
Die frühe Entscheidung für eine bestimmte Lösung beeinflusst andere Entscheidungen.
D.h. Wir treffen eine Entscheidung von der wir statistisch belegen können, dass sie falsch ist, was dazu führt, dass wir in der Anwendung eine Komplexität bekommen, die niemand gebrauchen kann.
Last responsible Moment
Umgekehrt, die bewusste Entscheidung die Entscheidung noch nicht zu treffen, zwingt uns die Entscheidung zu entkoppeln. Dies erlaubt es die Entscheidung dann zu treffen, wenn wir sie unbedingt treffen müssen und die maximal mögliche Informationsmenge haben.
Dies maximiert die Chancen die richtige Entscheidung zu treffen.
Damit dies funktioniert muss die Anwendung änderbar sein. Dies ist die nächste wichtige Anforderungen an fast alle Software.
Änderbarkeit
Ist die Fähigkeit Änderungen an der Software durch zu führen, ohne andere Qualtitätskriterien negativ zu beeinflussen. Insbesonder ohne
-
überhöhte Kosten
-
überhöhten Zeitbedarf
-
ohne neue Bugs an anderen Stellen
Single Responsibility
-
Jede Komponente hat genau eine Aufgabe.
- Jede Komponente hat genau einen Grund geändert zu werden.
Keine Seiteneffekte
stellt sicher dass Änderungen sich nicht "ausbreiten"
Automatische Regressionstests
geben schnelles Feedback über entstehende Fehler
Clean Code Prinzipien
machen Code leichter verständlich, was es erlaubt schneller die richtige Stelle für eine Änderung zu identifizieren
Domain Driven Design
-
erleichtert die Kommunikation zwischen Stakeholdern, da alle die gleiche Sprache verwenden
-
erleichtert die Identifikation zu ändernder Code Stellen.
Betreibbarkeit
Die Fähigkeit Software zu installieren, zu starten und zu stoppen, Probleme zu erkennen und zu beheben (so lange die Ursache außerhalb der Software selbst liegen)
Logging
Jedes Problematische Ereignis wird ...
-
genau einmal geloggt
-
so gelogged, dass das technische Problem genau identifizierbar ist
-
so gelogged, dass die fachichen Auswirkungen klar erkennbar sind.
Andere Features
- Selbst Diagnose
- Rückwärtskompatible Schnittstellen
Verfügbarkeit
- Horizontale Skalierbarkeit
- Fail Fast
- Failure Containment
- Bad idea: uncontrolled retry
Aufgaben
Lesen:
Anschauen und verstehen:
Recherche:
Was ist ACID im Zusammenhang von Transaktionen?
Was sagt das CAP Theorem aus?
Was ist die Aussage von Amdahls Law?
Weiterführende Literatur
Softwaretechnik Lesson 5
By Jens Schauder
Softwaretechnik Lesson 5
- 1,661
