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

Qual è la differenza tra includee extendin un diagramma dei casi d'uso ?

L'estensione viene utilizzata quando un caso d'uso aggiunge passaggi a un altro caso d'uso di prima classe.

Ad esempio, immagina che "Prelievo di contanti" sia un caso d'uso di un bancomat. "Valuta commissione" estenderebbe il prelievo di contante e descriverà il "punto di estensione" condizionale che viene istanziato quando l'utente ATM non effettua operazioni bancarie presso l'ente proprietario dello sportello automatico. Si noti che il caso d'uso di base "Preleva contanti" è autonomo, senza l'estensione.

Includere viene utilizzato per estrarre frammenti di casi d'uso duplicati in più casi d'uso. Il caso d'uso incluso non può essere autonomo 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 in base alla progettazione (piuttosto che per coincidenza).

Ad esempio, il flusso di eventi che si verifica all'inizio di ogni caso d'uso dello sportello automatico (quando l'utente inserisce la propria carta bancomat, immette il PIN e viene visualizzato il menu principale) sarebbe un buon candidato per una inclusione.

Questo può essere controverso, ma le "inclusioni sono sempre e le estensioni a volte" è un malinteso molto comune che ha quasi preso il sopravvento ora come significato di fatto. Ecco un approccio corretto (a mio avviso, e verificato contro Jacobson, Fowler, Larmen e altri 10 riferimenti).

Le relazioni sono dipendenze

La chiave per includere ed estendere le relazioni sui casi d'uso è rendersi conto che, comune con il resto di UML, la freccia tratteggiata tra i casi d'uso è una relazione di dipendenza. Userò i termini 'base', 'incluso' ed 'estensione' per fare riferimento ai ruoli del caso d'uso.

includere

Un caso d'uso di base dipende dai casi d'uso inclusi; senza di essa il caso d'uso di base è incompleto in quanto i casi d'uso inclusi rappresentano le sottosequenze dell'interazione che possono verificarsi sempre O a volte. (Ciò è in contrasto con 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 importare).

Nella migliore pratica della dipendenza in un modo il caso d'uso di base conosce (e si riferisce a) il caso d'uso incluso, ma il caso d'uso incluso non dovrebbe "conoscere" il caso d'uso base. Questo è il motivo per cui i casi d'uso inclusi possono essere: a) casi d'uso di base a sé stanti eb) condivisi da un numero di casi d'uso di base.

estendere

Il caso d'uso esteso dipende dal caso d'uso base; estende letteralmente il comportamento descritto dal caso d'uso di base. Il caso d'uso di base dovrebbe essere un caso d'uso completamente funzionale a sé stante ('include ovviamente incluso) senza la funzionalità aggiuntiva del caso d'uso esteso.

L'estensione dei casi d'uso può essere utilizzata in diverse situazioni:

1. Il caso d'uso di base rappresenta la funzionalità "must have" di un progetto, mentre il caso d'uso esteso rappresenta un comportamento facoltativo (dovrebbe / potrebbe / volere). È qui che il termine opzionale è pertinente - facoltativo se costruire / consegnare piuttosto che facoltativo se a volte viene eseguito come parte della sequenza dei casi d'uso di base.
2. Nella fase 1 è possibile fornire il caso d'uso di base che soddisfa i requisiti in quel momento, e la fase 2 aggiungerà funzionalità aggiuntive descritte dal caso d'uso esteso. Questo può contenere sequenze che vengono sempre o talvolta eseguite dopo la consegna della fase 2 (di nuovo contrariamente al malinteso popolare).
3. Può essere usato per estrarre le sottosequenze del caso d'uso di base, specialmente quando rappresentano un comportamento complesso "eccezionale" con i suoi flussi alternativi.

Un aspetto importante da considerare è che il caso d'uso esteso può "inserire" il comportamento in diversi punti del 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 estensibile sia adatto a estendere più di un caso d'uso di base.

Per quanto riguarda la dipendenza, il caso d'uso estendente dipende dal caso d'uso di base ed è di nuovo una dipendenza unidirezionale, ovvero il caso d'uso di base non ha bisogno di alcun riferimento al caso d'uso esteso nella sequenza. Ciò non significa che non è possibile dimostrare i punti di estensione o aggiungere una x-ref al caso d'uso estensivo in altre parti del modello, ma il caso d'uso di base deve essere in grado di funzionare senza il caso d'uso esteso.

SOMMARIO

Spero di aver dimostrato che l'idea sbagliata comune di "include sono sempre, si estende a volte" è sbagliata o nella migliore delle ipotesi semplicistica. Questa versione in realtà ha più senso se si considerano tutti i problemi relativi alla direzionalità delle frecce che il malinteso presenta: nel modello corretto è solo dipendenza e non cambia potenzialmente se si refacturing il contenuto del caso d'uso.

Lo uso spesso per ricordare i due:

Il mio caso d'uso: vado in città.

include -> guidare l'auto

si estende -> riempire la benzina

"Riempire la benzina" potrebbe non essere richiesto in ogni momento, ma facoltativamente può essere richiesto in base alla quantità di benzina rimasta nell'auto. "Guidare l'auto" è un prerequisito, quindi includo.

I casi d'uso vengono utilizzati per documentare il comportamento, ad esempio rispondere a questa domanda.

Un comportamento si estende ad un altro se è in aggiunta ma non necessariamente parte del comportamento, ad esempio ricerca della risposta.

Nota anche che la ricerca della risposta non ha molto senso se non stai cercando di rispondere alla domanda.

Un comportamento è incluso in un altro se fa parte del comportamento incluso, ad es. Accedi allo scambio di stack.

Per chiarire, l'illustrazione è vera solo se si desidera rispondere qui in overflow dello stack :).

Queste sono le definizioni tecniche di UML 2.5 pagine 671-672.

Ho sottolineato ciò che penso siano punti importanti.

estende

Un Extend è una relazione tra un UseCase (l'estensione) esteso e un UseCase esteso (estensioneCase) che specifica come e quando è possibile inserire il comportamento definito in UseCase esteso nel comportamento definito in UseCase esteso. L'estensione ha luogo in uno o più punti di estensione specifici definiti nella UseCase estesa.

Extend è destinato a essere utilizzato quando vi è un comportamento aggiuntivo che dovrebbe essere aggiunto, possibilmente in modo condizionale , al comportamento definito in uno o più UseCases.

La UseCase estesa è definita indipendentemente dalla UseCase estendibile ed è significativa indipendentemente dalla UseCase estensibile . D'altra parte, la UseCase estendibile in genere definisce un comportamento che potrebbe non essere necessariamente significativo da solo . Invece, UseCase estendibile definisce una serie di incrementi di comportamento modulari che aumentano l'esecuzione di UseCase esteso in condizioni specifiche.

...

include

Include è una DirectedRelationship tra due UseCase, che indica che il comportamento di UseCase incluso (l'aggiunta) è inserito nel comportamento di UseCase incluso ( inclusoCase ). È anche una specie di NamedElement in modo che possa avere un nome nel contesto del proprio UseCase (il compresoCase). UseCase incluso può dipendere dalle modifiche prodotte eseguendo UseCase incluso. UseCase incluso deve essere disponibile affinché il comportamento di UseCase incluso sia completamente descritto.

La relazione Includi deve essere utilizzata quando vi sono parti comuni del comportamento di due o più casi d'uso. Questa parte comune viene quindi estratta in un UseCase separato, da includere in tutti gli UseCase di base che hanno questa parte in comune . Poiché l'uso principale della relazione Includi è per il riutilizzo di parti comuni, ciò che rimane in una UseCase di base non è di solito completo in sé, ma dipende dal significato delle parti incluse. Ciò si riflette nella direzione della relazione, indicando che UseCase di base dipende dall'aggiunta ma non viceversa.

...

Penso che sia importante capire l'intenzione di include ed estende:

"La relazione include è intesa per riutilizzare il comportamento modellato da un altro caso d'uso , mentre la relazione estesa è intesa per aggiungere parti a casi d'uso esistenti nonché per modellare servizi di sistema opzionali " (Overgaard e Palmkvist, Use Cases: Patterns and Blueprints. Addison -Wesley, 2004).

Questo mi dice come:

Include = riutilizzo della funzionalità (ovvero la funzionalità inclusa viene utilizzata o potrebbe essere utilizzata altrove nel sistema). Includi quindi indica una dipendenza da un altro caso d'uso.

Estende = aggiunta funzionalità (non riutilizzo) e anche qualsiasi funzionalità opzionale . Estensioni pertanto può indicare una delle due cose:
1. aggiunta di nuove caratteristiche / capacità a un caso d'uso (facoltativo o meno)
2. eventuali casi d'uso facoltativi (esistenti o meno).

Riepilogo:
Includi = riutilizzo della funzionalità
Estende = funzionalità nuova e / o facoltativa

Molto spesso troverai il 2o utilizzo (ovvero la funzionalità opzionale) degli extender, perché se la funzionalità non è facoltativa, la maggior parte delle volte è incorporata nel caso d'uso stesso, anziché essere un'estensione. Almeno questa è stata la mia esperienza. (Julian C sottolinea che a volte vedi il primo utilizzo (ovvero l'aggiunta di nuove funzionalità) di estensioni quando un progetto entra nella sua seconda fase).

Per semplificare,

per include

1. Quando viene eseguito il caso d'uso di base, il caso d'uso incluso viene eseguito TUTTI .
2. Il caso d'uso di base ha richiesto il completamento del caso d'uso incluso per essere completato.

un tipico esempio: tra login e verifica password

(login) --- << includi >> --- > (verifica password)

affinché il processo di accesso abbia esito positivo, anche "verifica password" deve avere esito positivo.

per extend

1. Quando viene eseguito il caso d'uso di base, il caso d'uso esteso viene eseguito solo SOMETIMES
2. Il caso d'uso esteso accadrà solo quando saranno soddisfatti determinati criteri.

un tipico esempio: tra login e mostra messaggio di errore (è successo solo a volte)

(login) < --- << estende >> --- (mostra messaggio di errore)

"mostra messaggio di errore" si verifica a volte solo quando il processo di accesso non è riuscito.

Penso che ciò che ha spiegato msdn qui sia abbastanza facile da capire.

Includi [5]

Un caso d'uso incluso chiama o richiama quello incluso. L'inclusione viene utilizzata per mostrare come un caso d'uso si suddivide in passaggi più piccoli. Il caso d'uso incluso si trova all'estremità della freccia.

Estendi [6]

Nel frattempo, un caso d'uso esteso aggiunge obiettivi e passaggi al caso d'uso esteso. Le estensioni funzionano solo a determinate condizioni. Il caso d'uso esteso si trova all'estremità della freccia.

Rendiamolo più chiaro. Usiamo includeogni volta che vogliamo esprimere il fatto che l'esistenza di un caso dipende dall'esistenza di un altro.

ESEMPI:

Un utente può fare acquisti online solo dopo aver effettuato l'accesso al proprio account. In altre parole, non può fare acquisti finché non ha effettuato l'accesso al suo account.

Un utente non può scaricare da un sito prima che il materiale fosse stato caricato. Quindi, non riesco a scaricare se non è stato caricato nulla.

Lo capisci?

Si tratta di conseguenze condizionate. Non posso farlo se prima non l'ho fatto .

Almeno, penso che questo sia il modo giusto di usare Include. Tendo a pensare che l'esempio con Laptop e la garanzia di cui sopra sia il più convincente!

ogni volta che ci sono prerequisiti per un caso d'uso, andare a includere.

per i casi d'uso con autenticazione, scenario peggiore o facoltativi, andare per estendere.

esempio: per un caso d'uso di ricerca di ammissione, appuntamento, prenotazione del biglietto DEVI COMPILARE un modulo (modulo di registrazione o feedback) .... qui è dove include include ..

esempio: per un caso d'uso che verifica il login o accedi al proprio account, l'autenticazione è d'obbligo. Pensate anche agli scenari peggiori. Come restituire il libro con il bene ... NON ottenere una prenotazione ... pagare il conto DOPO DATA DATA ... questo è dove estende viene a giocare ...

non abusare di includere ed estendere nei diagrammi.

TIENI SEMPLICE SILLY !!!

Fai attenzione anche alla versione UML: ormai da molto tempo << usa >> e << include >> sono stati sostituiti da << include >> e << estende >> da << estendi >> E generalizzazione .
Per me questo è spesso il punto fuorviante: ad esempio il post e il link di Stephanie riguardano una vecchia versione:

Quando si paga un articolo, è possibile scegliere di pagare alla consegna, pagare tramite paypal o pagare con carta. Queste sono tutte alternative al caso d'uso "paga per articolo". Posso scegliere una di queste opzioni in base alle mie preferenze.

In realtà non esiste alternativa al "pagamento per articolo"! Al giorno d'oggi UML, "pay on delivery" è un'estensione e "pay using paypal" / "pay by card" sono specializzazioni.

"Includi" viene utilizzato per estendere il caso d'uso di base ed è una condizione indispensabile, ovvero l'esecuzione del caso d'uso incluso deve essere eseguita correttamente per completare l'uso di base.

ad es. considerare un caso di servizio e-mail, qui "Login" è un caso d'uso incluso che deve essere eseguito per inviare un'e-mail (caso d'uso base)

"Escludi" invece è un caso d'uso facoltativo che estende il caso d'uso di base, il caso d'uso di base può essere eseguito correttamente anche senza richiamare / chiamare il caso d'uso di estensione.

ad es. considerare "Acquisto laptop" come caso d'uso base e "Garanzia aggiuntiva" come caso d'uso esteso, qui è possibile eseguire il caso d'uso base "Acquisto laptop" anche senza richiedere ulteriore garanzia.

Questa è una grande risorsa con una grande spiegazione: che cosa è includere nel caso d'uso? Che cos'è Extend at use case?

L'estensione del caso d'uso in genere definisce il comportamento facoltativo. È indipendente dal caso d'uso esteso

Includi utilizzato per estrarre parti comuni dei comportamenti di due o più casi d'uso

Diagram Elements

• Attori: noto anche come ruoli. Il nome e lo stereotipo di un attore possono essere modificati nella sua scheda Proprietà.

• Ereditarietà: relazioni di perfezionamento tra attori. Questa relazione può avere un nome e uno stereotipo.

• Casi d'uso: possono avere punti estensione.

• Punti di estensione: definisce una posizione in cui è possibile aggiungere un'estensione.

• Associazioni: tra ruoli e casi d'uso. È utile dare alle associazioni dei nomi che parlano.

• Dipendenze: tra i casi d'uso. Le dipendenze hanno spesso uno stereotipo per definire meglio il ruolo della dipendenza. Per selezionare uno stereotipo, selezionare la dipendenza dal diagramma o dal riquadro di spostamento, quindi modificare lo stereotipo nella scheda Proprietà. Esistono due tipi speciali di dipendenze: <<extend>>e <<include>>, per cui Poseidon offre i propri pulsanti (vedi sotto).

• Estendi relazione: una relazione unidirezionale tra due casi d'uso. Una relazione estesa tra il caso d'uso B e il caso d'uso A significa che il comportamento di B può essere incluso in A.

• Includi relazione: una relazione unidirezionale tra due casi d'uso. Una tale relazione tra i casi d'uso A e B significa che il comportamento di B è sempre incluso in A.

• Bordo del sistema: il bordo del sistema non è attualmente implementato come elemento modello in Poseidon per UML. Puoi semplicemente disegnare un rettangolo, inviarlo allo sfondo e usarlo come bordo del sistema inserendo tutti i casi d'uso corrispondenti all'interno del rettangolo.

Entrambi <include>e <extend>dipendono dalla classe base ma <extend>è facoltativo, cioè è derivato dalla classe base ma dal punto di vista degli utenti può essere usato o non essere usato.

<include>è incorporato nella classe base, vale a dire che è obbligatorio utilizzarlo <include>nel tuo caso d'uso, altrimenti sarebbe considerato incompleto.

per esempio:

Nella costruzione di macchine ATM (secondo il punto di vista degli utenti):

1: Il prelievo, il deposito in contanti e il controllo del conto rientrano <extend>perché dipende dall'utente se ritirare o depositare o controllare. Queste sono cose facoltative che l'utente fa.

2: "Inserisci il segnaposto, posizionando la carta, rimuovendo la carta" queste sono le cose che vanno sotto <include>perché l'utente deve, e dovrebbe, posizionare una carta e inserire un perno valido per la verifica.

Non consiglio l'uso di questo per ricordare i due:

Il mio caso d'uso: vado in città.

include -> guidare l'auto

si estende -> riempire la benzina

Preferirei che usassi: Il mio caso d'uso: vado in città.

si estende -> alla guida dell'auto

include -> riempire la benzina

Mi viene insegnato che estendere la relazione continua il comportamento di una classe base. Le funzionalità della classe base devono essere presenti. Le relazioni di inclusione, d'altra parte, sono simili alle funzioni che possono essere chiamate. Maggio è in grassetto.

Ciò può essere visto dal riutilizzo agilemodeling nei modelli di casi d'uso

La differenza tra entrambi è stata spiegata qui. Ma ciò che non è stato spiegato è il fatto che <<include>>e<<extend>> semplicemente non dovrebbe essere usato affatto.

Se leggi Bittner / Spence sai che i casi d'uso riguardano la sintesi, non l'analisi. Un riutilizzo dei casi d'uso non ha senso. Indica chiaramente che hai tagliato il tuo dominio in modo errato. Il valore aggiunto deve essere univoco di per sé. L'unico riutilizzo del valore aggiunto che conosco è il franchising. Quindi, se sei negli affari degli hamburger, carino. Ma ovunque il tuo compito come BA è quello di cercare un USP. E questo deve essere presentato in casi di buon uso.

Ogni volta che vedo persone che usano una di quelle relazioni è quando provano a fare una decomposizione funzionale. E questo è assolutamente sbagliato.

Per dirla in parole povere: se riesci a rispondere senza esitazione al tuo capo "Ho fatto ...", allora il "..." è il tuo caso d'uso poiché hai i soldi per farlo. (Ciò chiarirà anche che "login" non è affatto un caso d'uso.)

A tale proposito, è molto improbabile trovare casi d'uso autonomi inclusi o estendere altri casi d'uso. Alla fine è possibile utilizzare <<extend>>per mostrare opzionalità del proprio sistema, ad esempio alcuni schemi di licenza che consentono di includere casi d'uso per alcune licenze o di ometterli. Ma altro: evitali.

Extends viene utilizzato quando si comprende che il caso d'uso è troppo complesso. Quindi estrai i passaggi complessi nei loro casi d'uso di "estensione".

Include viene utilizzato quando viene visualizzato un comportamento comune in due casi d'uso. Quindi, estrai il comportamento comune in un caso d'uso "astratto" separato.

(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Analisi dei sistemi e metodi di progettazione, McGraw-Hill / Irwin, 2007)

La relazione include consente a un caso d'uso di includere i passaggi di un altro caso d'uso.

Ad esempio, supponiamo di avere un account Amazon e di voler verificare un ordine, quindi è impossibile controllare l'ordine senza prima accedere al proprio account. Quindi il flusso di eventi vorrebbe così ...

La relazione di estensione viene utilizzata per aggiungere un passaggio aggiuntivo al flusso di un caso d'uso, che di solito è un passaggio facoltativo ...

Immagina che stiamo ancora parlando del tuo account Amazon. Supponiamo che il caso base sia Ordine e il caso d'uso estensione sia Amazon Prime . L'utente può scegliere di ordinare semplicemente l'articolo regolarmente oppure l'utente ha la possibilità di selezionare Amazon Prime che garantisce che il suo ordine arrivi più velocemente a costi più elevati.

Tuttavia, tieni presente che l'utente non deve selezionare Amazon Prime, questa è solo un'opzione, può scegliere di ignorare questo caso d'uso.

Mi piace pensare a "include" come un prerequisito / accompagnamento necessario del caso d'uso di base. Ciò significa che il caso d'uso di base non può essere considerato completo senza il caso d'uso che include. Fornirò l'esempio di un sito Web di e-commerce che vende articoli ai clienti. Non è possibile pagare un articolo senza prima selezionarlo e inserirlo nel carrello. Ciò implica che il caso d'uso "Paga per l'articolo" include "seleziona articolo".

Esistono vari usi degli extender, ma mi piace pensarlo come un'alternativa che può o non può essere utilizzata. Ad esempio, ancora sul sito di e-commerce. Quando si paga un articolo, è possibile scegliere di pagare alla consegna, pagare tramite paypal o pagare con carta. Queste sono tutte alternative al caso d'uso "paga per articolo". Posso scegliere una di queste opzioni in base alle mie preferenze.

Per maggiore chiarezza e le regole relative ai casi d'uso, leggi il mio articolo qui:

http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics