Minimum Effective UML: Ein praktischer Leitfaden zur Modellierung von Softwaresystemen

UML ist am nützlichsten, wenn es die Kommunikation und Entscheidungsfindung verbessert – nicht wenn es zu einer Dokumentationsübung wird. Ein Team benötigt selten alle UML-Diagrammtypen. In den meisten Projekten bieten sieben Diagrammtypen eine solide Grundlage:

1. Anwendungsfalldiagramme

2. Aktivitätsdiagramme

3. Sequenzdiagramme

4. Klassendiagramme

5. Komponentendiagramme

6. Bereitstellungsdiagramme

7. Zustandsautomatendiagramme

Zusammen beschreiben diese Diagramme das System aus komplementären Perspektiven:

• Ziele:Was Benutzer und externe Systeme benötigen

• Verhalten:Wie die Arbeit durch das System fließt

• Interaktion:Wie Objekte und Dienste zusammenarbeiten

• Struktur:Welche Entitäten und Beziehungen existieren

• Architektur:Wie die wichtigsten Softwareteile organisiert sind

• Betrieb:Wo das System ausgeführt wird

• Lebenszyklus:Wie wichtige Objekte im Laufe der Zeit verändert werden

Das Ziel ist nicht, für jedes mögliche Anliegen ein Diagramm zu erstellen. Das Ziel ist es, die kleinste kohärente Menge an Modellen zu erstellen, die die Fragen beantwortet, die die Beteiligten tatsächlich haben.

1. Was „Minimum Effective UML” bedeutet”

Minimum Effective UML ist eine Modellierungsstrategie, die auf vier Prinzipien basiert:

• Modellieren Sie für eine Entscheidung:Erstellen Sie ein Diagramm, weil es eine Anforderung, eine Designentscheidung, ein Risiko oder ein Implementierungsdetail verdeutlicht.

• Verwenden Sie die einfachste angemessene Notation:Vermeiden Sie unnötige Symbole, Dekorationen und Details.

• Stellen Sie die Rückverfolgbarkeit sicher:Verknüpfen Sie Anforderungen mit Verhalten, Struktur, Code, Tests und Bereitstellung, wo immer dies praktikabel ist.

• Halten Sie Diagramme verständlich:Ein Diagramm, das alles enthält, vermittelt oft nichts.

Ein nützliches Modell sollte helfen, Fragen wie diese zu beantworten:

• Wer interagiert mit dem System?

• Welche Fähigkeiten muss das System bereitstellen?

• Welche Schritte setzen einen Geschäftsprozess zusammen?

• Welches Objekt oder welcher Dienst ist für jede Aktion verantwortlich?

• Welche Daten und Domänenkonzepte müssen dargestellt werden?

• Wie sind Subsysteme unterteilt?

• Wo werden Anwendungen, Datenbanken und externe Dienste bereitgestellt?

• Wie durchläuft ein wichtiges Element seinen Lebenszyklus?

Wenn ein Diagramm nicht hilft, eine dieser Fragen zu beantworten, ist es möglicherweise nicht erforderlich.

2. Der Kern aus sieben Diagrammen

Diese Diagramme sind nicht unabhängig. Sie bilden eine Kette:

Zustandsautomaten-Diagramme durchlaufen diese Kette, indem sie den Lebenszyklus von Objekten beschreiben, die bedeutungsvolle Zustände aufweisen.

Beispielsweise kann eine Online-Bestellung wie folgt dargestellt werden:

• Anwendungsfall:Eine Bestellung aufgeben

• Aktivität:Warenkorb prüfen, Zahlung autorisieren, Lagerbestand reservieren, Bestellung bestätigen

• Sequenz:Die Benutzeroberfläche des Kunden ruft den Bestelldienst, den Zahlungsdienst und den Inventardienst auf

• Klasse: Bestellung, Bestellposition, Zahlung, und Produkt

• Komponente:Webanwendung, Bestelldienst, Zahlungsadapter, Inventardienst

• Bereitstellung:Browser, Anwendungscluster, Datenbank, Zahlungsanbieter

• Zustandsautomat:Entwurf → Ausstehende Zahlung → Bezahlt → Versendet → Geliefert

3. Anwendungsfall-Diagramme: Definition von Systemzielen

Ein Anwendungsfall-Diagramm stellt das System von außen dar. Es identifiziert die Akteure, die mit dem System interagieren, und die Ziele, die sie verfolgen.

3.1 Was ein Anwendungsfall-Diagramm enthält

Die Hauptelemente sind:

• Systemgrenze:Definiert, was sich innerhalb des zu modellierenden Systems befindet

• Akteure: Personen, Organisationen, Geräte oder externe Systeme

• Anwendungsfälle: Ziele oder Dienste, die das System bereitstellt

• Assoziationen: Verbindungen zwischen Akteuren und Anwendungsfällen

• Include-Beziehungen: Wiederverwendbares Verhalten, das von einem anderen Anwendungfall erforderlich ist

• Extend-Beziehungen: Optionales oder bedingtes Verhalten

Beispiel:

@startuml
left to right direction

actor Kunde
actor "Zahlungsanbieter" as PaymentProvider
actor "Lagersystem" as Warehouse

rectangle "Online-Shop" {
  usecase "Produkte durchsuchen" as UC1
  usecase "Bestellung aufgeben" as UC2
  usecase "Zahlung autorisieren" as UC3
  usecase "Bestellung erfüllen" as UC4
}

Kunde --> UC1
Kunde --> UC2
UC2 ..> UC3 : <<include>>
PaymentProvider --> UC3
Warehouse --> UC4
@enduml

3.2 Akteure korrekt identifizieren

Ein Akteur ist nicht zwangsläufig eine menschliche Rolle. Es ist alles Externe, das mit dem System interagiert.

Mögliche Akteure sind:

• Kunde

• Support-Mitarbeiter

• Administrator

• Zahlungs-Gateway

• Identitätsanbieter

• Lagerverwaltungssystem

• Geplanter Job

• Mobile Anwendung

• IoT-Gerät

Vermeiden Sie die Benennung von Akteuren nach internen Implementierungsdetails. Ein „REST-Controller“ ist normalerweise kein Akteur. Eine „Partner-Anwendung“ kann jedoch einer sein.

3.3 Benennen Sie Anwendungsfälle als Ziele

Gute Namen für Anwendungsfälle beschreiben Ergebnisse:

• Kostenerstattungsbericht einreichen

• Kaufantrag genehmigen

• Neuen Patienten registrieren

• Rechnung erstellen

• Passwort zurücksetzen

Schwache Namen beschreiben Implementierungsmechanismen:

• API aufrufen

• SQL-Abfrage ausführen

• Formular öffnen

• Controller aufrufen

Ein Anwendungsfall sollte Folgendes beantworten:

Welches sinnvolle Ergebnis möchte ein Akteur mit dem System erreichen?

3.4 Wann man include und extend verwendet

Verwenden Sie <<include>> wenn ein Verhalten immer als Teil eines anderen erforderlich ist.

Zum Beispiel:

• „Bestellung aufgeben“ enthält „Gesamtbetrag berechnen“

• „Konto registrieren“ enthält „E-Mail validieren“

Verwenden Sie <<extend>> wenn ein Verhalten optional oder bedingt ist.

Zum Beispiel:

• „Bestellung aufgeben“ kann durch „Werbeaktionrabatt anwenden“ erweitert werden

• „Anmelden“ kann durch „Multi-Faktor-Authentifizierung abschließen“ erweitert werden

Verwenden Sie diese Beziehungen nicht nur, um ein Diagramm anspruchsvoller wirken zu lassen. Oft ist ein kurzer schriftlicher Szenario- oder Aktivitätsdiagramm klarer.

3.5 Was Anwendungsfall-Diagramme nicht zeigen

Anwendungsfall-Diagramme sind nicht dazu gedacht, Folgendes zu beschreiben:

• Detaillierte Benutzeroberflächen-Layouts

• Exakte Implementierungsklassen

• Datenbanktabellen

• Nachrichtenreihenfolge

• Algorithmische Logik

• Infrastrukturtopologie

Sie definieren den Umfang und die Ziele. Andere Diagramme liefern die Details.

4. Aktivitätsdiagramme: Modellierung von Workflows und Prozessen

Aktivitätsdiagramme zeigen, wie die Arbeit voranschreitet. Sie sind besonders effektiv für Geschäftsprozesse, Workflows, Verzweigungslogik, parallele Arbeit und die Behandlung von Ausnahmen.

4.1 Kernelemente

Aktivitätsdiagramme verwenden häufig:

• Startknoten

• Aktionen

• Entscheidungsknoten

• Zusammenführungsknoten

• Verzweigungen und Zusammenführungen

• Schwimmbahnen

• Endknoten

• Bedingungen wie “[genehmigt] oder “[abgelehnt]

Beispiel:

@startuml
|Kunde|
start
:Bestellung einreichen;

|Bestelldienst|
:Bestellung validieren;

if (Bestellung gültig?) then (ja)
  :Gesamtbetrag berechnen;

  fork
    |Zahlungsdienst|
    :Zahlung autorisieren;
  fork again
    |Lagerdienst|
    :Lagerbestand reservieren;
  end fork

  |Bestelldienst|
  :Bestellung bestätigen;
  stop
else (nein)
  :Validierungsfehler zurückgeben;
  stop
endif
@enduml

4.2 Verwenden Sie Schwimmbahnen, um Verantwortlichkeiten darzustellen

Schwimmbahnen klären, welche Rolle, welches System oder welche Komponente jede Aktion ausführt.

Nützliche Bahnen können darstellen:

• Kunde

• Kundenservice-Mitarbeiter

• Bestelldienst

• Zahlungsanbieter

• Lager

• Automatisierter Zeitplaner

Schwimmbahnen sind besonders wertvoll, wenn ein Prozess Organisations- oder Systemgrenzen überschreitet.

4.3 Entscheidungen explizit modellieren

Eine Entscheidung sollte sinnvolle Bedingungen haben:

[Zahlung genehmigt]
[Zahlung abgelehnt]

Vermeiden Sie vage Bezeichnungen wie:

[ja]
[nein]

es sei denn, die Entscheidungsfrage ist sofort offensichtlich.

4.4 Parallelität zeigen, wenn es wichtig ist

Verzweigungen und Zusammenführungen sind nützlich, wenn Aktivitäten gleichzeitig stattfinden. Zum Beispiel, nachdem eine Bestellung validiert wurde:

• Die Zahlung kann autorisiert werden

• Der Lagerbestand kann reserviert werden

• Eine Betrugsprüfung kann durchgeführt werden

Modellieren Sie jedoch nur Parallelität, wenn sie Timing, Konsistenz, Fehlerbehandlung oder Systemdesign beeinflusst. Verwenden Sie parallele Zweige nicht nur, um das Diagramm aufwendiger zu gestalten.

4.5 Aktivitätsdiagramme und Anforderungen

Ein Aktivitätsdiagramm kann fehlende Anforderungen aufdecken. Zum Beispiel kann das Team bei der Modellierung eines Genehmigungsprozesses unbeantwortete Fragen entdecken:

• Was passiert, wenn ein Genehmiger nicht verfügbar ist?

• Kann ein Antrag abgelehnt und erneut eingereicht werden?

• Wie lange dauert die Eskalation?

• Können zwei Personen gleichzeitig genehmigen?

• Was passiert, wenn das nachgelagerte System nicht verfügbar ist?

Dies macht Aktivitätsdiagramme nützlich, bevor die Implementierung beginnt.

5. Sequenzdiagramme: Erklärung der Zusammenarbeit über die Zeit

Sequenzdiagramme zeigen, wie Teilnehmer Nachrichten in einer zeitlich geordneten Interaktion austauschen. Sie eignen sich ideal, um wichtige Szenarien im Detail zu beschreiben.

5.1 Hauptelemente

Ein Sequenzdiagramm umfasst typischerweise:

• Akteure

• Objekte oder Dienste

• Lebenslinien

• Nachrichten

• Rückmeldungen

• Aktivierungsstriche

• Bedingungen

• Schleifen

• Alternative Pfade

• Asynchrone Nachrichten

Beispiel:

@startuml
actor Kunde
boundary "Web-App" as Web
control "Bestelldienst" as Order
control "Zahlungsdienst" as Payment
database "Bestelldatenbank" as DB

Kunde -> Web : Bestellung einreichen
Web -> Order : createOrder(Warenkorb)

Order -> DB : save(Bestellung)
DB --> Order : Bestell-ID

Order -> Payment : autorisieren(Betrag)

alt Zahlung genehmigt
  Payment --> Order : genehmigt
  Order -> DB : updateStatus(GEZAHLT)
  Order --> Web : Bestätigung
  Web --> Kunde : Bestätigung anzeigen
else Zahlung abgelehnt
  Payment --> Order : abgelehnt
  Order -> DB : updateStatus(ZAHLUNG_FEHLGESCHLAGEN)
  Order --> Web : Zahlungsfehler
  Web --> Kunde : Fehler anzeigen
end
@enduml

5.2 Szenarien strategisch auswählen

Erstellen Sie kein Sequenzdiagramm für jeden Anwendungsfall. Beginnen Sie mit Szenarien, die:

• Geschäftskritisch

• Technisch riskant

• Integrationsintensiv

• Sicherheitskritisch

• Transaktional

• Schwer zu verstehen

• Die wahrscheinlich architektonische Probleme aufdecken

Typische Beispiele umfassen:

• Benutzerauthentifizierung

• Zahlungsverarbeitung

• Datei-Upload

• Bestellübermittlung

• Passwort-Zurücksetzung

• Ereignisveröffentlichung

• Fehlerwiederherstellung

• Hintergrundauftragsausführung

5.3 Unterscheidung zwischen synchronen und asynchronen Interaktionen

Ein synchroner Aufruf bedeutet, dass der Absender auf eine Antwort wartet. Eine asynchrone Nachricht ermöglicht es dem Absender, fortzufahren.

Diese Unterscheidung beeinflusst:

• Benutzererfahrung

• Transaktionsgrenzen

• Fehlerbehandlung

• Skalierbarkeit

• Wiederholungsverhalten

• Beobachtbarkeit

Verwenden Sie unterschiedliche Notationen konsistent und erklären Sie wichtiges asynchrones Verhalten in einer Notiz oder einem begleitenden Text.

5.4 Modellierung von Fehlerpfaden

Ein Sequenzdiagramm, das nur den erfolgreichen Pfad zeigt, kann erhebliche Designrisiken verbergen. Verwenden Sie alt, opt, und loopFragmente, um Folgendes darzustellen:

• Validierungsfehler

• Autorisierungsfehler

• Zeitüberschreitung

• Wiederholung

• Teilweiser Fehler

• Duplizierte Anfrage

• Dienstunverfügbarkeit

• Kompensation oder Rückgängigmachung

Zum Beispiel:

@startuml
Client -> API : Anfrage einreichen

API -> Service : Anfrage verarbeiten

alt Service antwortet
  Service --> API : Ergebnis
  API --> Client : Erfolg
else Timeout
  API -> Service : Anfrage wiederholen
  alt Wiederholung erfolgreich
    Service --> API : Ergebnis
    API --> Client : Erfolg
  else Wiederholung fehlschlägt
    API --> Client : Vorübergehender Fehler
  end
end
@enduml

5.5 Übermäßig detaillierte Sequenzdiagramme vermeiden

Ein Sequenzdiagramm wird schwer zu warten, wenn es jeden internen Methodenaufruf enthält. Konzentrieren Sie sich auf sinnvolle Verantwortlichkeiten und Grenzen:

• Benutzeroberfläche

• Anwendungsdienst

• Domänenobjekt

• Repository

• Externer Dienst

• Nachrichtenbroker

• Datenbank

Detaillierte Implementierungsdiagramme können beim Debuggen nützlich sein, sollten jedoch nicht zur primären architektonischen Dokumentation werden.

6. Klassendiagramme: Beschreibung von Struktur und Domänenkonzepten

Klassendiagramme zeigen die statische Struktur. Sie können entweder beschreiben:

• Ein konzeptuelles Domänenmodell

• Ein objektorientiertes Modell auf Design-Ebene

• Eine implementierungsorientierte Klassenstruktur

Dies sind unterschiedliche Abstraktionsebenen und sollten nicht sorglos vermischt werden.

6.1 Konzeptuelle versus implementierungsorientierte Klassendiagramme

Ein konzeptuelles Modell kann enthalten:

• Kunde

• Bestellung

• Produkt

• Zahlung

Ein Implementierungsmodell kann enthalten:

• OrderController

• OrderApplicationService

• OrderRepository

• PaymentGatewayAdapter

Beide sind gültig, beantworten aber unterschiedliche Fragen.

6.2 Kernbeziehungen

Zu den gängigen Beziehungen gehören:

• Assoziation

• Aggregation

• Komposition

• Verallgemeinerung

• Abhängigkeit

• Realisierung

Verwenden Sie Beziehungen sorgfältig. In vielen Fällen ist eine einfache Assoziation klarer als eine ausgefeilte Unterscheidung zwischen Aggregation und Komposition.

Beispiel:

@startuml
class Customer {
  +id: CustomerId
  +name: String
  +email: EmailAddress
}

class Order {
  +id: OrderId
  +status: OrderStatus
  +total(): Money
  +submit()
}

class OrderLine {
  +quantity: int
  +unitPrice: Money
  +lineTotal(): Money
}

class Product {
  +sku: String
  +name: String
}

Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "*" --> "1" Product : refers to
@enduml

6.3 Multiplizität ist wichtig

Multiplizität drückt Einschränkungen aus:

• 1 — genau eines

• 0..1 — optional

• * — viele

• 1..* — eines oder mehrere

Zum Beispiel:

Customer "1" -- "0..*" Order

bedeutet, dass jede Bestellung zu einem Kunden gehört, während ein Kunde null oder mehrere Bestellungen haben kann.

6.4 Modellieren Sie Verantwortlichkeiten, nicht nur Datenfelder

Ein Klassendiagramm sollte dabei helfen zu erklären, wo Verhalten hinzugehört. Ein Domänenobjekt mit sinnvollen Operationen ist oft aussagekräftiger als eine Menge von Klassen, die nur Getter und Setter enthalten.

Zum Beispiel:

Order.submit()
Order.cancel()
Order.calculateTotal()
Payment.authorize()

Die genauen Operationen hängen vom Designansatz ab, aber das Prinzip ist konsistent:

Legen Sie wichtige geschäftliche Verantwortlichkeiten in die Nähe der Konzepte, die sie besitzen.

6.5 Vermeiden Sie, Klassendiagramme in Datenbankschemata zu verwandeln

Ein Klassendiagramm ist nicht automatisch ein relationales Schema. Fügen Sie nicht jede Datenbankspalte hinzu, es sei denn, der Zweck ist speziell das Persistenzdesign.

Eine nützliche Unterscheidung ist:

• Domänenmodell:Geschäftskonzepte und -regeln

• Designmodell:Softwareklassen und -verantwortlichkeiten

• Datenmodell:Tabellen, Schlüssel, Indizes und Constraints

Diese können miteinander verbunden sein, sollten aber nicht verwechselt werden.

7. Komponentendiagramme: Zeigen architektonischer Grenzen

Komponentendiagramme beschreiben die wichtigsten austauschbaren oder bereitbaren Teile eines Systems und die Schnittstellen, über die sie interagieren.

Sie sind nützlich, um folgende Fragen zu beantworten:

• Was sind die wichtigsten Teilsysteme?

• Welche Komponente besitzt eine Verantwortlichkeit?

• Was bietet jede Komponente an?

• Was benötigt jede Komponente?

• Wo liegen Integrationsgrenzen?

• Welche Abhängigkeiten sind stabil oder riskant?

Beispiel:

@startuml
component "Web Application" as Web
component "Order Service" as Order
component "Payment Adapter" as Payment
component "Inventory Service" as Inventory
database "Order Database" as DB
cloud "External Payment Provider" as Provider

Web --> Order : REST API
Order --> Payment : Payment interface
Order --> Inventory : Inventory API
Order --> DB : Persistence
Payment --> Provider : Provider API
@enduml

7.1 Komponentendiagramme sind keine Paketdiagramme

Ein Paketdiagramm gruppiert Modellelemente, oft zur Organisation. Ein Komponentendiagramm beschreibt architektonische Einheiten, die Funktionalität bereitstellen und konsumieren.

Eine Komponente kann sein:

• Ein bereitstellbarer Dienst

• Eine Webanwendung

• Eine mobile Anwendung

• Eine Bibliothek

• Ein Nachrichtenbroker

• Eine externe Plattform

• Eine Datenbank

• Eine Integration von Drittanbietern

Das geeignete Niveau hängt von der Architektur ab.

7.2 Zeigen Sie Schnittstellen dort an, wo sie Verträge verdeutlichen

Schnittstellen machen Abhängigkeiten expliziter:

@startuml
interface PaymentGateway

component "Order Service" as Order
component "Payment Adapter" as Adapter

Order ..> PaymentGateway
Adapter - PaymentGateway
@enduml

Dies verdeutlicht, dass der Auftragsdienst von einer Abstraktion und nicht von einem bestimmten Anbieter abhängt.

7.3 Verwenden Sie Komponentendiagramme, um architektonische Entscheidungen zu unterstützen

Ein Komponentendiagramm wird wertvoller, wenn es mit kurzen Designnotizen kombiniert wird:

• Warum ist diese Grenze vorhanden?

• Wer besitzt die Daten?

• Ist die Interaktion synchron oder asynchron?

• Was passiert, wenn die Abhängigkeit fehlschlägt?

• Ist die Komponente unabhängig bereitstellbar?

• Welche Sicherheitsgrenze repräsentiert es?

• Welche Konsistenzgarantien bestehen?

Das Diagramm muss nicht jede Antwort enthalten, aber es sollte die Aufmerksamkeit auf die wichtigen lenken.

8. Bereitstellungsdiagramme: Verbindung von Software mit Infrastruktur

Bereitstellungsdiagramme zeigen die physische oder virtuelle Umgebung, in der Software-Artefakte ausgeführt werden.

Sie helfen bei der Beantwortung von:

• Wo läuft jede Anwendung?

• Welche Knoten kommunizieren miteinander?

• Wo befinden sich die Datenbanken?

• Welche Dienste sind von außen zugänglich?

• Welche Netzwerkgrenzen existieren?

• Wie ist das System verteilt?

• Welche Infrastruktur-Entscheidungen beeinflussen die Zuverlässigkeit oder Leistung?

Beispiel:

@startuml
node "Benutzergerät" als Device {
  artifact "Browser" als Browser
}

node "Cloud-Region" als Cloud {
  node "Web-Tier" als WebTier {
    artifact "Web-Anwendung" als WebApp
  }

  node "Anwendungstier" als AppTier {
    artifact "Bestelldienst" als OrderSvc
    artifact "Zahlungsadapter" als PaymentSvc
  }

  database "Bestelldatenbank" als DB
}

cloud "Zahlungsanbieter" als Provider

Browser --> WebApp : HTTPS
WebApp --> OrderSvc : HTTPS
OrderSvc --> DB : TLS
OrderSvc --> PaymentSvc
PaymentSvc --> Provider : HTTPS
@enduml

8.1 Knoten, Artefakte und Umgebungen unterscheiden

• Ein Knoten ist eine Ausführungsumgebung, wie ein Server, Container, Gerät, virtueller Computer oder verwaltete Plattform.

• Eine Artefakt ist eine bereitstellbare Softwareeinheit, wie eine Binärdatei, Container-Image, Paket oder Anwendung.

• Eine Umgebung kann Entwicklung, Test, Staging oder Produktion darstellen.

8.2 Betrieblich wichtige Details einbeziehen

Je nach Zweck können Bereitstellungsdiagramme Folgendes zeigen:

• Lastverteiler

• Firewalls

• Netzwerkzonen

• Container-Cluster

• Verfügbarkeitszonen

• Datenbanken und Replikate

• Caches

• Message-Broker

• Objektspeicher

• Externe Dienste

• Überwachungs- und Protokollierungssysteme

Fügen Sie keine Infrastrukturdetails hinzu, die keinen Einfluss auf die zu dokumentierende Entscheidung haben.

8.3 Verwenden Sie Bereitstellungsdiagramme für die Risikoanalyse

Die Bereitstellungsmodellierung kann Folgendes aufdecken:

• Ein Single Point of Failure

• Eine exponierte Datenbank

• Eine fehlende Netzwerkgrenze

• Übermäßiger regionenübergreifender Datenverkehr

• Eine Abhängigkeit ohne Failover-Strategie

• Unzureichende Trennung zwischen Umgebungen

• Eine unverschlüsselte Verbindung

• Eine unrealistische Skalierungsannahme

9. Zustandsautomatendiagramme: Modellierung von Lebenszyklen

Zustandsautomatendiagramme beschreiben, wie eine Entität auf Ereignisse reagiert, indem sie zwischen Zuständen wechselt.

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

Häufige Beispiele sind:

• Bestellung

• Zahlung

• Versand

• Support-Ticket

• Benutzerkonto

• Workflow-Anfrage

• Abonnement

• Dokument

• Gerät

• Auftragsausführung

Beispiel:

@startuml
[*] --> Entwurf

Entwurf --> Zahlung ausstehend : einreichen
Zahlung ausstehend --> Bezahlt : Zahlung genehmigt
Zahlung ausstehend --> Zahlung fehlgeschlagen : Zahlung abgelehnt
Zahlung fehlgeschlagen --> Zahlung ausstehend : Zahlung erneut versuchen
Bezahlt --> Bearbeitung : Erfüllung beginnen
Bearbeitung --> Versendet : Versand
Versendet --> Geliefert : Lieferung bestätigen
Bezahlt --> Storniert : stornieren
Bearbeitung --> Storniert : stornieren, falls erlaubt
Geliefert --> [*]
Storniert --> [*]
@enduml

9.1 Definieren Sie Zustände sorgfältig

Ein Zustand sollte eine sinnvolle Bedingung darstellen, nicht lediglich eine Aktion.

Gute Zustände:

• Genehmigung ausstehend

• Genehmigt

• Abgelehnt

• Zahlung fehlgeschlagen

• Versendet

Schwache Zustände:

• Auf Schaltfläche klicken

• Dienst aufrufen

• Methode ausführen

Aktionen sind Ereignisse oder Übergänge. Zustände sind Bedingungen, die bestehen bleiben.

9.2 Übergangsregeln einbeziehen

Ein Übergang kann Folgendes enthalten:

• Ereignis

• Wachbedingung

• Aktion

Zum Beispiel:

Genehmigung ausstehend -- genehmigen [Manager autorisiert] / genehmungAufzeichnen --> Genehmigt

Dies macht Geschäftsregeln sichtbar und testbar.

9.3 Verwenden Sie Zustandsautomaten, um Tests abzuleiten

Jeder Übergang schlägt Testfälle vor:

• Gültiger Übergang

• Ungültiger Übergang

• Wachstumsfehler

• Wiederholtes Ereignis

• Zeitüberschreitung

• Wiederholung

• Stornierung

• Wiederherstellung

Für einen Bestelllebenszyklus könnten Tests Folgendes überprüfen:

• Eine Entwurfsbestellung kann eingereicht werden

• Eine gelieferte Bestellung kann nicht storniert werden

• Ein Zahlungsfehler erlaubt eine Wiederholung

• Eine stornierte Bestellung kann nicht wieder in den bezahlten Status zurückkehren

10. Wie die sieben Diagramme zusammenarbeiten

Die Diagramme sollten ein konsistentes Modell bilden und nicht sieben voneinander getrennte Abbildungen.

Betrachten Sie die Fähigkeit „Reisekostenbericht einreichen“.

Anwendungsfall

• Mitarbeiter reicht Reisekostenbericht ein

• Manager genehmigt Reisekostenbericht

• Finanzbeamter bearbeitet Erstattung

Aktivität

• Kosten eingeben

• Belege anhängen

• Daten validieren

• Bericht einreichen

• An Manager weiterleiten

• Genehmigen oder ablehnen

• An Finanzabteilung senden

Sequenz

• Mitarbeiter-Schnittstelle ruft Kosten-Service auf

• Kosten-Service validiert Bericht

• Beleg-Service speichert Anhänge

• Workflow-Service weist einen Manager zu

• Benachrichtigungsservice sendet Warnungen

Klasse

• Mitarbeiter

• Kostenerstattungsbericht

• Kostenerstattungsposten

• Beleg

• Genehmigung

• Erstattung

Komponente

• Webanwendung

• Kostenerstattungsservice

• Belegspeicher

• Workflow-Service

• Benachrichtigungsservice

• Finanzintegration

Bereitstellung

• Browser

• Web-Ebene

• Anwendungscluster

• Objektspeicher

• Relationale Datenbank

• Finanzplattform

Zustandsautomat

Entwurf → Eingereicht → In Prüfung → Genehmigt → Erstattet
                         ↓
                      Abgelehnt

Jedes Diagramm fügt eine andere Perspektive hinzu, ohne alle anderen zu wiederholen.

11. Auswahl der zu erstellenden Diagramme

Ein praktischer Auswahlprozess besteht darin zu fragen, welche Art von Unsicherheit das Team hat.

Sie benötigen für jede Funktion nicht jedes Diagramm.

Eine leichte Entscheidungsregel

Erstellen Sie ein Diagramm, wenn mindestens eine der folgenden Bedingungen zutrifft:

• Mehrere Interessengruppen interpretieren die Anforderung unterschiedlich.

• Ein Prozess weist wichtige Verzweigungen oder paralleles Verhalten auf.

• Ein Szenario durchquert mehrere Systemgrenzen.

• Ein Domänenobjekt hat nicht-triviale Regeln.

• Eine Architekturentscheidung muss kommuniziert werden.

• Die Bereitstellungstopologie beeinflusst Zuverlässigkeit, Sicherheit oder Leistung.

• Lebenszyklusregeln sind im Fließtext schwer zu erklären.

• Das Diagramm wird für Implementierung, Überprüfung, Testen oder Betrieb wiederverwendet.

Vermeiden Sie die Erstellung eines Diagramms nur, weil eine Vorlage eines erwartet.

12. Detaillierungsgrade

Eine starke Modellierungspraxis verwendet mehrere Abstraktionsebenen.

Kontextebene

Zeigt das System und die wichtigsten externen Akteure oder Systeme.

Nützlich für:

• Umfang

• Kommunikation mit den Beteiligten

• Systemgrenzen

Container- oder Subsystemebene

Zeigt Anwendungen, Dienste, Datenbanken und wichtige Integrationen.

Nützlich für:

• Architektur

• Verantwortungsbereich

• Bereitstellungsplanung

Komponentenebene

Zeigt interne Architekturteile und Schnittstellen.

Nützlich für:

• Detaillierte Auslegung

• Abhängigkeitsprüfung

• Teamgrenzen

Codeebene

Zeigt Klassen, Methoden und Implementierungsabhängigkeiten.

Nützlich für:

• Entwicklerarbeit

• Refactoring

• Fehlersuche

Legen Sie nicht alle Ebenen in ein einziges Diagramm. Ein Kontextdiagramm sollte nicht jede Klasse enthalten, und ein Klassendiagramm sollte nicht versuchen, das gesamte Produktionsnetzwerk darzustellen.

13. Visual Paradigm UML

Visual Paradigm eignet sich gut für Teams, die grafische Modellierung und integrierte Dokumentation bevorzugen.

Es kann nützlich sein für:

• Interaktives Erstellen von UML-Diagrammen

• Verwalten eines Modell-Repositories

• Verknüpfen von Diagrammen mit Anforderungen

• Erstellen von Rückverfolgbarkeitsbeziehungen

• Erstellen von Dokumentation

• Zusammenarbeit über eine gemeinsame Modellierungsumgebung

• Erstellen oder Reverse-Engineering ausgewählter Artefakte

• Verwalten größerer Modelle mit Navigations- und Organisationsfunktionen

13.1 Stärken

Grafische UML-Tools sind besonders hilfreich, wenn:

• Analysten und Nicht-Entwickler müssen Diagramme bearbeiten

• Stakeholder bevorzugen visuelle Manipulation

• Ein Projekt erfordert eine formale Modellorganisation

• Nachverfolgbarkeit ist wichtig

• Das Team verwaltet ein zentrales Repository

• Dokumentation muss konsistent erzeugt werden

13.2 Empfohlene Verwendung

Verwenden Sie Visual Paradigm für Modellansichten, die von Folgendem profitieren:

• Interaktives Layout

• Umfangreiche Anmerkungen

• Diagrammübergreifende Navigation

• Formales Repository-Management

• Nachverfolgbarkeit

• Stakeholder-Workshops

Lassen Sie das Tool nicht die Modellierungsstrategie bestimmen. Entscheiden Sie zunächst:

• Welche Entscheidung das Diagramm unterstützt

• Wer es lesen wird

• Welches Detailniveau angemessen ist

• Wie es gewartet wird

• Ob das Modell mit Anforderungen oder Code verbunden werden muss

13.3 Repository-Disziplin

Ein gemeinsam genutztes Modell-Repository profitiert von denselben Praktiken wie die Versionskontrolle:

• Benennungskonventionen festlegen

• Verantwortung für wichtige Modellbereiche zuweisen

• Wesentliche Änderungen überprüfen

• Unnötige doppelte Diagramme vermeiden

• Veraltete Ansichten archivieren

• Den Zweck wichtiger Diagramme dokumentieren

• Modell-Elemente konsistent benennen

14. VPasCode und textbasiertes Modellieren

VPasCode unterstützt einen textorientierten Ansatz für das Modellieren innerhalb eines Visual-Paradigm-Ökosystems. Dieser Stil ist für Teams nützlich, die möchten, dass Diagramme sich eher wie Quellcode-Artefakte verhalten.

Textbasierte Diagramme können bieten:

• Kompatibilität mit Versionskontrollsystemen

• Code-Überprüfung

• Verzweigung und Zusammenführung

• Automatische Generierung

• Wiederholbare Builds

• Einfachere Batch-Aktualisierungen

• Nähe zu Quellcode und Dokumentation

Ein textbasiertes Modell könnte so aussehen:

actor Kunde
usecase "Bestellung aufgeben" als Bestellung
Kunde --> Bestellung

Die genaue Syntax hängt vom Werkzeug und vom Workflow ab, aber der größere Vorteil besteht darin, dass das Diagramm als bearbeitbarer Text und nicht nur als grafische Datei dargestellt wird.

14.1 Wann textbasiertes Modellieren gut funktioniert

Verwenden Sie textbasierte Diagramme, wenn:

• Entwickler pflegen die Modelle

• Diagramme ändern sich häufig

• Das Team verwendet Git oder ein anderes Versionskontrollsystem

• Prüfer möchten textliche Änderungen überprüfen

• Diagramme werden als Teil der Dokumentation generiert

• Mehrere Verzweigungen müssen sich unabhängig entwickeln

14.2 Mögliche Einschränkungen

Textbasiertes Modellieren kann weniger praktisch sein, wenn:

• Fachliche Stakeholder Diagramme direkt bearbeiten müssen

• Das Layout muss manuell optimiert werden

• Das Modell enthält umfangreiche visuelle Annotationen

• Das Team ist mit der Diagrammsyntax nicht vertraut

• Ein Repository erfordert eine ausgefeilte visuelle Navigation

Ein hybrider Ansatz ist oft effektiv: Verwenden Sie textbasierte Diagramme für eine codeorientierte Architektur und grafische Tools für die Analyse gegenüber den Stakeholdern.

15. PlantUML

PlantUML ist ein beliebter textbasierter Ansatz zur Diagrammerstellung, der UML- und verwandte Architekturdiagramme aus reinem Text generieren kann.

Beispiel:

@startuml
actor User
participant "Web App" as Web
participant "Application Service" as App
database Database

User -> Web : Request
Web -> App : Execute operation
App -> Database : Read/write data
Database --> App : Result
App --> Web : Response
Web --> User : Display result
@enduml

15.1 Vorteile

PlantUML ist wertvoll, weil Diagramme:

• neben dem Quellcode gespeichert werden können

• in Pull-Requests überprüft werden können

• automatisch generiert werden können

• mit einfachen Textbearbeitungen aktualisiert werden können

• in Markdown- oder Dokumentations-Pipelines einbezogen werden können

• umgebungsübergreifend konsistent erzeugt werden können

15.2 Organisation von PlantUML-Dateien

Eine praktische Repository-Struktur könnte wie folgt aussehen:

docs/
  architecture/
    system-context.puml
    components.puml
    deployment.puml
  workflows/
    place-order.puml
    refund-payment.puml
  domain/
    order-model.puml
    order-lifecycle.puml

Verwenden Sie beschreibende Namen und organisieren Sie Diagramme nach Zweck und nicht nach Werkzeug.

15.3 Generierte Bilder außerhalb der Quelle der Wahrheit halten

Wenn möglich:

• Speichern Sie .pumlDateien als die autoritative Quelle

• Generieren Sie PNG-, SVG- oder PDF-Dateien während der Dokumentations-Erstellung

• Vermeiden Sie das manuelle Bearbeiten generierter Bilder

• Stellen Sie sicher, dass Diagramme in der Automatisierung erfolgreich gerendert werden.

15.4 Verwenden Sie ein konsistentes Styling

Definieren Sie eine kleine visuelle Vokabular:

• Eine Farbe für externe Systeme

• Eine Farbe für interne Dienste

• Eine Farbe für Datenbanken

• Eine Notation für asynchrone Nachrichtenübermittlung

• Eine Benennungskonvention für Schnittstellen

• Eine Möglichkeit, Sicherheitsgrenzen darzustellen

Konsistenz ist wertvoller als Dekoration.

16. KI-gestütztes UML-Modellieren

KI kann das Modellieren beschleunigen, sollte jedoch eher als Modellierungsassistent denn als Autorität behandelt werden.

KI ist nützlich für:

• Umwandlung von Anforderungen in Kandidaten-Use-Cases

• Extrahieren von Akteuren und Zielen

• Vorschlagen von Aktivitätsflüssen

• Erstellen von PlantUML

• Vorschlagen von Sequenzteilnehmern

• Identifizieren von Domänenentitäten

• Erkennen fehlender alternativer Pfade

• Überprüfen der Diagrammkonsistenz

• Erstellen von Dokumentation aus Diagrammen

• Übersetzen zwischen grafischen und textuellen Darstellungen

• Generieren von Testideen aus Zustandsübergängen

16.1 Ein produktiver KI-Arbeitsablauf

Ein zuverlässiger Arbeitsablauf ist:

1. Stellen Sie die Anforderungen, Einschränkungen und den Systemkontext bereit.

2. Fordern Sie die KI auf, Annahmen und Unklarheiten zu identifizieren.

3. Erstellen Sie ein Kandidatendiagramm.

4. Überprüfen Sie das Diagramm anhand der tatsächlichen Anforderungen.

5. Vergleichen Sie es mit der Implementierung und der Infrastruktur.

6. Korrigieren Sie ungenaue oder erfundene Details.

7. Rendern Sie das Ergebnis visuell und prüfen Sie es.

8. Holen Sie sich ein Review von den relevanten Stakeholdern.

9. Speichern Sie das genehmigte Modell im Projekt-Repository.

10. Aktualisieren Sie es, wenn sich das System ändert.

16.2 Geben Sie der KI Anweisungen mit Einschränkungen

Schwaches Prompt:

Erstellen Sie ein UML-Diagramm für ein Bestellsystem.

Stärkeres Prompt:

Erstellen Sie ein PlantUML-Sequenzdiagramm für das Einreichen einer Bestellung.

Teilnehmer:
- Kunde
- Webanwendung
- Bestelldienst
- Zahlungsanbieter
- Inventardienst
- Bestell-Datenbank

Einschränkungen:
- Die Zahlung muss autorisiert werden, bevor die Bestellung bestätigt wird.
- Die Reservierung des Inventars kann parallel zur Zahlungsautorisation erfolgen.
- Eine abgelehnte Zahlung muss die Bestellung im Status „Zahlung fehlgeschlagen" belassen.
- Ein Zeitüberschreitung sollte einmal wiederholt werden.
- Zeigen Sie erfolgreiche, abgelehnte und Zeitüberschreitungs-Pfade an.
- Erfinden Sie keine Dienste, die hier nicht aufgeführt sind.

Je klarer die Einschränkungen formuliert sind, desto unwahrscheinlicher ist es, dass das Ergebnis eine nicht unterstützte Architektur enthält.

16.3 Fordern Sie von der KI Kritik an, nicht nur Generierung

Nützliche Review-Prompts umfassen:

• Welche Anforderungen sind nicht dargestellt?

• Welche Zweige fehlen?

• Widerspricht dieses Sequenzdiagramm der Zustandsmaschine?

• Sind einige Abhängigkeiten unerklärt?

• Sind Verantwortlichkeiten der falschen Komponente zugewiesen?

• Unterstützt das Bereitstellungsmodell die Verfügbarkeitsanforderung?

• Welche Übergänge sollten zu Testfällen werden?

• Welche Annahmen benötigen eine Bestätigung?

16.4 Häufige KI-Modellierungsfehler

Von der KI generierte Modelle können:

• Akteure oder Dienste erfinden

• Geschäftsrollen mit technischen Komponenten verwechseln

• Nicht unterstützte Datenbanktabellen hinzufügen

• Synchronkommunikation annehmen

• Fehlerpfade auslassen

• Die Eigentumsverhältnisse falsch darstellen

• UML-Beziehungen falsch verwenden

• Diagramme erstellen, die syntaktisch korrekt, aber semantisch falsch sind

• Abstraktionsebenen vermischen

• Vermutungen als Anforderungen behandeln

Das Schlüsselprinzip lautet:

KI kann schnell einen Entwurf erstellen, aber nur eine fachliche und technische Prüfung kann feststellen, ob der Entwurf zutrifft.

17. Validierung von UML gegen die Realität

Ein Diagramm ist nur dann wertvoll, wenn es mit dem System im Einklang bleibt.

17.1 Validierung gegen Anforderungen

Prüfen:

• Erscheint jede wichtige Anforderung in einem oder mehreren Modellen?

• Sind Akteure und Ziele korrekt?

• Sind Geschäftsregeln dargestellt?

• Sind Ausnahmen enthalten?

• Sind nichtfunktionale Anforderungen, wo zutreffend, berücksichtigt?

17.2 Validierung gegen die Implementierung

Prüfen:

• Entsprechen die Komponentengrenzen dem Code?

• Existieren die Sequenzteilnehmer?

• Sind Schnittstellen und Nachrichten korrekt?

• Sind Klassenverantwortlichkeiten realistisch?

• Sind asynchrone Operationen korrekt dargestellt?

• Werden Zustandsübergänge durch die Implementierung erzwungen?

17.3 Validierung gegen den Betrieb

Prüfen:

• Kann das Bereitstellungsdiagramm tatsächlich bereitgestellt werden?

• Sind Netzwerkkonnektivitäten realistisch?

• Sind externe Systeme dargestellt?

• Sind Datenbanken, Warteschlangen, Caches und Speicher, wo wichtig, enthalten?

• Sind Annahmen zu Ausfällen und Skalierung plausibel?

17.4 Validierung übergreifender Diagramme

Suchen Sie nach Widersprüchen wie:

• Ein Use Case benennt einen Akteur, der nicht im Systemkontext vorhanden ist

• Ein Sequenzdiagramm ruft eine Komponente auf, die in der Architektur nicht dargestellt ist

• Eine Zustandsmaschine erlaubt einen Übergang, der von den Geschäftsregeln nicht unterstützt wird

• Ein Klassendiagramm zeigt eine Eins-zu-Viele-Beziehung, während die Datenbank eine Eins-zu-Eins-Beziehung erzwingt

• Ein Bereitstellungsdiagramm lässt einen Dienst aus, der von den Sequenzdiagrammen erforderlich ist

• Ein Aktivitätsdiagramm zeigt parallele Operationen, während die Implementierung strikt sequenziell ist

Die konsistente Darstellung über Diagramme hinweg ist oft wichtiger als die künstlerische Qualität eines einzelnen Diagramms.

18. Rückverfolgbarkeit

Rückverfolgbarkeit verknüpft Modelle mit Anforderungen, Code, Tests und Betriebsartefakten.

Eine einfache Rückverfolgungskette könnte wie folgt aussehen:

Anforderung
  → Use Case
    → Aktivitätsablauf
      → Sequenzszenario
        → Komponente
          → Implementierung
            → Automatisierter Test

Für ein zustandsbehaftetes Domänenobjekt:

Geschäftsregel
  → Zustandsübergang
    → Guard-Bedingung
      → Testfall

Rückverfolgbarkeit erfordert nicht, jedes Element mit allen anderen zu verbinden. Konzentrieren Sie sich auf wertvolle Beziehungen:

• Sicherheitskritisches Verhalten

• Regulatorische Anforderungen

• Sicherheitskontrollen

• Wichtige Integrationen

• Komplexe Geschäftsregeln

• Architekturentscheidungen mit hohem Risiko

19. Versionskontrolle und Modellwartung

Ein Diagramm ist Dokumentation, und Dokumentation wird unzuverlässig, wenn sie nicht gepflegt wird.

19.1 Modelle in der Nähe der Arbeit speichern, die sie beschreiben

Mögliche Ansätze umfassen:

• UML-Dateien im Quellcode-Repository

• Repositories für Architektur-Dokumentation

• Ein gemeinsames Modellierungs-Repository

• Generierte Diagramme, die zusammen mit der technischen Dokumentation veröffentlicht werden

• Verknüpfungen zwischen Anforderungen und Modellelementen

19.2 Diagramme mit Code überprüfen

Bei Änderungen der Architektur oder des Verhaltens sollten Sie, wo praktikabel, die entsprechende Diagrammaktualisierung in dieselbe Änderung wie die Implementierung aufnehmen.

Prüfer können dann Folgendes bewerten:

• Ob die Implementierung dem beabsichtigten Design entspricht

• Ob die Designänderung vollständig ist

• Ob sich Abhängigkeiten geändert haben

• Ob neue Fehlerpfade existieren

• Ob Bereitstellungsfolgen berücksichtigt wurden

19.3 Weniger autoritative Diagramme bevorzugen

Mehrere widersprüchliche Diagramme sind schlechter als ein unvollständiges Diagramm. Legen Sie fest, welches Diagramm für jede Angelegenheit autoritativ ist.

Zum Beispiel:

• Komponentendiagramm: autoritativ für wesentliche Service-Grenzen

• Bereitstellungsdiagramm: autoritativ für die Produktions-Topologie

• Zustandsautomat: autoritativ für den Bestell-Lebenszyklus

• Klassendiagramm: autoritativ für Domänenbeziehungen

20. Häufige Modellierungsfehler

Alles modellieren

Mehr Diagramme führen nicht automatisch zu mehr Verständnis. Modellieren Sie die Risiken und Entscheidungen, die von Bedeutung sind.

Abstraktionsebenen vermischen

Legen Sie keine Geschäftsrollen, Programmierklassen, Cloud-Infrastruktur und Datenbankspalten in ein einziges undifferenziertes Diagramm.

Vage Namen verwenden

Namen wie „Daten verarbeiten“ oder „Anfrage bearbeiten“ verschleiern die Absicht. Bevorzugen Sie Namen, die ein Ziel, eine Verantwortung oder ein bedeutungsvolles Ereignis identifizieren.

Fehlerverhalten auslassen

Nur auf Erfolg ausgerichtete Modelle erzeugen unrealistische Erwartungen. Fügen Sie wichtige Ausnahmen, Wiederholungsversuche, Zeitüberschreitungen und abgelehnte Zustände ein.

Diagramme als dauerhaft behandeln

Architekturen entwickeln sich weiter. Ein Diagramm sollte einen Eigentümer und eine Wartungserwartung haben.

UML-Beziehungen übermäßig verwenden

Eine einfache Assoziation ist oft besser als eine technisch präzise, aber verwirrende Menge von Beziehungstypen.

Diagramme unleserlich machen

Verwenden Sie mehrere fokussierte Ansichten anstelle eines einzigen riesigen Diagramms. Zerlegen Sie große Modelle nach Szenario, Teilsystem, Lebenszyklus oder Bereitstellungs-Grenze.

Werkzeuge zur Steuerung des Designs zulassen

Ein Werkzeug kann das Erstellen von Diagrammen erleichtern, kann aber nicht entscheiden, was modelliert werden soll oder ob das Modell korrekt ist.

21. Ein praxisnaher Modellierungs-Arbeitsablauf

Ein Team kann den folgenden Arbeitsablauf für eine Funktion oder ein System übernehmen.

Schritt 1: Umfang festlegen

Erstellen Sie eine leichte Kontextansicht und identifizieren Sie:

• Systemgrenze

• Hauptbenutzer

• Externe Systeme

• Hauptziele

Schritt 2: Anwendungsfälle identifizieren

Schreiben Sie Anwendungsfälle als Akteursziele. Gruppieren Sie verwandte Funktionen und identifizieren Sie die wichtigsten Szenarien.

Schritt 3: Den Hauptarbeitsablauf modellieren

Verwenden Sie ein Aktivitätsdiagramm, um Folgendes darzustellen:

• Normaler Ablauf

• Entscheidungen

• Verantwortlichkeiten

• Parallele Arbeit

• Ausnahmen

Schritt 4: Kritische Szenarien auswählen

Erstellen Sie Sequenzdiagramme für Interaktionen, die wichtig, komplex, risikobehaftet oder integrationsintensiv sind.

Schritt 5: Domänenstruktur definieren

Erstellen Sie ein konzeptionelles oder Entwurfsniveau-Klassendiagramm für die Konzepte, die in diesen Szenarien involviert sind.

Schritt 6: Architekturgrenzen festlegen

Verwenden Sie ein Komponentendiagramm, um Folgendes darzustellen:

• Hauptmodule oder Dienste

• Schnittstellen

• Abhängigkeiten

• Eigentum

• Integrationsschnittstellen

Schritt 7: Modellbereitstellung

Erstellen Sie ein Bereitstellungsdiagramm, wenn Infrastruktur, Sicherheit, Skalierbarkeit, Verfügbarkeit oder Betriebsaspekte wesentliche Bedenken darstellen.

Schritt 8: Modelllebenszyklen

Erstellen Sie Zustandsautomatendiagramme für Entitäten, deren Verhalten vom Status oder zulässigen Übergängen abhängt.

Schritt 9: Validierung

Vergleichen Sie die Modelle mit:

• Anforderungen

• Vorhandener Code

• Tests

• Datenstrukturen

• Infrastruktur

• Betriebliche Einschränkungen

Schritt 10: Wartung

Aktualisieren Sie die betroffenen Diagramme, wenn sich Verhalten, Schnittstellen, Eigentumsverhältnisse oder die Bereitstellung ändern.

22. Ein minimales Lieferpaket für ein typisches System

Für eine mittelgroße Anwendung könnte ein praktischer Grundbestand wie folgt aussehen:

• Eine Systemkontext- oder Use-Case-Ansicht

• Zwei bis fünf Aktivitätsdiagramme für wichtige Geschäftsprozesse

• Zwei bis fünf Sequenzdiagramme für kritische Szenarien

• Ein Domänenklassendiagramm

• Ein Komponentendiagramm

• Ein Bereitstellungsdiagramm für die Produktion

• Zustandsautomatendiagramme für wichtige Lebenszyklus-Entitäten

Dies ist keine verbindliche Vorgabe. Einige Systeme benötigen weniger Diagramme, andere mehr. Die angemessene Anzahl hängt von Komplexität, Risiko, Teamgröße, Vorschriften und den Kosten von Missverständnissen ab.

23. Strategie zur Werkzeugauswahl

Unterschiedliche Werkzeuge erfüllen unterschiedliche Modellierungsbedürfnisse.

Ein Team muss nicht für jede Situation ein einziges Tool auswählen. Ein gemischter Ansatz kann gut funktionieren, wenn die Quelle der Wahrheit und die Verantwortlichkeiten für die Wartung klar sind.

Fazit

Eine praktische UML-Strategie geht nicht darum, jeden Diagrammtyp zu verwenden. Es geht darum, die kleinste Menge an Ansichten auszuwählen, die das System verständlich macht.

Der Kern aus sieben Diagrammen bietet breite Abdeckung:

• Anwendungsfalldiagramme erklären Ziele und Umfang.

• Aktivitätsdiagramme erklären Arbeitsabläufe und Verantwortlichkeiten.

• Sequenzdiagramme erklären Zusammenarbeit und Zeitplanung.

• Klassendiagramme erklären Struktur und Domänenkonzepte.

• Komponentendiagramme erklären architektonische Grenzen.

• Bereitstellungsdiagramme erklären Laufzeitplatzierung und Infrastruktur.

• Zustandsautomaten-Diagramme erklären Lebenszyklusregeln.

Visual Paradigm kann grafische Modellierung, Rückverfolgbarkeit und repository-basierte Zusammenarbeit unterstützen. VPasCode und PlantUML machen Diagramme einfacher zu versionieren, zu prüfen, zu generieren und mit Quellcode zu warten. KI kann das Erstellen, Transformieren und Prüfen beschleunigen, aber ihre Ausgabe muss gegen echte Anforderungen, die tatsächliche Implementierung und operative Einschränkungen geprüft werden.

Die stärkste Modellierungspraxis ist diszipliniert statt erschöpfend:

1. Modellieren Sie Entscheidungen, Risiken und Verhalten, die von Bedeutung sind.

2. Wählen Sie den Diagrammtyp, der die Frage am besten beantwortet.

3. Halten Sie jedes Diagramm auf einem einzigen Abstraktionsniveau fokussiert.

4. Verknüpfen Sie zusammenhängende Diagramme durch konsistente Namen und Rückverfolgbarkeit.

5. Validieren Sie Modelle anhand von Anforderungen, Code, Tests und der Bereitstellung.

6. Speichern und überprüfen Sie Diagramme als wartbare Projektartefakte.

7. Entfernen Sie Diagramme, die keinen Mehrwert mehr bieten.

Effektives UML wird nicht an der Anzahl der erstellten Diagramme gemessen. Es wird daran gemessen, ob die Modelle den Menschen helfen, das System mit größerem Vertrauen zu erstellen, zu testen, zu betreiben und zu ändern.

Referenz

1. VPasCode: KI-gestütztes Diagramm-as-Code mit PlantUML, Mermaid und Graphviz: Offizieller Leitfaden, der die Text-zu-Diagramm-Engine von VPasCode, Syntax-Best-Practices und KI-gestützte Änderungsworkflows abdeckt.
2. Von „Zeichenaufgaben“ zu „Artikulation“: Überblick über den KI-Chatbot: Erklärt, wie der KI-Chatbot von Visual Paradigm natürliche Sprache in normkonforme UML- und andere Diagramme umwandelt.
3. Stärken Sie den Visual Paradigm KI-Chatbot mit der NotesKeep-Wissensdatenbank: Zeigt, wie NotesKeep-Repositories als Wissensquelle für die KI-gesteuerte Diagrammerstellung und Anforderungssynthese verbunden werden können.
4. Revolutionieren Sie Ihre UML-Modellierung auf dem Mac mit Visual Paradigm: Überblick über die UML-2.x-Unterstützung, Code-Engineering und Modellrückverfolgbarkeit von Visual Paradigm unter macOS.
5. Vorstellung des KI-VPP-Chatbots in Visual Paradigm 18.1: Ankündigung der Veröffentlichung des KI-VPP-Chatbots, mit dem Benutzer .vpp-Projektdateien über natürliche Sprache abfragen können.
6. VPasCode-Pläne & Preise: Preisgestaltung und Funktionsvergleich für die kostenlose Version von VPasCode und die Integration mit den Online-/Desktop-Editionen von Visual Paradigm.
7. Willkommen bei Visual Paradigm VPasCode: Der Diagramm-as-Code-Shift: Stellt den Diagramm-as-Code-Workflow und die einheitliche Rendering-Umgebung für PlantUML, Mermaid und Graphviz vor.
8. Native KI-Diagrammerstellung in Visual Paradigm VPasCode: Beschreibt die eingebettete KI von VPasCode, die PlantUML/Mermaid/Graphviz-Diagramme direkt im Editor erstellt und modifiziert.

Der Artikel ist auch in English and Español verfügbar.