Grundlagen der Modellierung und UML

1. Was sind Modelle?

Ein Modell ist eine vollständige Beschreibung eines Systems aus einer bestimmten Perspektive und dient als eine vereinfachte Darstellung der Realität. Sie erstellen Modelle, weil komplexe Systeme insgesamt nicht vollständig verstanden werden können.

Vier zentrale Ziele der Modellierung:

1. Visualisieren ein System wie beabsichtigt.

2. Spezifizieren die Struktur oder das Verhalten eines Systems.

3. Ein Muster bereitstellen um die Systemkonstruktion zu leiten.

4. Dokumentieren Entwurfsentscheidungen.

Vier Prinzipien der Modellierung

• Das Modell, das Sie wählen, beeinflusst direkt, wie ein Problem angegangen wird.

• Jedes Modell kann auf unterschiedlichen Genauigkeitsstufen ausgedrückt werden.

• Die effektivsten Modelle bleiben eng mit der Realität verbunden.

• Kein einzelnes Modell ist ausreichend; komplexe Systeme erfordern mehrere Perspektiven.

Was ist UML?

Die Unified Modeling Language (UML) ist eine standardisierte grafische Sprache, die vom Object Management Group (OMG). Sie ist ausdrücklich keine Methodologie oder Vorgehensweise, sondern eine technische und grafische Spezifikation, die verwendet wird, um:

„Visualisieren, spezifizieren, erstellen und dokumentieren Sie die Artefakte eines softwareintensiven Systems.“

UML bietet ein universelles Bauplanformat sowohl für konzeptionelle Elemente (Geschäftsprozesse, Systemfunktionen) als auch für konkrete Implementierungen (Code-Anweisungen, Datenbankschemata, wiederverwendbare Komponenten).

Die vier Säulen von UML

Zweck	Beschreibung
Visualisieren	Stellt sicher, dass alle Beteiligten die gleiche Sprache sprechen. Explizite Modelle beseitigen Kommunikationsfehler und bringen Systemaspekte ans Licht, die ohne Modellierung unsichtbar bleiben.
Spezifizieren	Erstellt präzise, eindeutige und vollständige Systemdefinitionen.
Erstellen	Wird direkt auf Programmiersprachen (Java, C++, VB), RDBMS-Tabellen oder OODBMS-Speicher abgebildet. UnterstütztVorwärtsingenieurwesen (Modell → Code) und Rückwärtsingenieurwesen (Code → Modell).
Dokumentieren	Erfasst die Systemarchitektur, Anforderungen, Testpläne, Projekttermine und Release-Management.

---

2. Das UML-Diagramm-Ökosystem

UML 2.2 definiert 14 Diagrammtypen, eingeteilt in zwei Hauptgruppen:

1. Strukturelle Modelle (Statische Architektur)

2. Verhaltens- und Interaktionsmodelle (Dynamische Prozesse)

Verschiedene Diagramme dienen unterschiedlichen Perspektiven der Beteiligten:

• Anwendungsfalldarstellung: Funktionalität für Endbenutzer

• Logische Darstellung: Analysten und Designer (Systemstruktur)

• Prozessansicht: Software-Management (Leistungsfähigkeit, Skalierbarkeit, Durchsatz)

• Implementierungsansicht: Programmierer (konkrete Komponenten)

• Bereitstellungsansicht: Systemintegratoren (Topologie, Installation, Kommunikation)

---

3. Grundlegende UML-Diagramme erklärt

🔹 Use-Case-Diagramm

• Zweck: Modelliert die beabsichtigten Funktionen eines Systems und seine Umgebung. Wirkt als Vertrag zwischen Kunden und Entwicklern.

• Bestandteile: Akteure, Use-Cases und deren Beziehungen.

• Unterstützende Diagramme: Aktivitätsdiagramm (Ablauf innerhalb eines Use-Cases), Sequenzdiagramm (Objektkooperation zur Realisierung eines Use-Cases).

🔹 Aktivitätsdiagramm

• Zweck: Visualisiert den schrittweisen Ablauf von Ereignissen innerhalb eines Prozesses oder eines Use-Cases.

• Wichtige Elemente:

  • Aktion: Ein einzelner Schritt im Arbeitsablauf.

  • Fluss: Reihenfolge von Aktivitäten.

  • Entscheidung: Teilt den Fluss basierend auf einer Wächterbedingung[Bedingung].

  • Verzweigung: Beginnt parallele Threads.

  • Verbindung: Beendet parallele Threads (Synchronisation).

• Beispiel: Ablauf der Kursanmeldung mit Überprüfungen, Konfliktlösung und gleichzeitigen Aktualisierungen des Zeitplans.

🔹 Sequenzdiagramm

• Zweck: Zeigt, wie Objekte über Zeit interagieren, um einen Anwendungsfall zu erfüllen.

• Wichtige Elemente:

  • Lebenslinie: Senkrechte Linie, die das Bestehen eines Objekts über die Zeit zeigt.

  • Objekt/Klasse: Teilnehmer an der Interaktion.

  • Nachricht: Daten oder Methodenaufrufe, die zwischen Objekten ausgetauscht werden.

  • Ausführungszeitpunkt: Dünnes Rechteck, das anzeigt, wann ein Objekt aktiv verarbeitet wird.

  • Kombinierte Fragmente: opt (Optionale Ausführung), loop (Wiederholte Ausführung), ref (Verweist auf eine andere Interaktion).

🔹 Kommunikationsdiagramm

• Zweck: Alternative zu Sequenzdiagrammen. Betont strukturierte Beziehungen zwischen Objekten anstatt der zeitlichen Reihenfolge.

• Wichtige Elemente:Objekte, die miteinander verbunden sind, wobei nummerierte Nachrichten die Interaktionsreihenfolge entlang der Verbindungen anzeigen.

🔹 Komponentendiagramm

• Zweck:Zeigt die Laufzeitstruktur auf der Ebene der Softwarekomponenten.

• Wichtige Elemente:Modulare Systemteile, die hinter externen Schnittstellen verborgen sind. Enthält oft Klassen, um Implementierungsbeziehungen darzustellen.

🔹 Bereitstellungsdiagramm

• Zweck:Ordnet Softwareartefakte physischer Hardware zu.

• Wichtige Elemente:

  • Knoten: Stellt eine physische Maschine oder Ausführungsumgebung dar.

  • Artefakt: Stellt eine physische Datei oder bereitstellbare Einheit dar.

  • Eigenelement: Zeigt verschachtelte oder enthaltene Beziehungen an.

---

4. Beherrschen von Klassendiagrammen und Beziehungen

Klassendiagramme zeigen die statische Struktureines Systems. Sie bilden die Grundlage für Datenbeschreibungen (z. B. INSPIRE) und zeigen keine nichtzeitliche Informationen an.

Klassenanatomie

Fach	Beschreibung
Name	Bezeichner der Klasse (z. B. Flurstücksparzelle). Enthält oft Stereotypen wie «FeatureType».
Attribute	Benannte Eigenschaften mit Datentypen (z. B. - Adresse : char, - BaumAlter : int). Unterstützte Typen: Integer, LongInt, Double, Char, Datum, Boolean, String, Geometrie, usw.
Operationen	Klassenverhalten/Methoden. Format: + operationsName(Eingabetyp) : Rückgabetyp.

Beziehungstypen

Beziehung	Symbol	Bedeutung
Assoziation	───────	Allgemeiner Link zwischen Klassen. Enthält Rollennamen, Navigationspfeile und Kardinalität (1..*, 0..*, 1..2, usw.).
Generalisierung	─────▷	Vererbung. Die Unterklasse (Quelle) erbt alle Eigenschaften der Oberklasse (Ziel).
Aggregation	◇─────	„Teil-von“-Beziehung. Das Teil kann unabhängig existierendes Ganzen. (Hohles Diamant)
Zusammensetzung	◆─────	Starke „Teil-von“-Beziehung. Die Existenz des Teilshängt vollständigvom Ganzen ab. (Fülliges Diamant)

Beispiel aus den Trainingsmaterialien:

• Person → Holzfäller (Verallgemeinerung: Holzfäller erbtName, Geschlecht)

• Wald ◇─ Baum (Aggregation: Bäume können ohne einen bestimmten Wald existieren)

• Holzfäller ◆─ Mitarbeiter (Zusammensetzung: Mitarbeiter können in diesem Kontext nicht unabhängig von der Holzfäller-Entität existieren)

---

5. Praktische Anwendung: INSPIRE-Katastermodellierung

Das Trainingsmaterial verwendet dieINSPIRE-DatenSpezifikation für Kataster um die Anwendung von UML in der Praxis zu demonstrieren.

Übung 1: Modellierung einer Kernklasse

Aufgabe: Erstellen Sie die Grundstücksparzelle Klasse.
Lösungsstruktur:

«featureType» Grundstücksparzelle
- Adresse : Zeichen
- APN (Parzellennummer) : Zeichen
- Grenze : GM_Fläche
- Zentroid : GM_Punkt
- Beschriftung : Zeichen
- NationaleGrundstücksreferenz : Zeichenkette
- Flächenwert : doppelt (optional)
- Referenzpunkt : GM_Punkt (optional)

Hinweis: Mehrere gültige Lösungen existieren. Die Attribute sollten typische Merkmale der realen Welt widerspiegeln.

Übung 2: Modellieren von Beziehungen

Aufgabe: Verbinden Sie Grundstücksparzelle, Grundstücksbegrenzung, und Verwaltungszone.
Wichtige Modellierungsentscheidungen:

• Grundstücksparzelle ──── Grundstücksbegrenzung: Assoziation/Zusammensetzung (Grenze definiert die Parzelle; oft 1..1 oder 1..* Kardinalität). Rollen: +istGrenze / +hatGrenze.

• Flurstück ◇── Verwaltungszone: Aggregation/Assoziation. Die Existenz der Zone hängt nicht ab vom Flurstück. Das Flurstück gehört mehreren hierarchischen Zonen (1..* bis 0..*).

• Lektion: Wählen Sie Beziehungstypen basierend auf Lebenszyklusabhängigkeiten und Geschäftsregeln. Diagramme sollten die Realität widerspiegeln, nicht künstliche Beschränkungen erzwingen.

---

6. Best Practices für eine effektive UML-Modellierung

1. Verwenden Sie Diagramme strategisch: Diagramme visualisieren spezifische Perspektiven. Kein komplexes System kann aus einem einzigen Diagramm verstanden werden.

2. Elemente über mehrere Diagramme hinweg wiederverwenden: Eine einzelne Klasse kann in Klassendiagrammen, Zustandsmaschinen, Sequenzdiagrammen und Bereitstellungsdarstellungen erscheinen, wobei jeweils ein unterschiedlicher Aspekt hervorgehoben wird.

3. Passen Sie die Genauigkeit an die Zielgruppe an: Passen Sie die Komplexität des Diagramms an, je nachdem, ob der Betrachter ein Endbenutzer, Entwickler, Systemintegrator oder Projektmanager ist.

4. Überprüfen Sie anhand der Realität: Überprüfen Sie kontinuierlich, ob Modellelemente, Beziehungen und Kardinalitäten das tatsächliche Systemverhalten und die Domänenregeln widerspiegeln.

5. Nutzen Sie Werkzeugunterstützung: Verwenden Sie UML-konforme Werkzeuge (z. B. Sparx Systems) für Forward/Reverse Engineering, Konsistenzprüfungen und Codegenerierung.

---

Fazit

UML ist eine leistungsstarke, standardisierte Sprache zur Kommunikation, Gestaltung und Dokumentation von Software- und datenintensiven Systemen. Durch die Beherrschung der Kerndiagramme (insbesondere Klassendiagramm, Sequenzdiagramm, Aktivitätsdiagramm und Use-Case-Diagramm) sowie das Verständnis der Beziehungssemantik (Assoziation, Generalisierung, Aggregation, Komposition) können Fachleute präzise, an der Realität ausgerichtete Baupläne erstellen, die die Lücke zwischen konzeptuellen Anforderungen und technischer Umsetzung schließen.