Qual è la differenza tra includere ed estendere nel diagramma dei casi d'uso?

Extend è usato quando un caso d'uso aggiunge passi ad un altro caso d'uso di prima classe.

Per esempio, immaginiamo che "Withdraw Cash" sia un caso d'uso di un Automated Teller Machine (ATM). "Assess Fee" estenderebbe Withdraw Cash e descriverebbe il conditional "extension point" che viene istanziato quando l'utente del bancomat non effettua il prelievo presso l'istituto proprietario. Notate che il caso d'uso di base "Withdraw Cash" sta in piedi da solo, senza l'estensione.

Include è usato per estrarre frammenti di casi d'uso che sono duplicati in casi d'uso multipli. Il caso d'uso incluso non può stare da solo e il caso d'uso originale non è completo senza quello incluso. Questo dovrebbe essere usato con parsimonia e solo nei casi in cui la duplicazione è significativa ed esiste per progetto (piuttosto che per coincidenza).

Per esempio, il flusso di eventi che si verifica all'inizio di ogni caso d'uso ATM (quando l'utente inserisce la sua carta ATM, inserisce il suo PIN, e viene mostrato il menu principale) sarebbe un buon candidato per un include.

Questo può essere controverso, ma il "include sono sempre ed estende sono a volte" è un malinteso molto comune che ha quasi preso il sopravvento ora come significato de-facto. Ecco un approccio corretto (a mio parere, e controllato contro Jacobson, Fowler, Larmen e altri 10 riferimenti).

Le relazioni sono dipendenze

La chiave per includere ed estendere le relazioni tra i casi d'uso è realizzare che, come nel resto di UML, la freccia tratteggiata tra i casi d'uso è una relazione di dipendenza. Userò i termini "base", "incluso" ed "estendere" per riferirmi ai ruoli dei casi d'uso.

include

Un caso d'uso di base dipende dai casi d'uso inclusi; senza di essi il caso d'uso di base è incompleto, poiché i casi d'uso inclusi rappresentano sotto-sequenze dell'interazione che possono accadere sempre O qualche volta. (Questo è contrario a un malinteso popolare su questo, ciò che il tuo caso d'uso suggerisce accade sempre nello scenario principale e talvolta accade in flussi alternativi dipende semplicemente da ciò che scegli come scenario principale; i casi d'uso possono essere facilmente ristrutturati per rappresentare un flusso diverso come scenario principale e questo non dovrebbe avere importanza).

Nella migliore pratica di dipendenza a senso unico il caso d'uso di base conosce (e fa riferimento a) il caso d'uso incluso, ma il caso d'uso incluso non dovrebbe "conoscere" il caso d'uso di base. Questo è il motivo per cui i casi d'uso inclusi possono essere: a) casi d'uso di base a sé stanti e b) condivisi da un certo numero di casi d'uso di base.

estendere

Il caso d'uso estensivo dipende dal caso d'uso base; estende letteralmente il comportamento descritto dal caso d'uso base. Il caso d'uso base dovrebbe essere un caso d'uso completamente funzionale a sé stante (inclusi gli "include", ovviamente) senza le funzionalità aggiuntive del caso d'uso estensivo.

I casi d'uso estesi possono essere usati in diverse situazioni:

1. Il caso d'uso di base rappresenta la funzionalità "must have" di un progetto mentre il caso d'uso estensivo rappresenta un comportamento opzionale (dovrebbe/potrebbe/vorrebbe). Questo è dove il termine opzionale è rilevante - opzionale se costruire/consegnare piuttosto che opzionale se a volte viene eseguito come parte della sequenza del caso d'uso di base.
2. Nella fase 1 si può consegnare il caso d'uso di base che soddisfa i requisiti in quel punto, e la fase 2 aggiungerà funzionalità aggiuntive descritte dal caso d'uso esteso. Questo può contenere sequenze che sono sempre o a volte eseguite dopo che la fase 2 è stata consegnata (di nuovo contrariamente all'idea sbagliata popolare).
3. Può essere usato per estrarre sottosequenze del caso d'uso di base, specialmente quando rappresentano un comportamento complesso "eccezionale" con i propri flussi alternativi.

Un aspetto importante da considerare è che il caso d'uso estensivo può 'inserire' un comportamento in diversi posti nel flusso del caso d'uso di base, non solo in un singolo posto come fa un caso d'uso incluso. Per questo motivo, è altamente improbabile che un caso d'uso estensivo sia adatto ad estendere più di un caso d'uso base.

Per quanto riguarda la dipendenza, il caso d'uso estensivo dipende dal caso d'uso di base ed è di nuovo una dipendenza a senso unico, cioè il caso d'uso di base non ha bisogno di alcun riferimento al caso d'uso estensivo nella sequenza. Questo non significa che non si possano dimostrare i punti di estensione o aggiungere un x-ref al caso d'uso estensivo altrove nel modello, ma il caso d'uso base deve essere in grado di funzionare senza il caso d'uso estensivo.

SOMMARIO

Spero di aver dimostrato che il comune malinteso di "gli include sono sempre, gli extends sono a volte" è sbagliato o al massimo semplicistico. Questa versione in realtà ha più senso se si considerano tutti i problemi sulla direzionalità delle frecce che il malinteso presenta - nel modello corretto è solo dipendenza e non cambia potenzialmente se si rifattorizza il contenuto del caso d'uso.

quando ci sono prerequisiti per un caso d'uso, allora, vai per includere.

per le usecase che hanno autenticazione, nel peggiore dei casi, o sono opzionali, allora vai per estendere.

esempio: per un caso d'uso di ricerca di ammissione, appuntamento, prenotazione di biglietti SI DEVE COMPILARE UN MODULO (modulo di registrazione o di feedback) ....questo è il caso in cui include.

esempio: per un caso d'uso che verifica il login o l'accesso al tuo account, la tua autenticazione è un must.anche pensare a scenari peggiori.come restituire il libro con una multa..NON ottenere una prenotazione..pagare il conto DOPO LA DATA DI SCADENZA..questo è dove estendere viene a giocare...

non usate troppo include ed extend nei diagrammi.

MANTENETELO SEMPLICE, SCIOCCHI!