Usa diagramma del caso (UML): la memoria del database dovrebbe essere un caso di uso secondario (in questo diagramma)?

Il diagramma dei casi d'uso fornisce una panoramica dei requisiti e illustra come i vari attori interagiscono tramite il sistema.

Esistono molti modi per acquisire effettivamente casi d'uso. Un aspetto importante sono le storie utente a frase singola . Ad esempio: "Come utente, voglio cercare gli ORF". Questo è un caso d'uso valido. Ora stai proponendo un caso d'uso come "Come utente, voglio salvare i dati nel database". potrebbe essere un caso d'uso valido, ma in realtà non sembra.

Questo è più chiaro se usiamo un formato di caso d'uso tabellare. Qui, elenchiamo esplicitamente i passaggi che l'utente esegue e come risponde il sistema. Ad esempio:

Search ORFs

Precondition: A file is loaded.

Primary Actor: User

Trigger: The User clicks on the “search” button.

Scenario:

1. The User enters an ORF into the search box and submits the search.
2. The System displays a list of all matching sequences in the loaded file.

Postcondition: The system can receive the next search query.

Alcuni passaggi in questo scenario potrebbero essere così complessi da essere descritti in un altro caso d'uso che verrebbe quindi incluso. Ma un caso d'uso è sempre un'interazione tra attore e sistema. Se hai un "salva dati nel database" usa il caso in cui l'utente fa clic su un pulsante "salva in DB", quindi potresti avere un vero caso d'uso. Altrimenti, il database è solo un dettaglio di implementazione.

Il fatto che il database sembri essere importante per i tuoi utenti potrebbe significare che non hai effettivamente catturato tutti i casi d'uso. Si cita il vincolo che il database deve essere in esecuzione affinché tali casi d'uso possano funzionare: si tratta di una precondizione o forse di uno scenario di eccezione. Potremmo estendere il caso d'uso sopra descritto con un flusso alternativo:

Exceptions:

2. If the database is offline or returns an error, the System displays an error message to the User.

Se un controllo "il database non è in linea" è comune a molti casi di utilizzo, è possibile estrarre tale passaggio comune in un caso di utilizzo condiviso. Per esempio. per le applicazioni web, dovremmo estrarre il controllo "l'utente ha effettuato l'accesso" in un caso d'uso separato invece di ripeterlo in ogni caso d'uso.

Qual è l'interesse dell'utente qui? Non vogliono entrare in una ricerca se non è possibile rispondere. Quindi il caso d'uso in realtà è "Come utente, voglio vedere un avviso quando il database è inattivo" o "Come utente, voglio essere impedito di cercare quando il database è inattivo".

Direi che UC_07 forse non è affatto necessario se fa parte del sistema nel suo complesso.

Anche molti casi d'uso sono letti come una sequenza di passaggi che appartengono più propriamente a un diagramma di sequenza. Ma in realtà dipende da quanti diagrammi UML stai usando.

Potresti anche creare un caso per la rimozione delle applicazioni di avvio e di chiusura poiché questo è un dato se stai utilizzando l'applicazione stessa.

I casi d'uso e i modelli di casi d'uso servono a descrivere alcuni aspetti dei requisiti funzionali di un sistema. In quanto tali, dovrebbero concentrarsi su che dovrebbe fare il sistema dal punto di vista del business. Soprattutto non dovrebbero riguardare come il sistema funziona internamente, che è una questione di progettazione del software .

Oggetti tecnici come l'apertura di connessioni al database e la gestione di errori imprevisti appartengono per lo più al dominio del design piuttosto che ai requisiti.