isaqb-cpsa-f/src/lz2/2_02.md

LZ 2-2: Softwarearchitekturen entwerfen

Blackboxes und Whiteboxes

Bausteine eines Systems können als Blackbox oder als Whitebox beschrieben werden:

• Blackboxes verstecken die innere Strukture eines Bausteins:
  • Name
  • Verantwortlichkeit/Funktion
  • Bereitgestellte und benötigte Schnittstellen
  • ggf. Qualitätseigenschaften, Einschränkungen, Risiken, Probleme
• Whiteboxes erweitern die Blackboxdarstellung um die innere Struktur
  • Überblick (Diagramm) der internen Struktur
  • Gründe für das innere Design
  • enthaltene Blackboxes

Das folgende Diagramm zeigt, wie eine Blackbox schrittweise in Whiteboxes zerlegt werden kann:

graph G {
    compound=true;
    node [
        fontname="Roboto, sans-serif"
        style=filled
        fillcolor="#42d4fb"
        shape=box
    ]
    graph [
        fontname="Roboto, sans-serif"
    ]
    Sys
    subgraph clusterSys {
        label = "Sys"
        {
            rank = same
            White
            Black
        }
        White -- Black;
    }
    subgraph clusterWhite {
        label = "White"
        a -- b;
        a -- c;
    }
    Sys -- White [lhead=clusterSys label="     " style="dashed"]
    White -- a [lhead=clusterWhite label="     " style="dashed"]
}

Abhängigkeiten, Trade-Offs und Risiken

Entscheidungen bezüglich der Architektur haben immer Konsequenzen und schließen Trade-Offs mit ein: TANSTAAFL (There ain't no such thing as a free lunch). Konkret stehen verschiedene Qualitätsattribute oft miteinander in Konflikt. Deshalb sollten Architektureintscheidungen explizit getroffen und dokumentiert werden.

Beispiele für typische Trade-Offs:

• gute runtime Performance (gut) wird erreicht durch Caching, parallele Prozesse, komplexe Strategien, was zu mehr Code und Komplexität führt (schlecht)
• gute Benutzerfreundlichkeit (gut) erfordert mehr Aufwand beim UI- und UX-Design, was wiederum mehr Kostet (schlecht)
• besserer Schutz der Privatsphäre (gut) benötigt mehr Auswahlmöglichkteiten, was das System komplizierter zu Benutzten macht (schlecht)

Beispiele für typische Risiken

• innovativer, schlecht getesteter Ansatz
• fehlende Erfahrung im Implementierungsteam
• fehlende Tests eine Kombination von Technologien
• die Lösung ist suboptimal, aber es gibt keine bessere Alternative
• die Lösung wurde von oben vorgegeben und ist bekannt dafür, Probleme zu verursachen