Wat's het verschil tussen include en extend in use case diagram?

Extend wordt gebruikt wanneer een use-case stappen toevoegt aan een andere eersteklas use-case.

Bijvoorbeeld, stel "Geld opnemen" is een use case van een Automated Teller Machine (ATM). "Fee berekenen" zou Geld opnemen uitbreiden en het voorwaardelijke "uitbreidingspunt" beschrijven dat wordt geïnstantieerd wanneer de gebruiker van de ATM niet bij de eigen instelling van de ATM'bankiert. Merk op dat de basis "Withdraw Cash" use case op zichzelf staat, zonder de uitbreiding.

Include wordt gebruikt om use case fragmenten te extraheren die dubbel voorkomen in meerdere use cases. De ingesloten use-case kan niet op zichzelf staan en de oorspronkelijke use-case is niet compleet zonder de ingesloten use-case. Dit moet spaarzaam worden gebruikt en alleen in gevallen waar de duplicatie significant is en bestaat door ontwerp (in plaats van door toeval).

Bijvoorbeeld, de stroom van gebeurtenissen die optreedt aan het begin van elke ATM use case (wanneer de gebruiker zijn ATM-kaart inbrengt, zijn PIN-code invoert, en het hoofdmenu te zien krijgt) zou een goede kandidaat zijn voor een include.

Dit kan omstreden zijn, maar het "omvat zijn altijd en uitbreidt zijn soms" is een veel voorkomende misvatting die nu bijna is overgenomen als de de-facto betekenis. Hier is een correcte benadering (naar mijn mening, en gecontroleerd aan de hand van Jacobson, Fowler, Larmen en 10 andere referenties).

Relaties zijn afhankelijkheden

De sleutel tot het opnemen en uitbreiden van use case relaties is te beseffen dat, net als in de rest van UML, de gestippelde pijl tussen use cases een afhankelijkheidsrelatie is. Ik zal de termen "base", "included" en "extending" gebruiken om te verwijzen naar de use-case rollen.

include

Een base use case is afhankelijk van de included use case(s); zonder deze is de base use case onvolledig omdat de included use case(s) subsequenties van de interactie vertegenwoordigen die altijd OF soms kunnen voorkomen. (Dit is in tegenstelling tot een populaire misvatting hierover, wat uw use case voorstelt gebeurt altijd in het hoofdscenario en soms in alternatieve stromen hangt gewoon af van wat u kiest als uw hoofdscenario; use cases kunnen gemakkelijk worden geherstructureerd om een andere stroom weer te geven als het hoofdscenario en dit zou er niet toe moeten doen).

In de best practice van one way dependency weet de base use case van (en verwijst naar) de included use case, maar de included use case mag niet "weten" van de base use case. Dit is de reden waarom ingesloten use cases kunnen zijn: a) base use cases op zichzelf en b) gedeeld door een aantal base use cases.

uitbreiden

De uitbreidende use-case is afhankelijk van de basis use-case; het breidt letterlijk het gedrag uit dat door de basis use-case wordt beschreven. De base use case moet een volledig functionele op zichzelf staande use case zijn ('include's inbegrepen natuurlijk) zonder de extra functionaliteit van de extending use case.

Uitbreidende use cases kunnen in verschillende situaties worden gebruikt:

1. De basis use case vertegenwoordigt de "must have" functionaliteit van een project terwijl de uitbreidende use case optioneel (zou moeten/kunnen/willen) gedrag vertegenwoordigt. Dit is waar de term optioneel relevant is - optioneel of te bouwen/te leveren eerder dan optioneel of het soms loopt als deel van de base use case sequentie.
2. In fase 1 kun je de basis use case opleveren die voldoet aan de eisen op dat moment, en fase 2 zal extra functionaliteit toevoegen die wordt beschreven door de uitbreidende use case. Deze kan sequenties bevatten die altijd of soms worden uitgevoerd nadat fase 2 is opgeleverd (wederom in tegenstelling tot wat vaak wordt gedacht).
3. Het kan worden gebruikt om subsequenties uit de basis use case te halen, vooral wanneer ze "uitzonderlijk" complex gedrag vertegenwoordigen met zijn eigen alternatieve flows.

Een belangrijk aspect om te overwegen is dat de uitbreidende use-case gedrag kan "invoegen" op verschillende plaatsen in de flow van de basis use-case, niet slechts op één enkele plaats zoals een ingesloten use-case doet. Om deze reden is het hoogst onwaarschijnlijk dat een uitbreidende use-case geschikt zal zijn om meer dan één basis use-case uit te breiden.

Wat de afhankelijkheid betreft, de uitbreidende use-case is afhankelijk van de basis use-case en is opnieuw een eenrichtingsafhankelijkheid, d.w.z. de basis use-case heeft geen verwijzing nodig naar de uitbreidende use-case in de sequentie. Dat betekent niet dat je de uitbreidingspunten niet kunt demonstreren of dat je geen x-ref naar de uitbreidende use-case elders in de template kunt toevoegen, maar de base use-case moet wel kunnen werken zonder de uitbreidende use-case.

SUMMARY

Ik hoop dat ik heb laten zien dat de veel voorkomende misvatting van "includes zijn altijd, extends zijn soms" niet klopt of op zijn best simplistisch is. Deze versie is eigenlijk logischer als je alle problemen over de richting van de pijlen die de misvatting geeft in overweging neemt - in het juiste model is het gewoon afhankelijkheid en verandert het potentieel niet als je de inhoud van de use case refactored.

Als er voorwaarden zijn voor een usecase, ga dan voor include.

Voor usecases die authenticatie hebben, worst case scenario, of optioneel zijn, ga dan voor extend..

voorbeeld: voor een usecase van het zoeken van toelating, afspraak, ticketreservering U MOET een formulier invullen (registratie of feedback formulier)....Dit is waar include komt..

voorbeeld: voor een use case verifiëren login of aanmelden in uw account, uw authenticatie is een must.also denken aan worst case scenario's.like terug te keren boek met boete..NIET krijgen van een reservering..het betalen van de rekening na de vervaldatum..dit is waar uit te breiden komt om te spelen...

Gebruik niet te veel include en extend in de diagrammen.

HOU HET SIMPEL, GEKKIE!!!