Context-Diagramme
Ein Context-Diagramm zeigt ein System als einzelne Box mit externen Akteuren und Schnittstellen, um Umfang und Abgrenzungen klar zu kommunizieren.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Falsche Abgrenzung führt zu fehlerhaften Annahmen in Architekturentscheidungen
- Stakeholder interpretieren Diagramme unterschiedlich ohne gemeinsame Definitionen
- Übermäßiges Vertrauen in statische Sicht verhindert Betrachtung dynamischer Aspekte
- Fokussiere auf Übersicht statt Implementierungsdetails
- Verwende konsistente Symbole und Legenden
- Versioniere Diagramme und halte sie aktuell
I/O & Ressourcen
- Systembeschreibung oder Produktvision
- Liste externer Akteure und Systeme
- Bekannte Schnittstellen und Protokolle
- Kontext-Diagramm als Kommunikationsartefakt
- Identifizierte Integrationspunkte und Verantwortlichkeiten
- Grundlage für weitere Architektur- und Testentscheidungen
Beschreibung
Context-Diagramme visualisieren ein System als eine einzige Box mit externen Akteuren und Schnittstellen, um Umfang und Abgrenzungen zu klären. Sie eignen sich für Stakeholder-Kommunikation, Anforderungsanalyse und Architekturüberblick. Sie helfen bei Risikoabschätzungen, Schnittstellendefinition und der Priorisierung technischer Aufgaben.
✔Vorteile
- Schnelles gemeinsames Verständnis von Systemgrenzen
- Erleichtert Risiko- und Integrationsanalysen
- Gute Grundlage für Kommunikation mit Stakeholdern
✖Limitationen
- Vereinfachung kann Details und interne Komplexität verbergen
- Nicht geeignet für Laufzeit-Metriken oder Verhalten
- Kann bei großen Systemen schnell unübersichtlich werden, wenn zu viele externe Akteure gezeigt werden
Trade-offs
Metriken
- Anzahl identifizierter Integrationspunkte
Zählt externe Schnittstellen, die im Diagramm sichtbar sind.
- Stakeholder-Verständnis (Umfrage)
Messergebnis aus kurzer Umfrage zur Verständlichkeit des Diagramms.
- Zeit bis zur Abstimmung
Dauer, bis Stakeholder einem Systemumfang zustimmen.
Beispiele & Implementierungen
Webshop-Grundstruktur
Context-Diagramm zeigt Webshop-System, Zahlungsanbieter, Versanddienstleister und Nutzerrollen.
Microservice-Integration
Diagramm grenzt einen Microservice gegenüber Auth-Service, Datenbank und externen APIs ab.
B2B-Partner-Schnittstellen
Visualisierung der Schnittstellen zu Geschäftspartnern für SLA- und Sicherheitsdiskussionen.
Implementierungsschritte
Sammeln von Systembeschreibung und externen Akteuren
Erstellen eines einfachen Context-Diagramms und Abstimmen mit Stakeholdern
Verfeinern der Schnittstellenbeschreibungen und Ableiten von Aufgaben
⚠️ Technische Schulden & Engpässe
Tech Debt
- Nicht aktualisierte Diagramme führen zu falschen Annahmen
- Fehlende Schnittstellendokumentation erhöht späteren Integrationsaufwand
- Unklare Verantwortlichkeiten bei Schnittstellen verwischen Ownership
Bekannte Engpässe
Beispiele für Missbrauch
- Verwendung als Ersatz für Sequenz- oder Komponentendiagramme
- Ein Diagramm für unterschiedliche Publikumstypen ohne Anpassung
- Darstellung aller internen Details statt Grenzen
Typische Fallen
- Annahmen über Datenflüsse ohne Validierung
- Vage Benennung externer Akteure
- Ignorieren von nicht-funktionalen Schnittstellenanforderungen
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Begrenzte Detailtiefe für Stakeholder-Dokumente
- • Erfordert aktuelle Informationen zu externen Systemen
- • Nicht geeignet zur Darstellung interner Ablauflogik