Ein praktischer Leitfaden zu UML mit Visual Paradigm und VPasCode

UML – die Unified Modeling Language – ist eine standardisierte Methode zur Beschreibung der Struktur und des Verhaltens eines Systems. Sie hilft Teams dabei, Anforderungen zu diskutieren, Software zu entwerfen und Entscheidungen zu dokumentieren. UML ist eine Modellierungssprache und keine Programmiersprache: Diagramme vermitteln ein Modell, garantieren aber nicht automatisch, dass die Implementierung damit übereinstimmt.

Dieser Leitfaden verwendet ein Online-Shopping-System als durchgehendes Beispiel. Er behandelt die wichtigsten UML-Diagrammtypen und einen Workflow mit Visual Paradigm für visuelle Modellierung und VPasCode für textbasierte Diagramme.

1. Beginnen Sie mit der Frage, die Ihr Diagramm beantworten soll

Bevor Sie zeichnen, entscheiden Sie, was der Leser verstehen muss:

• Was können Benutzer tun? Verwenden Sie ein Use-Case-Diagramm.

• Was passiert während eines Szenarios? Verwenden Sie ein Sequenz- oder Aktivitätsdiagramm.

• Welche Konzepte und Beziehungen bilden das Domänenmodell? Verwenden Sie ein Klassendiagramm.

• Wie wird Software in bereitstellbare oder austauschbare Teile unterteilt? Verwenden Sie Komponenten- und Bereitstellungsdiagramme.

• Wie verändert sich ein Objekt im Laufe der Zeit? Verwenden Sie ein Zustandsautomatendiagramm.

Ein Diagramm, das versucht, alle Fragen auf einmal zu beantworten, wird meist schwer lesbar. Bevorzugen Sie mehrere fokussierte Diagramme gegenüber einer überladenen Übersicht.

2. UML-Diagrammfamilien

UML 2.x umfasst 14 standardisierte Diagrammtypen, die üblicherweise in strukturelle und verhaltensbezogene Diagramme gruppiert werden. Interaktionsdiagramme sind eine Teilmenge der verhaltensbezogenen Diagramme.

Sie benötigen für ein Projekt selten alle 14 Diagrammtypen. Für viele Anwendungsdesigns bilden ein Use-Case-Diagramm, ein Klassendiagramm, ein Sequenzdiagramm, ein Aktivitätsdiagramm, ein Komponentendiagramm und ein Bereitstellungsdiagramm eine starke Ausgangsbasis.

3. Die nützlichsten Diagramme, mit einem E-Commerce-Beispiel

Use-Case-Diagramm: Ziele und Systemgrenze

Ein Use-Case-Diagramm beschreibt Benutzerziele, nicht Bildschirmlayouts oder internen Code. Für einen Online-Shop können Akteure beispielsweise seinKunde, Zahlungsanbieter, undLagerservice. Use Cases könnten seinProdukte durchsuchen, Bestellung aufgeben, Für die Bestellung bezahlen, undVersand verfolgen.

Verwenden Sie<<include>>, wenn ein Use Case immer ein anderes erforderliches Verhalten aufruft. Verwenden Sie<<extend>>, für optionales oder bedingtes Verhalten, das einen Basis-Use Case erweitert. Halten Sie die Systemgrenze klar, damit Leser das System von externen Akteuren unterscheiden können.

Aktivitätsdiagramm: Workflow und Entscheidungen

Aktivitätsdiagramme sind nützlich für Prozesse mit Verzweigungen oder parallelen Arbeiten. Ein Checkout-Flow könnte wie folgt aussehen:

1. Warenkorb und Adresse validieren.

2. Versandkosten und Steuern berechnen.

3. Eine ausstehende Bestellung erstellen.

4. Zahlungsautorisierung anfordern.

5. Wenn die Zahlung erfolgreich ist, die Bestellung bestätigen und die Erfüllung benachrichtigen.

6. Wenn die Zahlung fehlschlägt, den Fehler anzeigen und die Bestellung unbestätigt lassen.

Verwenden Sie Entscheidungs- und Zusammenführungsknoten für Verzweigungen, Fork- und Join-Knoten für parallele Arbeiten sowie Schwimmbahnen, wenn sich die Zuständigkeit zwischen Kunde, Geschäft und einem externen Anbieter ändert.

Sequenzdiagramm: ein Szenario über die Zeit

Sequenzdiagramme zeigen Teilnehmer und die von ihnen ausgetauschten Nachrichten. Sie sind besonders nützlich zur Klärung von Servicegrenzen, Aufrufreihenfolgen und Fehlerfällen. Fügen Sie alternative Pfade für Ergebnisse wie Zahlungsablehnung oder nicht verfügbare Lagerbestände hinzu.

@startuml
actor Kunde
participant "Storefront" as UI
participant "Bestelldienst" as Orders
participant "Lagerdienst" as Inventory
participant "Zahlungsanbieter" as Payment

Kunde -> UI: Checkout einreichen
UI -> Orders: placeOrder(cart, address)
Orders -> Inventory: reserve(items)

alt Artikel verfügbar
    Inventory --> Orders: Reservierung bestätigt
    Orders -> Payment: authorize(total)
    alt Zahlung genehmigt
        Payment --> Orders: genehmigt
        Orders --> UI: Bestellung bestätigt
        UI --> Kunde: Bestätigung anzeigen
    else Zahlung abgelehnt
        Payment --> Orders: abgelehnt
        Orders -> Inventory: release reservation
        Orders --> UI: Zahlung fehlgeschlagen
        UI --> Kunde: Zahlungsfehler anzeigen
    end
else Artikel nicht verfügbar
    Inventory --> Orders: Reservierung fehlgeschlagen
    Orders --> UI: Artikel nicht verfügbar
    UI --> Kunde: Verfügbarkeitsfehler anzeigen
end
@enduml

Dieses Beispiel verwendet die PlantUML-Syntax. Es ist eine verhaltensbezogene Skizze, keine Spezifikation für jeden Timeout, jede Wiederholung oder jede Sicherheitsregel. Fügen Sie diese Details hinzu, wenn sie für das Design relevant sind.

Klassendiagramm: Domänenstruktur

Klassendiagramme beschreiben Typen und ihre Beziehungen. Ein kleines Bestellmodell könnte Folgendes enthalten:

• Kunde

• Bestellung

• Bestellposition

• Produkt

• Zahlung

Zeigen Sie Attribute und Operationen an, wenn sie helfen, Verantwortlichkeiten zu erklären. Verwenden Sie Multiplizitäten, um Mengenregeln explizit zu machen: Zum Beispiel enthält eine Bestellung eine oder mehrere Bestellposition Objekte, während jede Bestellposition sich auf eine Produkt.

Häufige Beziehungsarten:

• Assoziation:eine allgemeine strukturelle Verbindung.

• Vererbung/Verallgemeinerung:eine Klasse ist eine spezialisierte Art einer anderen.

• Aggregation:eine Ganzen-Teil-Beziehung, bei der Teile unabhängig existieren können; sparsam verwenden.

• Komposition:eine starke Ganzen-Teil-Beziehung, bei der der Lebenszyklus eines Teils an den des Ganzen gebunden ist.

• Abhängigkeit:ein Element verwendet oder hängt von einem anderen ab.

Für ein Handelsmodell wird eine Bestellpositionoft als zu einer Bestellungmodelliert, während eine Produktunabhängig von einer bestimmten Bestellung existiert. Wählen Sie die Beziehung, die den tatsächlichen Lebenszyklus und die Regeln des Domänenmodells widerspiegelt.

Zustandsautomatendiagramm: Lebenszyklusregeln

Verwenden Sie einen Zustandsautomaten, wenn die zulässigen Übergänge eines Objekts von Bedeutung sind. Eine Bestellung kann durch folgende Zustände verlaufen:

Ausstehend → Zahlung ausstehend → Bestätigt → Erfüllt

Sie kann auch in den Zustand Storniert oder Zahlung fehlgeschlagen kennzeichnen Sie Übergänge mit auslösenden Ereignissen oder Bedingungen, wie z. B. zahlungGenehmigt oder [Verfügbarkeit]. Dieses Diagramm kann ungültige Übergänge aufdecken – beispielsweise, ob eine erfüllte Bestellung storniert werden kann.

Komponenten- und Bereitstellungsdiagramme: Software und Laufzeitumgebung

Ein Komponentendiagrammzeigt Softwareverantwortlichkeiten und Abhängigkeiten, wie einen Shop, einen Bestelldienst, einen Inventardienst und einen Zahlungsadapter. Es ist nützlich für die Diskussion von Modularität und Integrationsgrenzen.

Ein Bereitstellungsdiagrammzeigt, wo Software ausgeführt wird: beispielsweise Browser, Anwendungslaufzeitumgebung, Datenbank und externer Zahlungsanbieter. Verwenden Sie es, um die Laufzeittopologie zu diskutieren, nicht die detaillierte Netzwerkkonfiguration.

4. Modellieren Sie gut: praktische Konventionen

• Geben Sie jedem Diagramm einen klaren Titel und einen einzigen Zweck.

• Verwenden Sie die Domänensprache konsistent; vermeiden Sie, für dasselbe Konzept unterschiedliche Namen zu erfinden.

• Halten Sie Diagramme klein genug, um sie in ihrer beabsichtigten Größe lesen zu können.

• Enthalten Sie nur Details, die die Frage des Diagramms beantworten.

• Beschriften Sie wichtige Assoziationen und Nachrichtenflüsse.

• Fügen Sie Assoziationen Multiplizitäten hinzu, wenn Mengenregeln relevant sind.

• Verwenden Sie Notizen für Annahmen, Einschränkungen und ungelöste Entscheidungen.

• Halten Sie Namen und Verantwortlichkeiten über Diagramme hinweg konsistent.

• Unterscheiden Sie, was bestätigt ist, von dem, was vorgeschlagen oder noch unbekannt ist.

• Aktualisieren Sie Diagramme, wenn wichtige Designentscheidungen oder Verhaltensänderungen eintreten.

Betrachten Sie UML als Kommunikationshilfe. Ein Diagramm kann syntaktisch gültig sein und dennoch irreführend wirken, wenn seine Beschriftungen, Annahmen oder sein Geltungsbereich unklar sind.

5. Verwendung von Visual Paradigm

Visual Paradigm eignet sich für grafisches Modellieren: Erstellen und Anordnen von UML-Elementen auf einer Zeichenfläche, Organisieren verwandter Diagramme und Verfeinern eines Modells durch visuelle Bearbeitung. Die Produktunterlagen von Visual Paradigm beschreiben UML-Modellierung als Teil seiner Fähigkeiten zur visuellen Modellierung.

Ein praktischer Arbeitsablauf:

1. Erstellen Sie ein Projektfür das System oder den abgegrenzten Bereich, den Sie modellieren.

2. Beginnen Sie mit Anforderungen und Geltungsbereich.Identifizieren Sie Benutzer, externe Systeme und Hauptziele.

3. Erstellen Sie ein Anwendungsfalldiagrammum die Grenze und die wesentlichen Interaktionen festzulegen.

4. Verhalten-Diagramme hinzufügenfür die Szenarien, die das größte Risiko oder die größte Unklarheit aufweisen.

5. Erstellen Sie das Klassenmodellbasierend auf Domänenkonzepten und deren Regeln.

6. Komponenten- und Bereitstellungsansichten hinzufügenwenn die Architektur oder die Laufzeitplatzierung diskutiert werden muss.

7. Mit den Beteiligten überprüfen.Namen, Umfang, alternative Abläufe und Kardinalitäten prüfen.

8. Diagramme exportieren oder teilenin Formaten, die für Überprüfungen und Dokumentation geeignet sind.

9. Halten Sie das Modell aktuell.Weisen Sie einen Eigentümer zu und aktualisieren Sie die Diagramme, wenn sich Entscheidungen ändern.

Die genauen Menünamen und verfügbaren Funktionen können je nach Visual Paradigm-Edition und Version variieren. Verwenden Sie daher die aktuelle Benutzeroberflächen-Dokumentation des Produkts für editionspezifische Schritte.

6. Verwendung von VPasCode

VPasCode ist ein browserbasierter Diagramm-als-Code-Editor von Visual Paradigm. Die Produktinformationen beschreiben die Unterstützung für textbasierte Diagrammformate einschließlich PlantUML und Mermaid mit Live-Vorschau; es werden auch Exporte wie SVG und PNG beschrieben.

Ein einfacher Arbeitsablauf:

1. Öffnen Sie VPasCode und wählen Sie die Diagrammsprache, z. B. PlantUML.

2. Schreiben Sie ein Diagrammskript oder fügen Sie es ein.

3. Überprüfen Sie die gerenderte Vorschau während der Bearbeitung.

4. Verfeinern Sie Namen, Beziehungen, Layout und Fehlerpfade.

5. Exportieren Sie ein Bild für ein Dokument oder eine Überprüfung.

6. Bewahren Sie das Quellskript mit dem Projekt auf, wenn Sie eine textbasierte Aufzeichnung wünschen, die überprüft und versioniert werden kann.

VPasCode eignet sich gut für schnelle Entwürfe, Dokumentationsdiagramme und Teams, die eine textbasierte Bearbeitung bevorzugen. Das grafische Modell von Visual Paradigm ist nützlich, wenn Sie Modellelemente visuell manipulieren und Diagramme als Teil eines größeren Modellierungsprojekts organisieren möchten. Die beiden Ansätze können sich ergänzen, aber gehen Sie nicht davon aus, dass jedes Diagramm oder Modell zwischen ihnen mit perfekter Rundum-Treue übertragen wird; validieren Sie jede Konvertierung in Ihrem Arbeitsablauf.

7. Ein nützlicher End-to-End-Arbeitsablauf

Für eine Checkout-Funktion könnte eine leichte Modellierungssequenz wie folgt aussehen:

1. Anwendungsfall:definieren Sie, wer eine Bestellung aufgeben kann und welche externen Systeme beteiligt sind.

2. Aktivität:abbilden Sie den Checkout-Fluss und seine Entscheidungen.

3. Sequenz:Details zu Interaktionen für die Pfade Erfolg, Zahlungsfehler und Nichtverfügbarkeit des Lagerbestands.

4. Klasse:definiert die Konzepte Bestellung, Positionsposition, Produkt und Zahlung sowie deren Regeln.

5. Zustandsautomat:legt den gültigen Lebenszyklus der Bestellung fest.

6. Komponente:zeigt auf, welche Dienste für diese Verantwortlichkeiten zuständig sind.

7. Bereitstellung:dokumentiert die Laufzeitplatzierung, sofern Infrastrukturentscheidungen relevant sind.

Verwenden Sie Visual Paradigm, wenn das Team von einer canvasbasierten Modellierung und einem verwalteten visuellen Modell profitiert. Verwenden Sie VPasCode, wenn das Team Diagrammtext schnell schreiben und rendern möchte. Ein häufiger Ansatz besteht darin, ein Szenario in VPasCode zu entwerfen, es mit dem Team zu überprüfen und zu verfeinern und anschließend die Diagramme in dem Format zu pflegen, das am besten zum Dokumentations- und Änderungsprozess des Projekts passt.

8. Häufige Fallstricke

• Versuch, das gesamte System auf einmal zu diagrammieren:aufteilen nach Anliegen oder Szenario.

• Verwechseln von Aktivitäten mit Sequenzen:Aktivitäten betonen den Workflow; Sequenzen betonen Nachrichten über die Zeit.

• Überlastung von Klassendiagrammen:sich auf relevante Domänenkonzepte konzentrieren, nicht auf jedes Implementierungsdetail.

• Verwenden von include und extendals Dekoration:sie drücken spezifische Beziehungen zwischen Use Cases aus.

• Alternativpfade auslassen:Fehler und Stornierungen offenbaren oft wichtige Anforderungen.

• Das Bild als Spezifikation behandeln:wichtige Geschäftsregeln, Annahmen und Einschränkungen explizit dokumentieren.

• Diagramme veralten lassen:ein veraltetes Diagramm kann schlimmer sein als kein Diagramm, da Leser ihm vertrauen könnten.

Eine starke UML-Menge ist nicht die größte Menge. Sie ist die kleinste Menge an Diagrammen, die es den beabsichtigten Lesern ermöglicht, das System zu verstehen, Entscheidungen zu diskutieren und Lücken zu erkennen, bevor sie teuer werden.

Der Artikel ist auch in English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文 verfügbar.