Was ist der Unterschied zwischen include und extend im Anwendungsfalldiagramm?

Erweitern wird verwendet, wenn ein Anwendungsfall Schritte zu einem anderen Anwendungsfall erster Klasse hinzufügt.

Stellen Sie sich zum Beispiel vor, "Bargeld abheben" ist ein Anwendungsfall eines Geldautomaten (ATM). "Gebühr ermitteln" würde den Anwendungsfall Bargeld abheben erweitern und den bedingten "Erweiterungspunkt" beschreiben, der instanziiert wird, wenn der Benutzer des Geldautomaten keine Bankgeschäfte bei dem Geldautomateninstitut tätigt, das ihn besitzt. Beachten Sie, dass der grundlegende Anwendungsfall "Bargeld abheben" ohne die Erweiterung für sich alleine steht.

Include wird verwendet, um Anwendungsfallfragmente zu extrahieren, die in mehreren Anwendungsfällen dupliziert sind. Der eingeschlossene Anwendungsfall kann nicht allein stehen und der ursprüngliche Anwendungsfall ist ohne den eingeschlossenen nicht vollständig. Dies sollte sparsam verwendet werden und nur in Fällen, in denen die Duplizierung signifikant ist und durch Design (und nicht durch Zufall) existiert.

Zum Beispiel wäre der Ablauf von Ereignissen, der zu Beginn jedes Anwendungsfalls eines Geldautomaten auftritt (wenn der Benutzer seine Geldautomatenkarte einsteckt, seine PIN eingibt und das Hauptmenü angezeigt bekommt), ein guter Kandidat für ein Include.

Dies mag umstritten sein, aber die Aussage "Includes sind immer und Extensions sind manchmal" ist ein weit verbreiteter Irrglaube, der sich inzwischen fast als De-facto-Bedeutung durchgesetzt hat. Hier ist ein korrekter Ansatz (meiner Meinung nach und geprüft anhand von Jacobson, Fowler, Larmen und 10 anderen Referenzen).

Beziehungen sind Abhängigkeiten

Der Schlüssel zum Einbeziehen und Erweitern von Use-Case-Beziehungen ist die Erkenntnis, dass der gepunktete Pfeil zwischen Use-Cases, wie in der übrigen UML, eine Abhängigkeitsbeziehung darstellt. Ich verwende die Begriffe "Basis", "Einschließen" und "Erweitern", um auf die Anwendungsfallrollen zu verweisen.

include

Ein Basis-Anwendungsfall ist abhängig von dem/den eingeschlossenen Anwendungsfall(en); ohne ihn/sie ist der Basis-Anwendungsfall unvollständig, da der/die eingeschlossene(n) Anwendungsfall(e) Teilsequenzen der Interaktion darstellen, die immer ODER manchmal auftreten können. (Dies steht im Gegensatz zu einem weit verbreiteten Missverständnis, dass das, was Ihr Anwendungsfall vorschlägt, immer im Hauptszenario und manchmal in alternativen Abläufen geschieht, einfach davon abhängt, was Sie als Hauptszenario wählen; Anwendungsfälle können leicht umstrukturiert werden, um einen anderen Ablauf als Hauptszenario darzustellen, und dies sollte keine Rolle spielen).

In der bewährten Praxis der Einwegabhängigkeit weiß der Basisanwendungsfall über den eingeschlossenen Anwendungsfall Bescheid (und verweist darauf), aber der eingeschlossene Anwendungsfall sollte nicht über den Basisanwendungsfall "Bescheid wissen". Aus diesem Grund können eingeschlossene Anwendungsfälle: a) eigenständige Basis-Anwendungsfälle sein und b) von mehreren Basis-Anwendungsfällen gemeinsam genutzt werden.

erweitern

Der erweiternde Anwendungsfall ist vom Basis-Anwendungsfall abhängig; er erweitert buchstäblich das Verhalten, das vom Basis-Anwendungsfall beschrieben wird. Der Basis-Anwendungsfall sollte ein voll funktionsfähiger, eigenständiger Anwendungsfall sein ('include's natürlich eingeschlossen) ohne die zusätzliche Funktionalität des erweiternden Anwendungsfalls.

Erweiternde Anwendungsfälle können in verschiedenen Situationen verwendet werden:

1. Der Basisanwendungsfall stellt die "Muss"-Funktionalität eines Projekts dar, während der erweiterte Anwendungsfall ein optionales Verhalten darstellt (sollte/könnte/wollte). Hier ist der Begriff "optional" von Bedeutung - optional in Bezug auf die Erstellung/Auslieferung und nicht optional in Bezug auf die Ausführung als Teil der Sequenz des Basisanwendungsfalls.
2. In Phase 1 können Sie den Basis-Anwendungsfall liefern, der die Anforderungen zu diesem Zeitpunkt erfüllt, und in Phase 2 wird zusätzliche Funktionalität hinzugefügt, die durch den erweiterten Anwendungsfall beschrieben wird. Dieser kann Sequenzen enthalten, die immer oder manchmal ausgeführt werden, nachdem Phase 2 geliefert wurde (was wiederum einem weit verbreiteten Missverständnis widerspricht).
3. Es kann verwendet werden, um Teilsequenzen des Basisanwendungsfalls zu extrahieren, insbesondere wenn sie "außergewöhnliches" komplexes Verhalten mit eigenen alternativen Abläufen darstellen.

Ein wichtiger Aspekt, den es zu berücksichtigen gilt, ist, dass der erweiternde Anwendungsfall Verhalten an mehreren Stellen in den Ablauf des Basis-Anwendungsfalls "einfügen" kann, nicht nur an einer einzigen Stelle, wie es ein eingeschlossener Anwendungsfall tut. Aus diesem Grund ist es höchst unwahrscheinlich, dass ein erweiternder Anwendungsfall geeignet ist, mehr als einen Basis-Anwendungsfall zu erweitern.

Was die Abhängigkeit betrifft, so ist der erweiternde Anwendungsfall vom Basis-Anwendungsfall abhängig und auch hier handelt es sich um eine einseitige Abhängigkeit, d.h. der Basis-Anwendungsfall benötigt keinen Verweis auf den erweiternden Anwendungsfall in der Sequenz. Das bedeutet nicht, dass Sie die Erweiterungspunkte nicht demonstrieren oder an anderer Stelle in der Vorlage einen Verweis auf den erweiternden Anwendungsfall hinzufügen können, aber der Basisanwendungsfall muss auch ohne den erweiternden Anwendungsfall funktionieren.

ZUSAMMENFASSUNG

Ich hoffe, dass ich gezeigt habe, dass das gängige Missverständnis "includes sind immer, extends sind manchmal" entweder falsch oder bestenfalls vereinfachend ist. Diese Version macht tatsächlich mehr Sinn, wenn man alle Probleme mit der Richtungsabhängigkeit der Pfeile berücksichtigt, die das Missverständnis darstellt - im korrekten Modell ist es nur eine Abhängigkeit und ändert sich nicht, wenn man den Inhalt des Anwendungsfalls umstrukturiert.

Wenn es Voraussetzungen für einen Anwendungsfall gibt, dann sollten Sie sich für Include entscheiden.

für Usecases mit Authentifizierung, Worst-Case-Szenario, oder sind optional dann gehen Sie für erweitern...

Beispiel: für einen Anwendungsfall, bei dem eine Zulassung, ein Termin oder eine Ticketreservierung gesucht wird SIE MÜSSEN EIN FORMULAR AUSFÜLLEN (Registrierung oder Feedback-Formular)....hier kommt include ins Spiel.

Beispiel: Für einen Anwendungsfall, bei dem die Anmeldung oder das Einloggen in Ihr Konto überprüft werden soll, ist Ihre Authentifizierung ein Muss. Denken Sie auch an Worst-Case-Szenarien wie die Rückgabe eines Buches mit Geldstrafe, die Nichterteilung einer Reservierung oder die Bezahlung der Rechnung nach dem Fälligkeitsdatum... hier kommt extend ins Spiel.

Verwenden Sie include und extend in den Diagrammen nicht übermäßig.

KEEP IT SIMPLE SILLY!!!