Seminar Gaphor: UML-Softwarearchitektur und Verhaltensmodellierung

Softwarearchitektur wird verständlich, wenn Struktur, Laufzeitverhalten und Bereitstellung aufeinander abgestimmt sind. Der Kurs entwickelt mit UML in Gaphor ein zusammenhängendes Architekturmodell. Pakete, Komponenten, Schnittstellen und Einsatzumgebungen werden mit Aktivitäten, Zuständen und Sequenzen verbunden, sodass Verantwortungen, Abhängigkeiten und kritische Szenarien prüfbar werden.

Inhaltsübersicht

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

Zielsetzung

• Architekturbausteine und Abhängigkeiten auf angemessener Abstraktionsebene modellieren.
• Komponenten und Schnittstellen aus Verantwortungen und Verträgen ableiten.
• Bereitstellung und Laufzeitumgebung nachvollziehbar darstellen.
• Aktivitäts-, Zustands- und Sequenzmodelle mit der statischen Architektur verbinden.
• Konsistenz und Architekturqualität in strukturierten Reviews prüfen.

Fachliche Schwerpunkte

1. Architekturauftrag und Sichtenmodell festlegen

Die Architekturmodellierung wird auf Stakeholderfragen und Entscheidungen ausgerichtet.

1. Stakeholder, Qualitätsziele und kritische Architekturfragen erfassen.
2. Systemgrenze, externe Abhängigkeiten und technische Randbedingungen festlegen.
3. Benötigte Struktur-, Verhaltens- und Bereitstellungssichten auswählen.
4. Paketstruktur und gemeinsame Begriffe für das Architekturmodell definieren.

2. Pakete und Abhängigkeiten strukturieren

Logische Verantwortungsbereiche und erlaubte Abhängigkeitsrichtungen werden sichtbar.

1. Pakete aus fachlichen und technischen Verantwortungen ableiten.
2. Abhängigkeiten nach Nutzung, Stabilität und Änderungsrichtung bewerten.
3. Zyklen und unerwünschte Kopplungen identifizieren.
4. Architekturregeln als prüfbare Vorgaben dokumentieren.

3. Komponenten und Schnittstellen modellieren

Bausteine werden über angebotene und benötigte Leistungen statt über Implementierungsdetails beschrieben.

1. Komponenten nach Verantwortung, Lebenszyklus und Austauschbarkeit abgrenzen.
2. Angebotene und benötigte Schnittstellen mit fachlich verständlichen Verträgen benennen.
3. Abhängigkeiten über Schnittstellen statt über diffuse Direktbeziehungen modellieren.
4. Fehlende Zuständigkeiten, überladene Komponenten und Schnittstellenbrüche prüfen.

4. Bereitstellung und Betriebsumgebung darstellen

Laufzeitknoten, Artefakte und Kommunikationswege werden für Betrieb und Sicherheit nachvollziehbar.

1. Relevante Ausführungsumgebungen, Geräte und Laufzeitknoten erfassen.
2. Artefakte oder bereitgestellte Komponenten den Knoten zuordnen.
3. Kommunikationspfade und Vertrauensgrenzen kenntlich machen.
4. Redundanz, Ausfallpunkte und Betriebsverantwortung im Modell prüfen.

5. Abläufe und Verantwortungen mit Aktivitäten modellieren

Architekturrelevante Prozesse werden mit Entscheidungen, Parallelität und Datenflüssen beschrieben.

1. Einen kritischen fachlichen oder technischen Ablauf auswählen.
2. Aktionen nach verantwortlichen Komponenten oder Rollen strukturieren.
3. Entscheidungs-, Parallel- und Ausnahmewege explizit modellieren.
4. Ablauf mit Schnittstellen und bereitgestellten Diensten abgleichen.

6. Komponentenverhalten mit Zuständen beschreiben

Lebenszyklen und Betriebsmodi werden als zulässige Zustandsübergänge präzisiert.

1. Stabile Zustände, Ereignisse und Übergangsbedingungen identifizieren.
2. Fehler-, Degradations- und Wiederanlaufzustände ergänzen.
3. Zustandsänderungen mit empfangenen oder gesendeten Nachrichten verknüpfen.
4. Unerreichbare oder widersprüchliche Zustände im Review untersuchen.

7. Interaktionen mit Sequenzen überprüfen

Kritische Szenarien werden als konkrete Zusammenarbeit der Architekturbausteine validiert.

1. Vorbedingungen, Auslöser und erwartetes Resultat eines Szenarios festlegen.
2. Lebenslinien aus bestehenden Komponenten und Schnittstellen ableiten.
3. Nachrichten, Alternativen, Fehlerpfade und zeitliche Abhängigkeiten modellieren.
4. Fehlende Schnittstellen oder widersprüchliche Verantwortungen in die Struktursicht zurückspielen.

8. Architekturmodell konsolidieren

Alle Sichten werden auf gemeinsame Begriffe, Verantwortungen und Entscheidungen geprüft.

1. Duplizierte Elemente beseitigen und gemeinsame Architekturbausteine wiederverwenden.
2. Abhängigkeiten zwischen Paket-, Komponenten-, Bereitstellungs- und Verhaltenssichten vergleichen.
3. Qualitätsrisiken und offene Architekturentscheidungen priorisieren.
4. Reviewbefunde einarbeiten und einen freigabefähigen Modellstand kennzeichnen.

Praxisprojekt

Die Architektur eines modularen Fachsystems wird von logischen Paketen über Komponenten und Schnittstellen bis zur Bereitstellung modelliert. Ein fachlicher Kernprozess, der Lebenszyklus einer zentralen Komponente und ein kritisches Sequenzszenario werden ergänzt. Das Abschlussreview prüft Kopplung, Schnittstellenkonsistenz, Ausfallpunkte und Übereinstimmung von Struktur und Verhalten.

Qualitätskriterien

• Architekturbausteine besitzen klare Verantwortungen und stabile Schnittstellen.
• Abhängigkeiten folgen nachvollziehbaren Richtungen und vermeiden unnötige Zyklen.
• Verhaltenssichten verwenden dieselben Komponenten und Nachrichtenbegriffe wie die Struktursichten.
• Bereitstellung, Vertrauensgrenzen und Betriebsverantwortung sind erkennbar.

Zielgruppe und Voraussetzungen

Zielgruppe: Softwarearchitektur, technische Entwicklung, DevOps-nahe Architekturarbeit, technische Projektleitung, Integration und Qualitätssicherung.

Voraussetzungen: UML-Grundkenntnisse und praktische Erfahrung mit Softwareentwicklung. Grundbedienung von Gaphor wird vorausgesetzt oder kann über das Grundlagenseminar erworben werden.