Home

06 Quiz: Softwarearchitektur

quiz chapter-06 software-architecture 4+1-views nfr design-decisions trade-offs

Neu: Interaktives Quiz verfügbar!

Möchtest du deinen Fortschritt verfolgen und sofortiges Feedback erhalten? Probiere unsere neue interaktive Version mit Fortschrittsverfolgung, sofortigen Erklärungen und Punkteberechnung.

Interaktives Quiz starten →

Anleitung


Frage 1: Warum Architektur wichtig ist

Twitters “Fail Whale”-Fehlerseite (2008-2010) wurde ikonisch. Welches grundlegende Problem offenbarte sie über ihr System?

A) Ihre Entwickler waren nicht qualifiziert genug, um die Codebasis zu handhaben B) Ihre monolithische Architektur konnte nicht skalieren, um das explosive Benutzerwachstum zu bewältigen C) Sie hatten nicht genug Server D) Ihre Programmiersprache (Ruby) war zu langsam

Antwort anzeigen

Richtige Antwort: B

Twitters Fail Whale illustrierte, was passiert, wenn die Architektur eines Systems seinen Erfolg nicht unterstützen kann. Ihre monolithische Ruby on Rails-Anwendung konnte nicht skaliert werden, um das schnelle Wachstum der Benutzer zu bewältigen. Das Problem waren nicht die Entwickler, die Anzahl der Server oder Ruby selbst — es war die architektonische Entscheidung, alles als eine eng gekoppelte Anwendung zu bauen, die nicht unabhängig skaliert werden konnte.


Frage 2: Definition von Softwarearchitektur

Was beschreibt Softwarearchitektur laut der Vorlesung?

A) Die Programmiersprachen und Frameworks, die in einem Projekt verwendet werden B) Wie ein System als kommunizierende Komponenten organisiert ist und wie sie sich verhalten und interagieren C) Die Dokumentation und Kommentare in der Codebasis D) Das Design der Benutzeroberfläche und das visuelle Erscheinungsbild

Antwort anzeigen

Richtige Antwort: B

Softwarearchitektur beschreibt, wie ein System als eine Menge kommunizierender Komponenten organisiert ist und wie sich diese Komponenten verhalten und interagieren. Sie beantwortet Fragen wie: Wie werden Verantwortlichkeiten verteilt? Wie kommunizieren Komponenten? Wie wird das System bereitgestellt? Was passiert, wenn eine Komponente ausfällt?


Frage 3: Architektur als kreativer Prozess

Warum wird architektonisches Design als “kreativer Prozess” bezeichnet und nicht als formelhafter?

A) Weil Architekten tun können, was sie wollen, ohne Einschränkungen B) Weil Architektur Kompromisse beinhaltet, die von Systemtyp, Erfahrung und spezifischen Anforderungen abhängen C) Weil es keine etablierten Muster gibt, denen man folgen kann D) Weil für Architektur keine Dokumentation erforderlich ist

Antwort anzeigen

Richtige Antwort: B

Architektonisches Design ist grundlegend kreativ, weil es Kompromisse beinhaltet, die vom Typ des zu entwickelnden Systems, dem Hintergrund und der Erfahrung des Architekten und den spezifischen Anforderungen des Projekts abhängen. Anders als Algorithmen mit beweisbar optimalen Lösungen hat Architektur keine “richtige” Antwort — es geht darum, informierte Entscheidungen unter Berücksichtigung von Einschränkungen und Zielen zu treffen.


Frage 4: Zentrale Designfragen

Welche der folgenden ist KEINE der zentralen Fragen, die Architekten während des architektonischen Designs berücksichtigen müssen?

A) Gibt es ein generisches Architektur-Template, das wir verwenden können? B) Welche Programmiersprache sollten einzelne Entwickler bevorzugen? C) Wie werden Komponenten zerlegt? D) Welche Organisation liefert nicht-funktionale Anforderungen am besten?

Antwort anzeigen

Richtige Antwort: B

Die Vorlesung identifiziert 8 zentrale architektonische Fragen: Templates, Hardware-Verteilung, Muster, grundlegende Strukturierung, Komponenten-Zerlegung, Betriebskontrolle, NFR-Organisation und Dokumentation. Die Präferenzen einzelner Entwickler für Programmiersprachen sind persönliche Entscheidungen, keine architektonischen Entscheidungen. Architektur befasst sich mit systemweiten Belangen, nicht mit individuellen Coding-Präferenzen.


Frage 5: Performance-getriebene Architektur

Warum laufen Lenk- und Bremssysteme in der Architektur eines autonomen Fahrzeugs mit Regelkreisen bei 1 kHz (1000 Mal pro Sekunde)?

A) Weil schnellere Schleifen weniger Strom verbrauchen B) Weil Vorschriften genau diese Frequenz vorschreiben C) Weil eine reibungslose, sichere Steuerung eine schnelle Reaktion erfordert — ein Auto legt bei Autobahngeschwindigkeit in 100ms 2,8 Meter zurück D) Weil die Sensoren nur mit dieser Rate Daten erzeugen

Antwort anzeigen

Richtige Antwort: C

Bei 100 km/h legt ein Auto in 100ms ungefähr 2,8 Meter zurück. Für sicherheitskritische Funktionen wie Lenken und Bremsen muss das Steuerungssystem schnell genug reagieren, dass Verzögerungen nicht wahrnehmbar und sicher sind. Bei 1 kHz (1ms-Zyklen) legt das Auto nur 2,8 Zentimeter zwischen den Steuerungsaktionen zurück, was einen reibungslosen und sicheren Betrieb ermöglicht.


Frage 6: Sicherheitsgetriebene Architektur

Was ist das Prinzip der “Verteidigung in der Tiefe” (Defense in Depth) in der Sicherheitsarchitektur?

A) Die dickstmögliche Firewall am Netzwerkrand aufbauen B) Mehrere Sicherheitsschichten verwenden, sodass wenn eine Schicht versagt, andere das System weiterhin schützen C) Allen Sicherheitscode in einem einzigen, gut getesteten Modul halten D) Alle Daten unabhängig von ihrer Sensibilität verschlüsseln

Antwort anzeigen

Richtige Antwort: B

Verteidigung in der Tiefe verwendet eine Schichtenarchitektur, bei der jede Schicht zusätzliche Sicherheit bietet. Zum Beispiel: WAF (Web Application Firewall) → API Gateway → Geschäftslogik → Datenzugriff → Datenbank. Wenn ein Angreifer eine Schicht durchbricht, steht er vor weiteren Barrieren. Dies ist widerstandsfähiger als sich auf eine einzige Sicherheitsmaßnahme zu verlassen.


Frage 7: Verfügbarkeit und “Neunen” verstehen

Was bedeutet “99,99% Verfügbarkeit” (vier Neunen) in der Praxis?

A) Das System kann maximal 3,65 Tage pro Jahr ausfallen B) Das System kann maximal 8,76 Stunden pro Jahr ausfallen C) Das System kann maximal 52,6 Minuten pro Jahr ausfallen D) Das System darf niemals ausfallen

Antwort anzeigen

Richtige Antwort: C

99,99% Verfügbarkeit (“vier Neunen”) erlaubt etwa 52,6 Minuten Ausfallzeit pro Jahr. Vergleiche: 99% = 3,65 Tage, 99,9% = 8,76 Stunden, 99,999% = 5,26 Minuten. Jede zusätzliche “Neun” erfordert exponentiell ausgefeiltere Architektur — mehrere Rechenzentren, keine Single Points of Failure und Active-Active-Replikation.


Frage 8: Netflix’ hohe Verfügbarkeit

Welche architektonische Strategie verwendet Netflix, um hohe Verfügbarkeit zu erreichen?

A) Alle Services auf einem einzigen, extrem leistungsstarken Server betreiben B) Chaos Engineering (absichtliches Einschleusen von Fehlern) und zustandslose Services mit Multi-Region-Deployment C) Alle Daten im Speicher halten, um Datenbankausfälle zu vermeiden D) Nur eine Programmiersprache über alle Services hinweg verwenden

Antwort anzeigen

Richtige Antwort: B

Netflix erreicht 99,99% Verfügbarkeit durch mehrere Strategien: Deployment über mehrere AWS-Regionen in Active-Active-Konfiguration, Verwendung von Chaos Engineering (Chaos Monkey), um absichtlich Fehler einzuschleusen und Widerstandsfähigkeit zu verifizieren, und Aufbau zustandsloser Services, bei denen kein einzelner Service kritische Zustände hält. Das bedeutet, dass jede Instanz jede Anfrage bearbeiten kann, was Failover nahtlos macht.


Frage 9: Wartbarkeit und Trennung der Zuständigkeiten

Warum ist “Trennung der Zuständigkeiten” (Separation of Concerns) das Kernprinzip wartbarer Architektur?

A) Es macht den Code schneller B) Es ermöglicht, Änderungen zu isolieren, wodurch das Risiko unbeabsichtigter Nebeneffekte reduziert wird C) Es macht das Testen überflüssig D) Es erfordert weniger Entwickler zur Wartung des Systems

Antwort anzeigen

Richtige Antwort: B

Trennung der Zuständigkeiten bedeutet, verschiedene Verantwortlichkeiten zu isolieren, sodass Änderungen in einem Bereich nicht durch das gesamte System wellenartig wirken. Wenn du änderst, wie Daten gespeichert werden, solltest du nicht die UI ändern müssen. Wenn du eine Berechnung korrigierst, solltest du nicht die Authentifizierung kaputt machen. Diese Isolation macht das System einfacher zu verstehen, zu testen und zu ändern — kritisch, weil 80% der Softwarekosten Wartung sind.


Frage 10: Architektonische Kompromisse

Was wird laut Vorlesung typischerweise geopfert, wenn für Performance optimiert wird?

A) Sicherheit wird immer für Performance geopfert B) Modularität und Testbarkeit — eng gekoppelte, monolithische Komponenten sind schnell, aber schwer zu ändern C) Die Benutzererfahrung wird verschlechtert, um Geschwindigkeit zu verbessern D) Dokumentation wird unmöglich zu warten

Antwort anzeigen

Richtige Antwort: B

Performance-optimierte Architekturen opfern oft Modularität und Testbarkeit. Eng gekoppelte, monolithische Komponenten minimieren Kommunikationsaufwand und sind schnell, aber sie sind schwer zu verstehen, zu testen und zu ändern. Die Vorlesung betont, Performance-Optimierung nur dann zu wählen, wenn die Anforderungen es wirklich erfordern, nicht als Standard.


Frage 11: Das 4+1-Sichtenmodell

Welche Sicht im 4+1-Sichtenmodell zeigt, wie die Software in Pakete und Module für Entwicklungszwecke zerlegt ist?

A) Logische Sicht B) Prozesssicht C) Entwicklungssicht D) Physische Sicht

Antwort anzeigen

Richtige Antwort: C

Die Entwicklungssicht zeigt, wie Code in Pakete und Module organisiert ist. Sie beantwortet Fragen wie “Wo befindet sich diese Funktionalität in der Codebasis?” und hilft bei der Koordination der Entwicklung (“Anna arbeitet an services/, Ben arbeitet an presentation/”). Die Logische Sicht zeigt Domänenabstraktionen, die Prozesssicht zeigt Laufzeitverhalten, und die Physische Sicht zeigt Hardware-Deployment.


Frage 12: Stakeholder und Sichten

Laut dem 4+1-Sichtenmodell, wer sind die primären Stakeholder für die Physische Sicht?

A) Entwickler und Domänenexperten B) Performance-Ingenieure und Integratoren C) System-Ingenieure und Betriebsteams D) Programmierer und Projektmanager

Antwort anzeigen

Richtige Antwort: C

Jede Sicht im 4+1-Modell dient verschiedenen Stakeholdern: Logische Sicht → Entwickler, Domänenexperten. Prozesssicht → Performance-Ingenieure, Integratoren. Entwicklungssicht → Programmierer, Projektmanager. Physische Sicht → System-Ingenieure, Betrieb. Szenarien (+1) → alle Stakeholder. Die Physische Sicht befasst sich mit Deployment-Fragen wie Hardware, Netzwerke und Skalierung.


Bewertungsleitfaden


Wichtige Erkenntnisse zum Merken

  1. Architektur ermöglicht Skalierung - Agile Prozesse können erfolgreich sein, während die Architektur versagt (Twitters Fail Whale)
  2. Architektur = Komponenten + Interaktionen - Wie das System organisiert ist und wie Teile kommunizieren
  3. Kreativer Prozess, keine Formel - Architektur beinhaltet Kompromisse basierend auf Kontext, Erfahrung und Anforderungen
  4. NFRs treiben Architektur - Performance, Sicherheit, Verfügbarkeit und Wartbarkeit prägen strukturelle Entscheidungen
  5. Verteidigung in der Tiefe - Sicherheit durch mehrere Schichten, nicht einen einzigen Schutzpunkt
  6. Verfügbarkeit hat ihren Preis - Jede zusätzliche “Neun” erfordert exponentiell komplexere Architektur
  7. Chaos Engineering - Netflix testet Widerstandsfähigkeit, indem sie absichtlich Dinge in der Produktion kaputt machen
  8. Trennung der Zuständigkeiten - Verantwortlichkeiten isolieren, damit Änderungen nicht durch das System wellenartig wirken
  9. Performance vs. Wartbarkeit - Enge Kopplung ist schnell, aber schwer zu ändern; wähle weise
  10. 4+1-Sichten dienen verschiedenen Stakeholdern - Logisch, Prozess, Entwicklung, Physisch und Szenarien beantworten jeweils unterschiedliche Fragen

Merke: Softwarearchitektur ist die Brücke zwischen agiler Lieferung und nachhaltigen Systemen. Es geht nicht darum, die “beste” Architektur zu wählen — es geht darum, Kompromisse zu verstehen und informierte Entscheidungen zu treffen, die die spezifischen Anforderungen und Einschränkungen deines Systems unterstützen!

© 2026 Dominik Mueller   •  Powered by Soopr   •  Theme  Moonwalk