Unified Modeling Language (UML): Ein umfassender Leitfaden zu Diagrammen, Konzepten und Visual Paradigm

Einführung

Unified Modeling Language (UML) ist eine standardisierte visuelle Modellierungssprache, die zur Analyse, Gestaltung, Dokumentation und Kommunikation der Struktur und des Verhaltens von Softwaresystemen verwendet wird. Sie bietet eine gemeinsame Menge an Symbolen und Diagrammtechniken, die Entwicklern, Architekten, Business Analysten, Projektmanagern und anderen Beteiligten helfen zu verstehen, wie ein System funktioniert.

UML ist keine Programmiersprache. Stattdessen fungiert sie als visuelle Blaupause für Software. Teams können UML-Diagramme verwenden, um Anforderungen zu beschreiben, die Systemarchitektur zu planen, Geschäftsprozesse zu modellieren, bestehende Anwendungen zu dokumentieren und zu erklären, wie verschiedene Teile eines Systems interagieren.

Beispielsweise kann eine E-Commerce-Anwendung Benutzer, Produkte, Warenkörbe, Bestellungen, Zahlungsdienste und Lieferdienste enthalten. UML-Diagramme können diese Elemente darstellen, ihre Beziehungen zeigen und veranschaulichen, was passiert, wenn ein Kunde eine Bestellung aufgibt.

UML wird als Industriestandard von der Object Management Group (OMG) verwaltet und wurde auch durch internationale Standards übernommen. Das moderne UML bezieht sich üblicherweise auf UML 2.x, das eine breite Sammlung von strukturellen und verhaltensbezogenen Diagrammen definiert. UML 2.2 definierte beispielsweise 14 Diagrammtypen, die gleichmäßig auf strukturelle und verhaltensbezogene Modellierung verteilt sind.

Was ist UML?

UML ist eine universelle Modellierungssprache für softwareintensive Systeme. Sie bietet eine standardisierte Notation zur Darstellung von:

• Systemkomponenten

• Klassen und Objekte

• Benutzeranforderungen

• Workflows und Geschäftsprozesse

• Zwischen Objekten ausgetauschte Nachrichten

• Systemzustände und Übergänge

• Software-Bereitstellungsumgebungen

• Abhängigkeiten zwischen Paketen und Komponenten

Der Zweck von UML ist es nicht, Quellcode zu ersetzen. Vielmehr hilft es Teams, ein System vor, während und nach der Implementierung zu durchdenken und zu kommunizieren.

Ein UML-Modell kann auf verschiedenen Detaillierungsgraden erstellt werden:

• Konzeptionelles Niveau:Beschreibt wesentliche Geschäftskonzepte ohne Implementierungsdetails.

• Analyse-Niveau:Untersucht Anforderungen, Verantwortlichkeiten und Systemverhalten.

• Design-Niveau:Definiert Klassen, Schnittstellen, Komponenten und Interaktionen.

• Implementierungsniveau:Stellt Details dar, die eng mit dem Quellcode und der Bereitstellungsinfrastruktur übereinstimmen.

Warum ist UML wichtig?

UMList nützlich, weil Softwaresysteme schwer verständlich werden können, wenn sie nur durch Quellcode oder umfangreiche schriftliche Dokumente beschrieben werden.

Vereinfacht komplexe Systeme

Diagramme bieten einen visuellen Überblick über große Systeme. Ein Klassendiagramm kann beispielsweise Dutzende von Klassen und ihre Beziehungen klarer darstellen als mehrere Seiten Text.

Verbessert die Kommunikation

Entwickler, Designer, Architekten, Tester, Business Analysten und Kunden können unterschiedliche technische Hintergründe haben. UML bietet ihnen eine gemeinsame visuelle Sprache zur Diskussion von Systemanforderungen und Designentscheidungen.

Unterstützt die Planung

Teams können Workflows, Klassen, Dienste und Bereitstellungsumgebungen modellieren, bevor Code geschrieben wird. Dies kann fehlende Anforderungen, doppelte Verantwortlichkeiten und architektonische Probleme in einem frühen Stadium aufdecken.

Hilft bei der Dokumentation von Software

UML-Diagramme können als langfristige technische Dokumentation dienen. Sie helfen neuen Entwicklern, ein bestehendes System zu verstehen, und unterstützen Wartungsteams, wenn Änderungen erforderlich sind.

Fördert ein besseres Design

Die Erstellung eines Modells zwingt ein Team, Fragen wie diese zu berücksichtigen:

• Welches Objekt ist für eine Aufgabe verantwortlich?

• Wie sind Komponenten verbunden?

• Was passiert, wenn eine Operation fehlschlägt?

• Welche Klassen hängen voneinander ab?

• Wie reagiert das System auf verschiedene Ereignisse?

Wichtige UML-Konzepte

Klasse

Eine Klasse ist eine Blaupause, die die von einer Gruppe von Objekten geteilten Attribute und Operationen definiert.

Zum Beispiel kann eine Bestellung-Klasse Folgendes enthalten:

• Attribute: orderId, orderDate, und Status

• Abläufe: calculateTotal() und cancelOrder()

Objekt

Ein Objekt ist eine tatsächliche Instanz einer Klasse. Wenn Bestellung eine Klasse ist, order1001 kann ein spezifisches Objekt sein, das aus dieser Klasse erstellt wurde.

Attribut

Ein Attribut stellt Daten dar, die von einer Klasse oder einem Objekt gehalten werden.

Beispiele umfassen:

• Name

• Preis

• E-Mail-Adresse

• Bestellstatus

Ablauf

Ein Ablauf stellt Verhalten dar, das von einer Klasse bereitgestellt wird. Abläufe werden in Programmiersprachen häufig als Methoden implementiert.

Beispiele umfassen:

• addItem()

• submitPayment()

• sendNotification()

Akteur

Ein Akteur ist eine externe Rolle, die mit einem System interagiert. Ein Akteur kann eine Person, ein anderes System oder ein externes Gerät sein.

Beispiele umfassen:

• Kunde

• Administrator

• Zahlungs-Gateway

• Lagersystem

Schnittstelle

Eine Schnittstelle definiert eine Menge von Operationen, die eine Klasse oder Komponente bereitstellen wird. Schnittstellen helfen, Abhängigkeiten zu reduzieren und austauschbare Implementierungen zu unterstützen.

Beziehung

Eine Beziehung beschreibt, wie UML-Elemente miteinander verbunden sind. Zu den gängigen Beziehungen zählen Assoziation, Abhängigkeit, Verallgemeinerung, Aggregation und Komposition.

Multiplizität

Die Multiplizität legt fest, wie viele Objekte an einer Beziehung teilnehmen können.

Häufige Beispiele sind:

• 1: Genau eines

• 0..1: Null oder eines

• *: Viele

• 1..*: Eins oder mehr

• 0..*: Null oder mehr

Ein Kunde kann beispielsweise null oder viele Bestellungen aufgeben. Dies kann wie folgt dargestellt werden:

Kunde 1 -------- 0..* Bestellung

UML-Diagramm-Kategorien

UML-Diagramme werden üblicherweise in zwei Hauptkategorien unterteilt:

1. Strukturdiagramme

2. Verhaltensdiagramme

Strukturdiagramme beschreiben, woraus ein System besteht. Verhaltensdiagramme beschreiben, was ein System tut und wie es sich im Laufe der Zeit verhält.

---

Struktur-UML-Diagramme

Strukturdiagramme stellen die statische Organisation eines Systems dar. Sie konzentrieren sich auf Klassen, Objekte, Komponenten, Pakete, Knoten und Beziehungen.

1. Klassendiagramm

Ein Klassendiagramm ist eines der am weitesten verbreiteten UML-Diagramme. Es stellt die statische Struktur eines Systems dar, indem es Folgendes zeigt:

• Klassen

• Attribute

• Operationen

• Schnittstellen

• Beziehungen

• Sichtbarkeit

• Multiplizität

Ein vereinfachtes Klassenmodell für den E-Commerce könnte wie folgt aussehen:

Kunde
- customerId
- name
+ placeOrder()

Bestellung
- orderId
- orderDate
- status
+ calculateTotal()

Produkt
- productId
- name
- price
+ updatePrice()

Mögliche Beziehungen umfassen:

Kunde 1 -------- 0..* Bestellung
Bestellung 1 -------- 1..* Produkt

In einem detaillierteren Entwurf kann eine Bestellposition Klasse zwischen Bestellung und Produkt.

Klassendiagramme sind nützlich für:

• Domänenmodellierung

• Objektorientiertes Design

• Datenbank- und Anwendungsplanung

• Identifizierung von Verantwortlichkeiten

• Erklärung von Vererbung und Schnittstellen

Ein Klassendiagramm beschreibt Klassen allgemein, während ein Objektdiagramm spezifische Instanzen dieser Klassen zeigt. Visual Paradigm beschreibt Klassendiagramme als Modelle von Klassen, Attributen, Operationen und Beziehungen innerhalb eines objektorientierten Systems.

2. Objektdiagramm

Ein Objektdiagramm zeigt einen Schnappschuss eines Systems zu einem bestimmten Zeitpunkt. Es stellt tatsächliche Objektinstanzen dar, nicht allgemeine Klassen.

Zum Beispiel:

customerA:Kunde
name = "Alex"

order1001:Bestellung
status = "Bezahlt"

Ein Objektdiagramm ist nützlich, wenn Sie Folgendes demonstrieren müssen:

• Der Zustand von Objekten zur Laufzeit

• Beispielhafte Datenbeziehungen

• Ein spezifisches Szenario

• Wie Instanzen von Klassen verbunden sind

Ein Klassendiagramm könnte zeigen, dass ein Kunde viele Bestellungen aufgeben kann. Ein Objektdiagramm könnte zeigen, dass KundeA besitzt derzeit Bestellung1001 und Bestellung1002.

3. Komponentendiagramm

Ein Komponentendiagramm zeigt die Organisation und Abhängigkeiten austauschbarer Softwarekomponenten.

Ein E-Commerce-Komponentendiagramm könnte Folgendes enthalten:

• Webanwendung

• Bestelldienst

• Produktdienst

• Zahlungsdienst

• Benachrichtigungsdienst

• Datenbank

Beispiel:

Webanwendung --> Bestelldienst
Bestelldienst --> Zahlungsdienst
Bestelldienst --> Benachrichtigungsdienst
Bestelldienst --> Bestell-Datenbank

Komponentendiagramme sind besonders nützlich für:

• Microservice-Architekturen

• Dienstorientierte Systeme

• API-Design

• Anwendungsarchitektur

• Darstellung von Dienstgrenzen und Abhängigkeiten

4. Bereitstellungsdiagramm

Ein Bereitstellungsdiagramm stellt die physische oder virtuelle Umgebung dar, in der Software ausgeführt wird.

Es kann Folgendes anzeigen:

• Client-Geräte

• Webserver

• Anwendungsserver

• Datenbankserver

• Cloud-Knoten

• Container

• Netzwerkverbindungen

• Bereitgestellte Software-Artefakte

Beispiel:

Kundengerät
       |
       v
Webserver
       |
       v
Anwendungsserver
       |
       v
Datenbankserver

Bereitstellungsdiagramme helfen Architekten zu verstehen, wo Software ausgeführt wird und wie Infrastrukturkomponenten kommunizieren.

5. Paketdiagramm

Ein Paketdiagramm organisiert zusammengehörige Modellelemente in Paketen und zeigt Abhängigkeiten zwischen diesen Paketen auf.

Ein Projekt kann Pakete wie folgende enthalten:

• Benutzer

• Katalog

• Bestellung

• Zahlung

• Benachrichtigung

Beispiel:

Bestellung --> Benutzer
Bestellung --> Katalog
Bestellung --> Zahlung
Zahlung --> Benachrichtigung

Paketdiagramme sind nützlich für:

• Organisieren großer Modelle

• Aufzeigen von Modulabhängigkeiten

• Identifizieren von Architekturebenen

• Vermeiden unerwünschter Kopplungen

6. Diagramm der zusammengesetzten Struktur

Ein Diagramm der zusammengesetzten Struktur zeigt die interne Struktur einer Klasse, eines Bausteins oder eines anderen strukturierten Klassifizierers.

Es kann Folgendes anzeigen:

• Interne Teile

• Ports

• Verbindungen

• Interne Zusammenarbeit

• Beziehungen zwischen internen Elementen

Zum Beispiel ein OrderController kann enthalten oder verbinden mit:

• OrderService

• OrderRepository

• PaymentService

• NotificationService

Im Gegensatz zu einem Komponentendiagramm, das sich allgemein auf Komponenten auf hoher Ebene konzentriert, konzentriert sich ein zusammengesetztes Strukturdigramm auf die interne Organisation eines Klassifizierers.

7. Profil-Diagramm

Ein Profil-Diagramm erweitert UML für einen bestimmten Bereich oder eine bestimmte Technologie. Es definiert spezialisierte Modellierungselemente durch Stereotype, markierte Werte und Einschränkungen.

Zum Beispiel kann ein Profil Stereotype wie folgende einführen:

<<entity>>
<<controller>>
<<service>>
<<microservice>>

Profil-Diagramme sind nützlich, wenn die Standard-UML-Notation angepasst werden muss für:

• Webanwendungen

• Unternehmensarchitektur

• Echtzeitsysteme

• Eingebettete Systeme

• Spezifische Programmierframeworks

• Branchenspezifische Modellierung

Das Profil-Diagramm wird oft von Einführungslisten ausgeschlossen, ist jedoch unter den Standard-UML-2.x-Diagrammtypen enthalten. UML 2.x wird allgemein als bestehend aus sieben strukturellen und sieben verhaltensbezogenen Diagrammtypen beschrieben.

---

Verhaltensbezogene UML-Diagramme

Verhaltensbezogene Diagramme beschreiben das dynamische Verhalten eines Systems. Sie zeigen Workflows, Ereignisse, Interaktionen, Zustandsänderungen und Reaktionen.

1. Use-Case-Diagramm

Ein Use-Case-Diagramm stellt die funktionalen Anforderungen eines Systems aus der Sicht externer Akteure dar.

Ein typisches Online-Shopping-System kann folgende Akteure enthalten:

• Kunde

• Administrator

• Zahlungs-Gateway

• Lieferdienst

Mögliche Anwendungsfälle umfassen:

• Konto registrieren

• Anmelden

• Produkte durchsuchen

• Produkt zum Warenkorb hinzufügen

• Bestellung aufgeben

• Zahlung leisten

• Lieferung verfolgen

• Produkte verwalten

Ein Anwendungsfalldiagramm bietet eine hochlevelige Übersicht darüber, was das System tut, ohne Implementierungsdetails zu beschreiben.

Wichtige Beziehungen umfassen:

• Assoziation:Verbindet einen Akteur mit einem Anwendungsfall.

• Einschließen:Zeigt Verhalten, das von einem anderen Anwendungsfall immer wiederverwendet wird.

• Erweitern:Zeigt optionales oder bedingtes Verhalten.

• Verallgemeinerung:Zeigt Spezialisierung zwischen Akteuren oder Anwendungsfällen.

Zum Beispiel, Bestellung aufgeben kann einschließen Zahlung leisten, während Rabatt anwenden kann erweitern Bestellung aufgeben.

2. Aktivitätsdiagramm

Ein Aktivitätsdiagramm stellt den Kontrollfluss in einem Prozess oder Anwendungsfall dar. Es ist nützlich zur Modellierung sequenzieller und paralleler Workflows.

Beispiel: Eine Bestellung aufgeben

Start
  |
Produkte durchsuchen
  |
Produkt zum Warenkorb hinzufügen
  |
Zur Kasse gehen
  |
Zahlungsdaten eingeben
  |
Zahlung erfolgreich?
 /              
Nein              Ja
|                |
Fehler anzeigen   Bestellung erstellen
                  |
              Bestätigung senden
                  |
                 Ende

Aktivitätsdiagramme können darstellen:

• Aktionen

• Entscheidungen

• Zusammenführungen

• Schleifen

• Parallele Aktivitäten

• Start- und Endknoten

• Schwimmbahnen für Zuständigkeiten

Schwimmbahnen können zeigen, welcher Akteur oder welche Systemkomponente jede Aktion ausführt. Zum Beispiel kann eine Bahn den Kunden, eine andere den Bestelldienst und eine weitere das Zahlungs-Gateway darstellen.

3. Sequenzdiagramm

Ein Sequenzdiagramm zeigt, wie Objekte oder Komponenten in einer zeitlich geordneten Abfolge kommunizieren.

Beispiel: Eine Bestellung aufgeben

Kunde -> WebApp: Bestellung einreichen
WebApp -> OrderService: createOrder()
OrderService -> PaymentService: authorizePayment()
PaymentService --> OrderService: paymentApproved
OrderService -> NotificationService: sendConfirmation()
OrderService --> WebApp: orderCreated
WebApp --> Kunde: Bestätigung anzeigen

Sequenzdiagramme enthalten:

• Teilnehmer

• Lebenslinien

• Nachrichten

• Aktivierungsstriche

• Rückmeldungen

• Bedingungen

• Schleifen

• Alternativen

• Parallele Interaktionen

Sie sind besonders nützlich zur Erklärung von API-Aufrufen, Dienstinteraktionen, Authentifizierungsflüssen und Fehlerbehandlungen.

4. Kommunikationsdiagramm

Ein Kommunikationsdiagramm, das in früheren UML-Versionen historisch als Kollaborationsdiagramm bezeichnet wurde, betont die Beziehungen zwischen Objekten und die zwischen ihnen ausgetauschten Nachrichten.

Anstatt sich primär auf eine vertikale Zeitachse wie ein Sequenzdiagramm zu konzentrieren, konzentriert es sich auf:

• Objekte

• Verbindungen zwischen Objekten

• Nummerierte Nachrichten

• Kollaborationsstruktur

Beispiel:

1: submitOrder()
Kunde ----------------> WebApp

2: createOrder()
WebApp ------------------> OrderService

3: authorizePayment()
OrderService -------------> PaymentService

Kommunikationsdiagramme sind nützlich, wenn die Struktur der Objektkollaboration wichtiger ist als die genaue visuelle Zeitachse.

5. Zustandsautomatendiagramm

Ein Zustandsautomatendiagramm zeigt, wie sich ein Objekt oder System als Reaktion auf Ereignisse in seinen Zustand ändert.

Eine Bestellung kann durch die folgenden Zustände verlaufen:

Neu -> Ausstehende Zahlung -> Bezahlt -> Versendet -> Geliefert
                  |
                  v
              Storniert

Ein Übergang kann mit einem Ereignis oder einer Bedingung beschriftet werden:

Ausstehende Zahlung -- paymentApproved --> Bezahlt
Ausstehende Zahlung -- paymentFailed --> Zahlung fehlgeschlagen

Zustandsautomatendiagramme sind nützlich für:

• Bestellungslebenszyklen

• Benutzerkontozustände

• Workflow-Status

• Geräteverhalten

• Netzwerkverbindungszustände

• Genehmigungsprozesse

Sie sind besonders wertvoll, wenn das Verhalten eines Objekts stark von seinem aktuellen Zustand abhängt.

6. Zeitdiagramm

Ein Zeitdiagramm veranschaulicht, wie sich der Zustand oder Wert eines oder mehrerer Elemente im Laufe der Zeit ändert.

Es wird häufig verwendet für:

• Echtzeitsysteme

• Eingebettete Systeme

• Kommunikationsprotokolle

• Hardware- und Software-Koordination

• Leistungsensitive Interaktionen

Ein Zeitdiagramm kann beispielsweise die Beziehung zwischen Folgendem zeigen:

• Ein Gerätesignal

• Ein Controller-Zustand

• Ein Sensorwert

• Eine Antwort über ein definiertes Zeitintervall

7. Interaktionsübersichtsdiagramm

Ein Interaktionsübersichtsdiagramm bietet eine hochstufige Übersicht von Interaktionen, indem es einen aktivitätsähnlichen Kontrollfluss mit Interaktionsdiagrammen kombiniert.

Es kann Folgendes zeigen:

• Die Reihenfolge der Hauptinteraktionen

• Entscheidungen zwischen Interaktionsfragmenten

• Parallele Interaktionspfade

• Verweise auf Sequenz- oder Kommunikationsdiagramme

Ein Interaktionsübersicht für eine Online-Bestellung könnte beispielsweise Folgendes verbinden:

1. Kundenauthentifizierung

2. Produktauswahl

3. Kassierinteraktion

4. Zahlungsautorisation

5. Auftragserfüllung

Dieses Diagramm ist nützlich, wenn ein Prozess zu komplex ist, um mit einem einzigen Sequenzdiagramm erklärt zu werden.

---

UML-Beziehungen

Das Verständnis von UML-Beziehungen ist für die Erstellung aussagekräftiger Diagramme unerlässlich.

Assoziation

Eine Assoziation stellt eine strukturelle Verbindung zwischen zwei Elementen dar.

Kunde -------- Bestellung

Dies zeigt an, dass Kunden und Bestellungen miteinander verbunden sind.

Gerichtete Assoziation

Eine gerichtete Assoziation zeigt die Navigierbarkeit in eine Richtung an.

Bestellung ------> Zahlung

Dies deutet darauf hin, dass eine Bestellung ein Zahlungsobjekt kennt oder verwendet, während das Umgekehrte möglicherweise nicht zutrifft.

Verallgemeinerung

Verallgemeinerung stellt Vererbung oder Spezialisierung dar.

       Benutzer
      /    
Kunde  Administrator

Hier, Kunde und Administrator sind spezialisierte Arten von Benutzer.

Abhängigkeit

Eine Abhängigkeit zeigt an, dass ein Element ein anderes vorübergehend verwendet oder sich auf dieses verlässt.

OrderService - - - -> PaymentGateway

Eine Änderung am Payment-Gateway kann den Order-Service beeinflussen.

Aggregation

Aggregation stellt eine Ganzz-Teil-Beziehung dar, bei der die Teile unabhängig voneinander existieren können.

Team ◇------ Spieler

Ein Spieler kann weiterhin existieren, auch wenn das Team aufgelöst wird.

Komposition

Komposition stellt eine starke Ganzz-Teil-Beziehung dar. Die Teile sind im Allgemeinen für ihren Lebenszyklus vom Ganzen abhängig.

Order ◆------ OrderItem

Ein OrderItemkann als Teil einer Bestellung betrachtet werden und hat möglicherweise außerhalb dieser Bestellung keine Bedeutung.

Realisierung

Realisierung zeigt an, dass eine Klasse oder Komponente eine Schnittstelle implementiert.

PaymentService - - -|> PaymentProcessor

Der PaymentService bietet das Verhalten, das durch die ” definiert wird"PaymentProcessor" Schnittstelle.

UML-Beispiel: Online-Shopping-System

Betrachten wir eine Online-Shopping-Anwendung.

Hauptakteure

• Kunde

• Administrator

• Zahlungs-Gateway

• Lieferdienst

Hauptanwendungsfälle

• Konto erstellen

• Produkte durchsuchen

• Artikel zum Warenkorb hinzufügen

• Bestellung aufgeben

• Zahlung leisten

• Lieferung verfolgen

• Lagerbestand verwalten

Mögliche Klassen

Kunde
Produkt
Warenkorb
Warenkorbartikel
Bestellung
Bestellposition
Zahlung
Versand

Mögliche Service-Komponenten

Benutzer-Service
Katalog-Service
Warenkorb-Service
Bestell-Service
Zahlungs-Service
Versand-Service
Benachrichtigungs-Service

Beispielinteraktion

Wenn ein Kunde eine Bestellung aufgibt:

1. Der Kunde übermittelt den Warenkorb.

2. Die Webanwendung sendet die Anfrage an den Bestell-Service.

3. Der Bestell-Service validiert die Artikel.

4. Der Zahlungs-Service autorisiert die Zahlung.

5. Die Bestellung wird gespeichert.

6. Der Versand-Service wird benachrichtigt.

7. Der Benachrichtigungsdienst sendet eine Bestätigungs-E-Mail.

Dieser einzelne Geschäftsprozess kann durch mehrere UML-Diagramme dargestellt werden:

• Anwendungsfalldiagramm: Zeigt, dass der Kunde eine Bestellung aufgeben kann.

• Aktivitätsdiagramm: Zeigt den Arbeitsablauf und Entscheidungspunkte.

• Sequenzdiagramm: Zeigt Nachrichten zwischen Diensten.

• Klassendiagramm: Zeigt Kunde, Bestellung, Produkt, und verwandte Klassen.

• Komponentendiagramm: Zeigt die beteiligten Dienste.

• Bereitstellungsdiagramm: Zeigt, wo diese Dienste ausgeführt werden.

Wie man das richtige UML-Diagramm wählt

Modellierungsziel	Empfohlenes UML-Diagramm
Klassen und ihre Beziehungen anzeigen	Klassendiagramm
Echte Objektinstanzen anzeigen	Objektdiagramm
Systemfunktionalität beschreiben	Anwendungsfalldiagramm
Geschäfts- oder Systemarbeitsablauf modellieren	Aktivitätsdiagramm
Im Laufe der Zeit ausgetauschte Nachrichten anzeigen	Sequenzdiagramm
Objektzusammenarbeit anzeigen	Kommunikationsdiagramm
Lebenszyklus und Zustandsänderungen anzeigen	Zustandsautomatendiagramm
Zeigt Softwaremodule oder -dienste	Komponentendiagramm
Zeigt die physische Bereitstellung	Bereitstellungsdiagramm
Organisiert Modellelemente	Paketdiagramm
Zeigt interne Teile eines Klassifizierers	Kompositionsstrukturdiagramm
Zeigt Änderungen im Zeitverlauf	Zeitdiagramm
Fasst mehrere Interaktionen zusammen	Interaktionsübersichtsdiagramm
Erweitert UML für einen spezialisierten Bereich	Profil-Diagramm

Eine gute Modellierungspraxis besteht darin, nur die Diagramme auszuwählen, die eine spezifische Frage beantworten. Die Erstellung aller möglichen UML-Diagramme kann die Dokumentation unnötig komplex machen.

UML und der Softwareentwicklungslebenszyklus

UML kann viele Phasen der Softwareentwicklung unterstützen.

Anforderungsanalyse

Anwendungsfalldiagramme helfen dabei, Akteure und Systemfunktionalitäten zu identifizieren. Aktivitätsdiagramme können Geschäftsprozesse und Workflows verdeutlichen.

Systemanalyse

Klassendiagramme können Domänenkonzepte darstellen. Sequenzdiagramme können Analysten dabei helfen zu verstehen, wie Anwendungsfälle erfüllt werden.

Architekturentwurf

Komponenten-, Paket- und Bereitstellungsdiagramme helfen dabei, die Struktur der Anwendung und ihrer Infrastruktur zu definieren.

Detaillierter Entwurf

Klassendiagramme, Sequenzdiagramme, Zustandsautomatendiagramme und Kompositionsstrukturdiagramme können Implementierungsaufgaben und Objektinteraktionen beschreiben.

Entwicklung

Entwickler können Modelle als Referenz verwenden, während sie Klassen, Dienste, APIs und Datenbankstrukturen implementieren.

Testen

Tester können Szenarien aus Anwendungsfällen, Aktivitätsdiagrammen und Sequenzdiagrammen ableiten. Zustandsautomatendiagramme können helfen, gültige und ungültige Zustandsübergänge zu identifizieren.

Wartung

UML-Diagramme liefern Dokumentation für bestehende Systeme und helfen Teams, die Auswirkungen vorgeschlagener Änderungen zu bewerten.

Erstellen von UML-Diagrammen mit Visual Paradigm

Visual Paradigm ist eine visuelle Modellierungs- und Software-Design-Plattform, die die Erstellung von UML-Diagrammen sowie andere Modellierungs- und Entwicklungstätigkeiten unterstützt. Zu den UML-Funktionen gehören Diagramme wie Klassen-, Sequenz-, Anwendungsfall-, Aktivitäts-, Komponenten-, Bereitstellungs-, Zustandsautomaten-, Paket-, Objekt- und zusammengesetzte Strukturdiagramme.

Starten eines UML-Projekts

Ein praktischer Workflow in Visual Paradigm ist:

1. Erstellen Sie ein neues Projekt.

2. Organisieren Sie das Modell in Pakete wie “Anforderungen, Domänenmodell, Dienste, und “Bereitstellung.

3. Erstellen Sie ein Anwendungsfalldiagramm, um die Systemfunktionalität festzuhalten.

4. Fügen Sie ein Aktivitäts- oder Sequenzdiagramm für wichtige Workflows hinzu.

5. Erstellen Sie ein Klassendiagramm für das Domänenmodell.

6. Fügen Sie Komponenten- und Bereitstellungsdiagramme für die Architektur hinzu.

7. Überprüfen Sie die Diagramme mit den Beteiligten.

8. Aktualisieren Sie das Modell, während sich das System weiterentwickelt.

9. Exportieren Sie Diagramme oder generieren Sie bei Bedarf Dokumentation.

Erstellen eines Klassendiagramms

Um ein Klassendiagramm zu erstellen:

1. Erstellen Sie ein neues Klassendiagramm.

2. Fügen Sie die Hauptdomänenklassen hinzu.

3. Fügen Sie Attribute und Operationen hinzu.

4. Verbinden Sie Klassen mit geeigneten Beziehungen.

5. Fügen Sie Multiplizitäten hinzu.

6. Geben Sie Vererbung und Schnittstellen dort an, wo erforderlich.

7. Ordnen Sie das Diagramm so an, dass verwandte Klassen leicht nachvollziehbar sind.

8. Validieren Sie das Modell anhand der Anforderungen.

Ein Beispiel: Ein Klassendiagramm für einen Online-Shop kann Folgendes enthalten: Kunde, Bestellung, Produkt, Zahlung, und Versand.

Erstellen eines Use-Case-Diagramms

Ein Use-Case-Diagramm kann erstellt werden durch:

1. Identifizieren externer Akteure.

2. Auflisten der Hauptfunktionen des Systems.

3. Hinzufügen einer Systemgrenze.

4. Platzieren der Use Cases innerhalb der Grenze.

5. Verbinden der Akteure mit den Use Cases, an denen sie teilnehmen.

6. Hinzufügen von Include- oder Extend-Beziehungen nur dann, wenn sie Wiederverwendung oder optionales Verhalten verdeutlichen.

Erstellen eines Sequenzdiagramms

Beim Erstellen eines Sequenzdiagramms:

1. Identifizieren Sie das zu modellierende Szenario.

2. Fügen Sie den Akteur oder die auslösende Komponente hinzu.

3. Fügen Sie die teilnehmenden Objekte oder Dienste hinzu.

4. Ordnen Sie sie von links nach rechts an.

5. Fügen Sie Nachrichten in chronologischer Reihenfolge hinzu.

6. Modellieren Sie Alternativen, Schleifen und Fehlerbedingungen.

7. Stellen Sie sicher, dass jede Nachricht einer realistischen Verantwortung entspricht.

Zusammenarbeit und Dokumentation

Visual Paradigm bietet visuelle Modellierungsfunktionen, Funktionen für die Teamzusammenarbeit, Dokumentationsunterstützung und Integrationen, die darauf abzielen, die Modellierung mit breiteren Softwareentwicklungsaktivitäten zu verbinden. Die Plattform unterstützt zudem die kollaborative Überprüfung und Kommentierung von Diagrammen.

Einige Editionen und Workflows können auch Funktionen wie Code-Engineering, Datenbankmodellierung, Modellorganisation, Diagramm-Export und Dokumentengenerierung bereitstellen. Diese Fähigkeiten sollten entsprechend den Anforderungen des Projekts ausgewählt werden, anstatt automatisch jedem Modell hinzugefügt zu werden.

Best Practices für effektives UML-Modellieren

Modellieren Sie mit einem Ziel

Jedes Diagramm sollte eine klare Frage beantworten. Zum Beispiel:

• Wie legt ein Kunde eine Bestellung auf?

• Welche Dienste hängen vom Zahlungsdienst ab?

• In welche Zustände kann eine Bestellung eintreten?

• Welche Klassen gehören zur Bestellungsdomäne?

Halten Sie Diagramme fokussiert

Vermeiden Sie es, das gesamte System in einem einzigen Diagramm abzubilden. Teilen Sie große Modelle in kleinere Ansichten für Anforderungen, Domänenstruktur, Verhalten, Architektur und Bereitstellung auf.

Verwenden Sie konsistente Namen

Verwenden Sie dieselben Namen über alle Diagramme hinweg. Wenn ein Diagramm eine Komponente “OrderService” nennt, sollte ein anderes sie nicht “OrderManager” nennen, es sei denn, es handelt sich tatsächlich um unterschiedliche Elemente.OrderService"“, sollte ein anderes sie nicht “OrderManager” nennen, es sei denn, es handelt sich tatsächlich um unterschiedliche Elemente.OrderManager"es sei denn, es handelt sich tatsächlich um unterschiedliche Elemente.

Wählen Sie das richtige Detaillierungslevel

Ein Diagramm, das für Stakeholder bestimmt ist, sollte normalerweise weniger technische Details enthalten als ein Implementierungsdiagramm. Fügen Sie keine Methodensignaturen, Datenbankfelder oder frameworkspezifischen Details hinzu, es sei denn, sie sind für das Zielpublikum relevant.

Vermeiden Sie unnötige Beziehungen

Das Hinzufügen jeder möglichen Abhängigkeit kann ein Diagramm schwer lesbar machen. Fügen Sie nur Beziehungen hinzu, die aussagekräftige Designinformationen vermitteln.

Zeigen Sie Multiplizität dort an, wo es wichtig ist

Multiplizität hilft, Geschäftsregeln und Datenbeziehungen zu verdeutlichen. Zum Beispiel ist die Darstellung, dass eine Bestellung ein oder mehrere Bestellpositionen enthält, aussagekräftiger als die einfache Verbindung der beiden Klassen.

Validieren Sie Diagramme gegen Anforderungen

Ein Modell ist nur nützlich, wenn es das System genau abbildet. Vergleichen Sie Diagramme mit Anforderungen, Testszenarien, Quellcode und dem Feedback von Stakeholdern.

Verwenden Sie Diagramme als lebendige Dokumentation

Aktualisieren Sie UML-Diagramme, wenn sich wesentliche Designentscheidungen ändern. Veraltete Diagramme können verwirrender sein als gar keine Diagramme.

Kombinieren Sie sich ergänzende Diagramme

Kein einzelnes UML-Diagramm erklärt jeden Aspekt eines Systems. Ein Klassendiagramm kann die Struktur zeigen, während ein Sequenzdiagramm erklärt, wie diese Struktur in einem bestimmten Szenario verhält.

Häufige Fehler, die vermieden werden sollten

• UML als Quellcode behandeln

• Erstellen von Diagrammen ohne einen spezifischen Zweck

• Konzeptuelle und Implementierungsdetails ohne Erklärung vermischen

• Verwendung von Vererbung, wo Komposition angemessener wäre

• Vermutung von Multiplizitäten bei wichtigen Beziehungen

• Hinzufügen von zu vielen Elementen zu einem Diagramm

• Verwendung falscher Include- und Extend-Beziehungen

• Fehlerhafte Modellierung von Fehler- und Alternativabläufen

• Erlauben, dass verschiedene Diagramme inkonsistente Namen verwenden

• Davon ausgehen, dass ein Diagramm korrekt ist, nur weil es visuell organisiert aussieht

UML 2.x und Diagrammanzahl

Frühe UML-Versionen beschrieben üblicherweise weniger Diagrammtypen. UML 2.x erweiterte die Sprache und führte zusätzliche Diagramme ein oder formalisierte sie, darunter:

• Kompositionsstrukturdiagramm

• Kommunikationsdiagramm

• Interaktionsübersichtsdiagramm

• Zeitdiagramm

Es benannte Zustandsautomatendiagramme in Zustandsmaschinendiagramme um. Eine gängige UML 2.x-Klassifizierung enthält 14 Diagramme: sieben strukturelle Diagramme und sieben verhaltensbezogene Diagramme. Die verhaltensbezogene Gruppe umfasst Use-Case-, Aktivitäts-, Zustandsmaschinen-, Sequenz-, Kommunikations-, Interaktionsübersichts- und Zeitdiagramme. Die strukturelle Gruppe umfasst Klassen-, Objekt-, Komponenten-, Kompositionsstruktur-, Bereitstellungs-, Paket- und Profil-Diagramme.

Daher sind Listen, die UML 2.x als nur 13 Diagramme beschreibend, unter der gängigen 14-Diagramm-Klassifizierung unvollständig.

Fazit

UML bietet eine praktische visuelle Sprache zum Verständnis, zur Gestaltung und zur Dokumentation von Softwaresystemen. Es hilft Teams, Anforderungen zu kommunizieren, Architekturen zu erkunden, Objektbeziehungen zu modellieren, Workflows zu beschreiben und Laufzeitverhalten zu erklären.

Die am häufigsten verwendeten Diagramme sind normalerweise:

• Use-Case-Diagramme für funktionale Anforderungen

• Klassendiagramme für statische Struktur

• Aktivitätsdiagramme für Workflows

• Sequenzdiagramme für Interaktionen

• Komponentendiagramme für Architektur

• Bereitstellungsdiagramme für die Infrastruktur

• Zustandsautomatendiagramme für das Lebenszyklusverhalten

Visual Paradigm kann diesen Modellierungsprozess unterstützen, indem es Werkzeuge für das Erstellen von UML-Diagrammen, das Organisieren von Modellen, die Zusammenarbeit mit Teammitgliedern und die Erstellung technischer Dokumentation. Der effektivste Ansatz besteht nicht darin, jedes UML-Diagramm wahllos einzusetzen, sondern die Diagramme auszuwählen, die wichtige Designfragen klären.

Wenn UML konsistent eingesetzt und stets mit dem tatsächlichen System abgeglichen wird, wird es mehr als eine Sammlung von Symbolen: Es wird zu einer gemeinsamen Designsprache, die geschäftliche Anforderungen, Softwarearchitektur, Implementierung, Testen und langfristige Wartung verbindet.

Der Artikel ist auch in English, Español and Français verfügbar.