Estensione nel diagramma dei casi d'uso: esempio di gestione della libreria?

Ci sono due relazioni in un diagramma dei casi d'uso: includi ed estendi.

La relazione di estensione viene utilizzata quando un caso d'uso aggiunge un comportamento a un altro caso d'uso. In questa situazione, il caso base verrebbe eseguito. Quindi, a seconda di cosa accade durante l'esecuzione di quel caso d'uso, potrebbero essere eseguiti uno o più altri casi d'uso. Si noti che non è richiesto che un'estensione venga effettivamente eseguita - è solo una possibilità. Ciò indica anche un certo livello di riutilizzo tra le funzionalità.

La relazione include viene utilizzata quando un caso d'uso include la funzionalità di un altro caso d'uso. Il comportamento specifico non è importante, ma il risultato finale è, il che significa che il caso d'uso incluso potrebbe avere un'implementazione diversa, ma gli stessi passaggi e il risultato finale. In questo tipo di relazione, il caso d'uso incluso di solito non è disponibile come caso d'uso autonomo.

Guardando il tuo esempio particolare, ho sviluppato due modelli di casi d'uso che ritengo più appropriati. In entrambi, ho cambiato l'attore da "Membro" a "Bibliotecario". Sembra che la persona che interagisce effettivamente con il software non sia il membro della biblioteca, ma il bibliotecario.

Inquestoesempio,ilBibliotecariopuòeseguireduefunzioni:controllareunlibrooprenotareunlibro.Entrambigliesempirichiedonoalbibliotecariodiconsultareillibroutilizzandoleinformazionifornitedalmembro.Tuttavia,lafunzionalitàdiricercanonèdisponibilecomeentitàautonoma.Nonsonosicurochequestoèciòchestaiper.

In questo esempio, il Bibliotecario può eseguire tre funzioni: cercare libri, controllare libri e registrare prenotazioni. Sia la verifica dei libri che la registrazione delle prenotazioni utilizzano il caso di utilizzo del libro, ma aggiungono ulteriori comportamenti. I dettagli dell'implementazione sono lasciati come esercizio per ulteriori specifiche, ma questo indica che al fine di controllare un libro o effettuare una prenotazione, il bibliotecario deve prima cercare il libro. Credo che questo sia più in linea con la funzionalità che stai descrivendo nella tua domanda.

Mi è capitato di imbattermi ultimamente mentre studiavo sul design OO.

I have problem to understand the extension relation in the use case diagrams, sometimes some relations seem extension.

Esiste una relazione di estensione se un caso d'uso estende il comportamento di un altro. Il primo è l'estensione, e il secondo è la base. Nelle relazioni estese, la base è indipendente e significativa di per sé. Questo non è il caso dell'estensione, dipende dalla base. Non resiste da solo.

In general what are rules of thumb to find out extension relation?

Utilizza una relazione di estensione quando un caso d'uso ha un comportamento che è facoltativo o quando ha un comportamento che viene eseguito solo in determinate condizioni.

Could the reservation be the extend of borrow?

Se un socio può effettuare una prenotazione indipendentemente (per qualsiasi ragione) anche se il libro è disponibile (come ha raggiunto il limite di prestito), allora no, la prenotazione non può essere l'estensione del prestito. La riserva può reggersi da sola. Un membro può effettuare una prenotazione senza dover prendere in prestito. Altrimenti, sì, è un'estensione del prestito perché viene eseguita solo quando si prende in prestito un libro che non è disponibile. Spero che questo aiuti.

Oh, e nel caso in cui la riserva sia un'estensione del prestito, non disegnarla come hai fatto nel tuo diagramma. Per mostrare la relazione di estensione, l'estensione si connette alla base con una freccia aperta. Aggiungi la parola chiave extend. La freccia punta dall'estensione alla base.

Dico che non dovresti preoccuparti di cercare di capire se dovresti usare extends / includes. Questo ti fa solo perdere l'attenzione su ciò che stai veramente cercando di realizzare, che è descrivere ciò che il tuo sistema deve essere in grado di fare. Hanno i loro usi benefici "rari" ma questa è l'eccezione. Sicuramente non ne hai bisogno per ogni banale passo "comune".

Ero solito rimuginare su quei dettagli fino a quando ho realizzato "a posteriori" che non aggiungono molto valore al processo generale e concentrarsi su di essi finisce per spingerti verso dettagli di implementazione che non dovresti davvero preoccuparti di a livello del caso d'uso. Ad esempio, sebbene il design possa riservare un libro allo stesso modo, indipendentemente dal modo in cui ci si è arrivati, una volta che si inizia a progettare, si può scoprire che non è possibile farlo allo stesso modo. Ora devi "estendere" il caso d'uso perché hai preso una decisione di progettazione a livello dei requisiti.

Quando è appropriato usare extends / include YOU WILL KNOW, non dovrai chiedertelo se lo userò o meno.

Per rispondere direttamente alla tua domanda "quali sono le regole": se non è chiaro, non preoccuparti.

Inoltre, proprio come una FYI, i passaggi 1 e 2 dovrebbero semplicemente essere "Richieste di membri per prenotare il libro" / "Richieste di membri al libro in prestito". Le vostre descrizioni non hanno un'azione chiara iniziale per iniziare ogni caso d'uso particolare, che è essenziale per scrivere casi d'uso buoni e utili.

Inoltre, non è necessario menzionare "informazioni del libro" che sono già implicite nella richiesta. Una volta che si inizia ad analizzare il caso d'uso e si fa il disegno, si identificheranno le informazioni richieste dalla richiesta.