Seminar Gaphor: Architekturmodellierung mit C4

Im Mittelpunkt steht die strukturierte Darstellung von Softwaresystemen auf den C4-Ebenen Systemkontext, Container und Komponenten. Gaphor wird als gemeinsame Modellierungsumgebung eingesetzt, damit Architekturentscheidungen, Verantwortungsgrenzen und Abhängigkeiten nachvollziehbar dokumentiert werden. Der Schwerpunkt liegt nicht auf dekorativen Einzelbildern, sondern auf einem konsistenten Modell, aus dem zielgruppengerechte Sichten entstehen.

Inhaltsübersicht

• Zielsetzung
• Fachliche Schwerpunkte
• Praxisprojekt
• Qualitätskriterien
• Zielgruppe und Voraussetzungen

Zielsetzung

• C4-Abstraktionsebenen sicher unterscheiden und für konkrete Kommunikationsziele auswählen.
• Systeme, Personen, Container, Komponenten und Beziehungen konsistent im Modell strukturieren.
• Statische und dynamische Sichten miteinander verbinden und widerspruchsarme Architekturunterlagen erzeugen.
• Qualitätsregeln für Lesbarkeit, Benennung, Verantwortlichkeiten und Reviewfähigkeit anwenden.

Fachliche Schwerpunkte

1. Modellierungsauftrag und C4-Sichten festlegen

Zu Beginn wird der fachliche Zweck jeder Sicht geklärt. Dadurch bleibt die Modellierung auf Entscheidungen und Zielgruppen ausgerichtet.

1. Stakeholder, Fragestellungen und erwartete Architekturentscheidungen erfassen.
2. Systemgrenze, Umgebung und externe Abhängigkeiten als Ausgangspunkt definieren.
3. Benötigte C4-Ebenen auswählen und unnötige Detailstufen bewusst ausschließen.
4. Namenskonventionen, Legende und Verantwortlichkeiten für das Modell festlegen.

2. Systemkontext und Containerstruktur modellieren

Die äußere Einordnung wird schrittweise in ausführbare oder speichernde Bausteine verfeinert.

1. Personen und benachbarte Systeme mit klaren Rollen und Erwartungen erfassen.
2. Gerichtete Beziehungen mit fachlicher Bedeutung und verwendeter Schnittstellenart beschreiben.
3. Container nach Verantwortung, Technologiegrenze und Betriebsrolle abgrenzen.
4. Konsistenz zwischen Kontext- und Containersicht durch gemeinsame Modellelemente sichern.

3. Komponenten und interne Verantwortungen ausarbeiten

Für ausgewählte Container werden interne Bausteine modelliert, ohne die Sicht mit Implementierungsdetails zu überladen.

1. Architekturrelevante Komponenten aus Verantwortungen und Änderungsgrenzen ableiten.
2. Abhängigkeiten, angebotene Leistungen und konsumierte Dienste präzise benennen.
3. Wiederverwendung von Modellelementen statt mehrfacher, voneinander abweichender Kopien organisieren.
4. Kritische Kopplungen und fehlende Zuständigkeiten anhand des Modells prüfen.

4. Dynamische Abläufe und Architekturentscheidungen ergänzen

Statische Strukturen werden mit exemplarischen Interaktionen und begründeten Entscheidungen verbunden.

1. Geschäftskritische Szenarien und technische Durchstiche auswählen.
2. Interaktionen in zeitlicher Reihenfolge und auf passender Abstraktionsebene darstellen.
3. Sicherheits-, Betriebs- und Datenaspekte an den betroffenen Beziehungen verorten.
4. Entscheidungen, Annahmen und offene Punkte mit den relevanten Modellelementen verknüpfen.

5. Review und Veröffentlichung vorbereiten

Abschließend entsteht eine nachvollziehbare Architekturunterlage für unterschiedliche Adressaten.

1. Sichten auf Vollständigkeit, Lesbarkeit und widerspruchsfreie Benennung prüfen.
2. Technische Details aus Managementsichten entfernen und operative Details gezielt ergänzen.
3. Diagramme für Präsentation und Dokumentation einheitlich gestalten.
4. Reviewbefunde priorisieren und als konkrete Modelländerungen einarbeiten.

Praxisprojekt

Als durchgängiger Praxisfall wird die Architektur eines digitalen Fachverfahrens mit Webzugang, Integrationsdiensten, Datenhaltung und externen Partnern modelliert. Ausgehend von einer unvollständigen Kontextskizze entsteht ein konsistentes Modell mit Container- und Komponentensichten sowie einem dynamischen Szenario. Ein strukturiertes Architekturreview deckt unklare Verantwortungen, widersprüchliche Beziehungen und fehlende Betriebsaspekte auf.

Qualitätskriterien

• Jedes Diagramm beantwortet eine klar formulierte Fragestellung.
• Modellelemente werden in mehreren Sichten wiederverwendet, statt dupliziert.
• Beziehungen besitzen Richtung, Bedeutung und einen nachvollziehbaren fachlichen oder technischen Zweck.
• Detailtiefe, Begriffe und Legenden bleiben über alle Sichten hinweg konsistent.

Zielgruppe und Voraussetzungen

Zielgruppe: Softwarearchitektur, technische Projektleitung, Entwicklung, Produktverantwortung und IT-Beratung.

Voraussetzungen: Grundverständnis von Softwarearchitektur, verteilten Systemen und technischen Schnittstellen. Grundkenntnisse der Bedienung von Gaphor sind hilfreich, aber nicht zwingend.