Woche 8 ASR-Dokumentation

[mohid-1311]

Architekturentscheidungen für BitFlow - von ASR zur Struktur

In dieser Iteration haben wir uns systematisch damit beschäftigt, welche Anforderungen bei BitFlow wirklich architekturrelevant sind und wie wir unsere Struktur daran ausrichten. Ausgangspunkt waren die Architecture Significant Requirements (ASR), die wir mit Hilfe der 6-Part-Form beschrieben und anschließend in einem Utility-Tree priorisiert haben.
Architecture Significant Requirements (ASR)

1. Warum gerade diese Qualitätsattribute?

Aus der Aufgabenstellung und aus unserer eigenen Zielsetzung für BitFlow ergaben sich sechs zentrale Qualitätsattribute:

• Performance: BitFlow soll Schaltungen interaktiv und möglichst in Echtzeit simulieren.
• Usability: Der Editor ist das zentrale UI - Drag & Drop, Linienziehen und direkte Rückmeldung sind entscheidend.
• Reliability: Undo/Redo und Autosave sollen Datenverlust verhindern.
• Modifiability: Neue Bausteine, Custom Components und spätere Erweiterungen (z. B. zusätzliche Simulationsmodi) sollen ohne Re-Design möglich sein.
• Security: Projekte sind accountspezifisch; unberechtigte Zugriffe müssen verhindert werden.
• Availability: Die UI soll auch bei Fehlern im Simulationskern benutzbar bleiben.

Die Szenarien P1, U1, R1/R2, M1, S1/S2 und A1 konkretisieren diese Punkte - etwa Echtzeitreaktion im Editor, stabile Undo/Redo-Ketten oder Autosave bei Browserabsturz. Genau diese Szenarien haben wir als „Treiber“ für unsere Architektur verwendet.

2. Von den ASR zu Taktiken

Aus den Szenarien haben wir gezielt passende Taktiken abgeleitet:

• Performance: Eventgetriebene Simulation, Batch-Updates im UI, asynchrone Ausführung.
  Ziel: Änderungen in Netzwerken bis ca. 200 Gattern in ≤ 50 ms propagieren.

• Usability: Sofortiges visuelles Feedback (Drag & Drop, Wire-Preview), farbliche Signalzustände und ein eindeutiges SVG-Grid als Orientierung.

• Reliability: Validierung vor der Simulation, Snapshot-basiertes Undo/Redo sowie Autosave im lokalen Speicher.

• Modifiability: Trennung der Kernmodule (Separation of Concerns), abstrakte Interfaces (Simulation, Storage, Components) und eine erweiterbare Bausteinbibliothek.

• Security: Login/Session-Mechanismen und strikte Zugriffskontrolle auf Projekte.

Diese Taktiken sind direkt an die definierten ASR-Szenarien gebunden, z. B. Autosave bei R2 oder Isolation im WebWorker bei A1.

3. Warum diese Architekturstruktur?

Auf Basis der Taktiken haben wir uns für ein vierteiliges Architekturmodell entschieden:

• Core: Schaltung, Komponenten, Verbindungen, Simulation
• UI: React-Frontend mit SVG-Canvas, Signalviewer, Editor-Interaktionen
• Storage: Persistenzschicht (DB/LocalStorage/Import/Export)
• Library: Vordefinierte und benutzerdefinierte Bausteine

Diese Trennung folgt direkt aus Modifiability und Testability:

• Änderungen an der Simulation (z. B. eine neue Berechnungsstrategie) sollen möglich sein, ohne das UI anzupassen.
• Die UI kann erweitert werden (z. B. zusätzliche Panels), ohne dass die Simulation neu geschrieben wird.
• Die Bausteinbibliothek kann wachsen (Custom Components), ohne den Core zu verändern.
• Die Storage-Schicht bleibt abstrahiert - egal ob lokal oder serverseitig gespeichert wird.

Damit sind die zentralen ASR M1 (Modifiability) und R1/R2 (Reliability) direkt durch die Struktur abgedeckt.

4. Spezifische Entscheidungen und ihre Gründe

Undo/Redo als separater Service mit Zustandssnapshots

Wir speichern vollständige Schaltungszustände statt einzelner Operationen.
Grund: Höhere Robustheit und einfacheres Zurückspringen, egal wie viele Bearbeitungsschritte erfolgt sind (R1).

Compiler als eigenständiges Modul

Benutzerdefinierte Bausteine werden nicht „ad hoc“ verarbeitet, sondern erst validiert und in ausführbare Logik übersetzt.
Grund: Saubere Trennung von Definition und Ausführung sowie bessere Fehlermeldungen (M1, Testability).

Library als zentrale Registry

Alle Standard- und Custom-Komponenten laufen über eine gemeinsame Registry.
Grund: Einheitliche Schnittstelle für das UI, geringere Kopplung, einfaches Nachladen neuer Komponenten (M1).

Simulation über eine abstrahierte Schnittstelle

Die Simulation ist austauschbar (Strategy-ähnlich).
Grund: Unterstützt verschiedene Simulationsmodi (Echtzeit, Schrittweises Ausführen, Analyse), ohne das UI oder die Datenstrukturen anzupassen (Modifiability).

Lose Kopplung zwischen Core und UI

UI-Komponenten reagieren auf Änderungen im Core (Signaländerungen).
Grund: Sofortiges Feedback und hohe Responsiveness (Usability). Gleichzeitig bleibt die Architektur flexibel.

5. Entwurfsmuster im Kontext unserer Anforderungen

Die eingesetzten Muster sind unmittelbar aus den ASR abgeleitet:

• Factory: Erzeugt Bausteine aus der Library oder aus benutzerdefinierten Definitionen → Modifiability, Testability.
• Strategy: Für Simulation und Validierung → erfüllt M1 und verbessert P1.
• Composite: Custom-Komponenten bestehen aus Sub-Schaltungen → Wiederverwendung und Strukturierung.
• Observer: UI aktualisiert sich bei Signal- oder Schaltungsänderungen → Usability.
• Repository: Einheitliche Schnittstelle für Speichern/Laden von Projekten → Reliability und Security.

6. Fazit

Unsere Architekturentscheidungen ergeben sich direkt aus den zuvor formulierten ASR:

• Performance-Szenarien führen zu eventgetriebener, asynchroner Simulation.
• Usability-Szenarien führen zu Drag & Drop, Grid-basiertem Editor und sofortiger visueller Rückmeldung.
• Reliability- und Availability-Szenarien führen zu Undo/Redo, Autosave und isolierter Simulation.
• Modifiability-Szenarien führen zu klar getrennten Modulen (Core, UI, Storage, Library) und abstrakten Interfaces.
• Security-Szenarien führen zu einem Backend mit Authentifizierung und Zugriffskontrolle.

Durch diese Verbindung von ASR, Taktiken und Architektur ergibt sich eine Struktur, die erweiterbar, stabil und für Nutzer gut bedienbar ist.

[knoepsim]

Hallo,
einer unserern nächsten Schritte ist die Implementation einer SVG Karte mit Interatkionen.

Wie habt ihr die SVG-Interaktionen implementiert? Nutzt ihr spezielle Libraries oder Eigenentwicklungen für das Eventhandling und die Darstellung?
Interessant wäre, wie ihr State-Management und React-Komponentenstruktur gestaltet habt, um Aktualisierungen effizient nur an betroffene UI-Elemente zu senden.

Gruppe Caesars Gambit

[tinow04]

Hey,
eure Architektur ist nachvollziehbar. Einen Punkt hätte ich aber: Ich kenne mich nicht aus mit Performance-Anforderungen, deshalb hört sich eure Anforderung "200 Gattern in ≤ 50 ms" für mich sehr ambitioniert an. Vielleicht liege ich falsch, aber das wirkt auf mich so, als ob das durch das Rendern der SVGs usw. schwer umsetzbar ist. Finde aber gut, dass ihr euch ambitionierte Ziele setzt :)

[Nom Nom Now]