Qual è la differenza tra includere
e estendere
in un 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).
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.
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.
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:
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.
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!