Now Reading: Ein umfassender Leitfaden zum Einbeziehen und Erweitern von Beziehungen in UML-Aktdiagrammen

1
  • 01

    Ein umfassender Leitfaden zum Einbeziehen und Erweitern von Beziehungen in UML-Aktdiagrammen

en_USes_ESfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Ein umfassender Leitfaden zum Einbeziehen und Erweitern von Beziehungen in UML-Aktdiagrammen

Use Case Modeling, Unified Modeling Language, Visual Paradigm8 hours ago

Unified Modeling Language (UML)Aktdiagramme sind leistungsfähige Werkzeuge zur Modellierung der funktionalen Anforderungen eines Systems. Sie veranschaulichen, wie Akteure (Benutzer oder externe Systeme) über Akteure mit dem System interagieren, die spezifische Funktionalitäten darstellen. Zwei zentrale Beziehungen in Aktdiagrammen—Einbeziehen und Erweitern—helfen dabei, die Komplexität durch Strukturierung und Modularisierung des Verhaltens zu managen. Dieser Tutorial bietet eine detaillierte Erklärung dieser Beziehungen, ihrer Zwecke, Eigenschaften und praktischen Anwendungen, inklusive Beispiele zur Sicherstellung von Klarheit.

Was sind Einbeziehungs- und Erweiterungsbeziehungen?

In UML-Aktdiagrammen, Einbeziehen und ErweiternBeziehungen ermöglichen es Ihnen, komplexe Akteure in kleinere, wiederverwendbare oder optionale Komponenten zu zerlegen. Diese Beziehungen erhöhen die Modularität, reduzieren Redundanz und verbessern die Klarheit der Diagramme.

Include” and “Extend” Use Cases - Visual Paradigm Blog

  • Einbeziehungsbeziehung (<<einbeziehen>>): Stellt ein obligatorisches Verhalten dar, das immer als Teil eines Basis-Akteurs ausgeführt wird. Es extrahiert gemeinsame Funktionalitäten, die über mehrere Akteure hinweg vorhanden sind, in eine wiederverwendbare Komponente.

  • Erweiterungsbeziehung (<<erweitern>>): Stellt ein optionales oder bedingtes Verhalten dar, das einen Basis-Akteur unter bestimmten Bedingungen erweitert und den Basis-Akteur auf seine Kernfunktionalität fokussiert hält.

Beide Beziehungen verwenden gestrichelte Pfeile, um Akteure zu verbinden, wobei die Beschriftungen <<einbeziehen>> oder <<erweitern>>. Die Richtung des Pfeils ist entscheidend, da sie die Abhängigkeit zwischen den Akteuren widerspiegelt.

Einbeziehungsbeziehung (<<einbeziehen>>)

Zweck

Der EinbeziehenDie Beziehung wird verwendet, um gemeinsame, obligatorische Verhaltensweisen aus mehreren Anwendungsfällen in einen einzigen, wiederverwendbaren Anwendungsfall zu extrahieren. Dies fördert die Wiederverwendbarkeit und vereinfacht die Basisanwendungsfälle, indem doppelte Funktionalität vermieden wird.

Eigenschaften

  • Obligatorisch: Der eingeschlossene Anwendungsfall wird immer ausgeführt, wenn der Basisanwendungsfall durchgeführt wird.

  • Wiederverwendbar: Der eingeschlossene Anwendungsfall ist eine eigenständige, kohärente Funktion, die von mehreren Basisanwendungsfällen verwendet werden kann.

  • Vereinfacht Diagramme: Durch die Extraktion gemeinsamer Schritte bleibt der Basisanwendungsfall knapp und fokussiert.

  • Richtung: Der Pfeil zeigt vom Basisanwendungsfall zum eingeschlossenen Anwendungsfall, was anzeigt, dass der Basisanwendungsfall vom eingeschlossenen abhängt.

Notation

  • Ein gestrichelter Pfeil mit der Beschriftung<<einbeziehen>> verbindet den Basisanwendungsfall mit dem eingeschlossenen Anwendungsfall.

Beispiel 1: Online-Einkaufssystem

Betrachten Sie ein Online-Einkaufssystem, bei dem ein KundeBestellung aufgeben oder Bestellung stornieren. Beide Anwendungsfälle erfordern, dass der KundeEinloggen sich im System anmeldet.

  • Basisanwendungsfälle: Bestellung aufgeben, Bestellung stornieren

  • Eingebundener Anwendungsfall: Anmelden

  • Erklärung: Die Anmeldung ist ein obligatorischer Schritt sowohl beim Platzieren als auch beim Stornieren einer Bestellung. Anstatt die Anmeldefunktion in beiden Anwendungsfällen zu duplizieren, wird sie in einen separaten Anmelden Anwendungsfall ausgelagert, der von beiden eingebunden wird.

Diagrammdarstellung:

[Bestellung aufgeben] ----<<einschließen>>----> [Anmelden]
[Bestellung stornieren] ----<<einschließen>>----> [Anmelden]

Beispiel 2: Bibliotheksverwaltungssystem

In einem Bibliothekssystem kann ein Benutzer Buch ausleihen oder Buch zurückgeben. Beide Prozesse erfordern Benutzer überprüfen.

  • Grundanwendungsfälle: Buch ausleihen, Buch zurückgeben

  • Eingebundener Anwendungsfall: Benutzer überprüfen

  • Erklärung: Die Überprüfung der Benutzeridentität (z. B. Prüfung der Bibliothekskarte) ist ein obligatorischer Schritt sowohl beim Ausleihen als auch beim Zurückgeben eines Buches. Der Benutzer überprüfen Der Use Case wird eingeschlossen, um Redundanz zu vermeiden.

Diagrammdarstellung:

[Buch ausleihen] ----<<include>>----> [Benutzer überprüfen]
[Buch zurückgeben] ----<<include>>----> [Benutzer überprüfen]

Wann verwenden

  • Wenn mehrere Use Cases einen gemeinsamen, obligatorischen Schritt teilen.

  • Wenn Sie die Use-Case-Beschreibungen vereinfachen möchten, indem Sie wiederverwendbare Funktionalität extrahieren.

  • Wenn der eingeschlossene Use Case unabhängig sinnvoll ist (z. B. Anmelden oder Benutzer überprüfen kann als eigenständige Funktionen verstanden werden).

Erweiterungsbeziehung (<<erweitern>>)

Zweck

Die ErweiternDie Erweiterungsbeziehung wird verwendet, um optionales oder bedingtes Verhalten zu modellieren, das nur unter bestimmten Umständen ausgeführt wird. Sie ermöglicht es dem Basis-Use-Case, sich auf seine Kernfunktionen zu konzentrieren, während optionaler Funktionalität modulare hinzugefügt wird.

Eigenschaften

  • Optional/Bedingt: Der erweiternde Use Case wird nur ausgeführt, wenn bestimmte Bedingungen erfüllt sind.

  • Abhängig: Der erweiternde Use Case ist nicht selbstständig sinnvoll und hängt vom Basis-Use-Case ab.

  • Erweiterungspunkte: Der Basis-Use-Case kann spezifische Punkte definieren, an denen das erweiternde Verhalten eingefügt werden kann.

  • Richtung: Der Pfeil zeigt vom erweiternden Use Case zum Basis-Use-Case, was anzeigt, dass der erweiternde Use Case dem Basis-Use-Case Verhalten hinzufügt.

Notation

  • Ein gestrichelter Pfeil mit der Beschriftung <<erweitern>> verbindet den erweiternden Use Case mit dem Basis-Use Case, oft mit einer Notiz, die die Bedingung oder den Erweiterungspunkt angibt.

Beispiel 1: Geldautomatensystem

Im Geldautomatensystem ist der Basis-Use CaseGeld abheben. Ein optionales Verhalten,Beleg ausdrucken, kann auftreten, wenn der Benutzer einen Beleg anfordert.

  • Basis-Use Case: Geld abheben

  • Erweiternder Use Case: Beleg ausdrucken

  • Bedingung: Der Benutzer entscheidet sich, einen Beleg auszudrucken, nachdem er Geld abgehoben hat.

  • Erklärung: Der Belegausdruck ist nicht obligatorisch und erfolgt nur, wenn der Benutzer ihn ausdrücklich anfordert. Der Beleg ausdrucken Use Case erweitert Geld abheben am Erweiterungspunkt „Benutzer fordert Beleg an.“

Diagrammdarstellung:

[Beleg ausdrucken] ----<<erweitern>>----> [Geld abheben]rn(Hinweis: Bedingung = Benutzer fordert Beleg an)

Beispiel 2: Online-Kursplattform

In einer Online-Kursplattform kann ein BenutzerQuiz beantworten. Ein optionales Verhalten,Hinweis anfordern, tritt auf, wenn der Benutzer Schwierigkeiten mit einer Frage hat.

  • Basisisierung: Quiz bearbeiten

  • Erweiternde Anwendungsfall: Hinweis anfordern

  • Bedingung: Der Benutzer fordert während des Quiz einen Hinweis an.

  • Erklärung: Die Anforderung eines Hinweises ist optional und hängt vom Bedarf des Benutzers ab. Der Hinweis anfordern Anwendungsfall erweitert Quiz bearbeiten am Erweiterungspunkt „Benutzer benötigt Hilfe.“

Diagrammdarstellung:

[Hinweis anfordern] ----<<erweitern>>----> [Quiz bearbeiten]
(Hinweis: Bedingung = Benutzer benötigt Hilfe)

Wann verwenden

  • Wenn das Verhalten optional ist oder von bestimmten Bedingungen abhängt.

  • Wenn Sie den Basisanwendungsfall auf seine primäre Funktionalität fokussiert halten möchten.

  • Wenn der erweiternde Anwendungsfall ohne den Basisanwendungsfall keinen Sinn ergibt (z. B. Beleg ausdrucken ist ohne Geld abheben).

Wichtige Unterschiede zwischen Include und Extend

Die folgende Tabelle fasst die Unterschiede zwischen Einbinden und Erweitern Beziehungen, um ihre Verwendung zu leiten:

Kriterien

Einbeziehen (<<einbeziehen>>)

Erweitern (<<erweitern>>)

Ist das Verhalten obligatorisch?

Ja, wird immer als Teil des Basis-Anwendungsfalls ausgeführt

Nein, wird nur unter bestimmten Bedingungen ausgeführt

Kann das Verhalten unabhängig existieren?

Ja, es ist eine kohärente, wiederverwendbare Funktion

Nein, es hängt vom Basis-Anwendungsfall ab

Tritt es in mehreren Anwendungsfällen auf?

Ja, wird über mehrere Anwendungsfälle geteilt

Meist spezifisch für einen Anwendungsfall

Zweck

Wiederverwendung fördern und den Basis-Anwendungsfall vereinfachen

Optionales oder außergewöhnliches Verhalten modulargestaltig hinzufügen

Pfeilrichtung

Basis → Einbezogener Anwendungsfall

Erweiternder → Basis-Anwendungsfall

Praktisches Beispiel: Restaurant-Verwaltungssystem

Lassen Sie uns beide Beziehungen in einem Restaurant-Verwaltungssystem anwenden, um ihre Verwendung in einer realen Situation zu veranschaulichen.

Szenario

Ein Restaurant-System ermöglicht es Kunden, Essen zu bestellen und Tisch reservieren. Das System verarbeitet auch zusätzliche Verhaltensweisen wie Rechnung bezahlen und Abholung anfordern.

Anwendungsfälle

  • Essen bestellen: Der Kunde bestellt Essen von der Speisekarte.

  • Tisch reservieren: Der Kunde reserviert einen Tisch zum Essen.

  • Kunden authentifizieren: Überprüft die Identität des Kunden (z. B. über ein Treuekonto).

  • Rechnung bezahlen: Der Kunde zahlt für seine Bestellung (pflichtend für Essen bestellen).

  • Abholung anfordern: Eine optionale Anforderung, die Bestellung zum Mitnehmen zu verpacken.

Beziehungen

  • Enthält: Beide Essen bestellen und Tisch reservieren erfordern Kunden authentifizieren um die Identität des Kunden zu überprüfen. Essen bestellen beinhaltet auch Rechnung bezahlen da die Zahlung nach der Bestellung obligatorisch ist.

  • Erweitern: Essen bestellen kann erweitert werden durch Abholung anfordern falls der Kunde entscheidet, sein Essen mitzunehmen.

Diagrammdarstellung

[Essen bestellen] ----<<einschließen>>----> [Kunden authentifizieren]
[Essen bestellen] ----<<einschließen>>----> [Rechnung bezahlen]
[Tisch reservieren] ----<<einschließen>>----> [Kunden authentifizieren]
[Abholung anfordern] ----<<erweitern>>----> [Essen bestellen]
(Hinweis: Bedingung = Kunde fordert Abholung)

Erklärung

  • Kunden authentifizieren ist in beiden enthaltenEssen bestellen und Tisch reservieren da es ein obligatorischer Schritt zur Systemnutzung ist.

  • Rechnung bezahlen ist in enthaltenEssen bestellen da die Zahlung zur Abschluss der Bestellung erforderlich ist.

  • Abholung anfordern erweitert Essen bestellen da es ein optionales Verhalten ist, das nur auftritt, wenn der Kunde eine Abholung anfordert.

Best Practices für die Verwendung von Einschließen und Erweitern

  1. Verwenden Sie Einschließen sparsam: Extrahieren Sie nur Verhalten in einen eingeschlossenen Use Case, wenn es von mehreren Use Cases geteilt wird oder den Basis-Use Case erheblich vereinfacht. Zu häufige Verwendung von Einschließungen kann Diagramme unübersichtlich machen.

  2. Definieren Sie klare Erweiterungspunkte für Erweitern: Geben Sie die Bedingungen oder Punkte im Basis-Use Case an, an denen das erweiternde Verhalten gilt, um Unklarheiten zu vermeiden.

  3. Halten Sie Use Cases fokussiert: Stellen Sie sicher, dass der Basis-Use-Case einfach bleibt und sich auf sein primäres Ziel konzentriert, indem Sie Einbinden für obligatorische Schritte und Erweitern für optionale Schritte.

  4. Überprüfen Sie die Wiederverwendbarkeit für Einbinden: Der eingebundene Use-Case sollte sinnvoll und in verschiedenen Kontexten wiederverwendbar sein.

  5. Vermeiden Sie unnötige Komplexität in Diagrammen: Verwenden Sie Einbinden und Erweitern nur, wenn sie Klarheit schaffen. Komplexe Beziehungen können Stakeholder verwirren.

Häufige Fehler und wie man sie vermeidet

  1. Verwechseln von Einbinden mit Erweitern:

    • Fehlerquelle: Verwenden von Einbinden für optionales Verhalten oder Erweitern für obligatorisches Verhalten.

    • Lösung: Überprüfen Sie immer, ob das Verhalten obligatorisch ist (verwenden Sie Einbinden) oder bedingt (verwenden Sie Erweitern).

  2. Übermäßige Verwendung von Beziehungen:

    • Falle: Zu viele erstellenEinbeziehen oder Erweitern Beziehungen, wodurch das Diagramm schwer lesbar wird.

    • Lösung: Verwenden Sie diese Beziehungen nur, wenn sie Redundanz verringern oder die Klarheit verbessern.

  3. Ungenaue Erweiterungsbedingungen:

    • Falle: Die Bedingung für eine ErweiternBeziehung nicht angeben, was zu Verwirrung führt.

    • Lösung: Fügen Sie immer eine Notiz oder Beschreibung der Bedingung oder des Erweiterungspunkts hinzu.

  4. Einbeziehung nicht wiederverwendbarer Verhaltensweisen:

    • Falle: Ein eingeschlossenes Anwendungsfalldiagramm erstellen, das nur von einem Basis-Anwendungsfalldiagramm verwendet wird.

    • Lösung: Stellen Sie sicher, dass das eingeschlossene Anwendungsfalldiagramm wiederverwendbar ist oder das Basis-Anwendungsfalldiagramm erheblich vereinfacht.

Fazit

Die Einbeziehen und ErweiternBeziehungen in UML-Anwendungsfalldiagrammen sind entscheidend für die Behandlung von Komplexität und die Gewährleistung von Modularität. Die Einbeziehen Beziehung fördert Wiederverwendbarkeit, indem obligatorische, gemeinsame Verhaltensweisen extrahiert werden, während die Erweitern Beziehung hält die Basis-Use-Cases fokussiert, indem sie optionales oder bedingtes Verhalten modelliert. Durch Verständnis ihrer Zwecke, Eigenschaften und Best Practices können Sie klare, wartbare und effektive Use-Case-Diagramme erstellen, die die Systemfunktionalität an Stakeholder vermitteln.

Referenz

Follow
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...