Il diagramma dei casi d'uso è una vista utilizzata per descrivere le funzioni del sistema composte da attori, casi d'uso e la relazione tra loro. È osservabile da utenti esterni chiamati diagrammi del modello della funzionalità del sistema. I diagrammi dei casi d'uso vengono spesso utilizzati durante la fase di analisi dei requisiti.
Prima di sviluppare un sistema, il compito più importante è ottenere le esigenze degli utenti, e la più importante tra le esigenze degli utenti sono i requisiti funzionali del sistema proposti dagli utenti. Possiamo utilizzare i diagrammi dei casi d'uso per esprimere visivamente le esigenze degli utenti.
Diagramma visivo dei casi d'uso
Gli elementi principali in un diagramma dei casi d'uso includono attori, casi d'uso e relazioni tra gli elementi. Oltre a ciò, i diagrammi dei casi d'uso possono contenere anche annotazioni e vincoli.
1. Concetto di partecipanti
Gli attori sono entità esterne che interagiscono con il sistema principale. I partecipanti possono essere persone, sottosistemi, altri sistemi, ecc. al di fuori del sistema.
Ogni attore è in realtà un set di ruoli. In UML, un attore viene rappresentato graficamente utilizzando una forma umana e gli viene dato un nome. Come mostrato nell'immagine qui sotto, il "lettore" è un partecipante al sistema di prestito della biblioteca.
attori del diagramma dei casi d'uso
Gli attori dovrebbero essere al di fuori dei confini del sistema, non parte del sistema.
2. Come identificare i partecipanti
Quando si esegue la modellazione dei casi d'uso, identificare gli attori è il primo passo nella modellazione dei diagrammi dei casi d'uso. Quindi, come determinare i partecipanti al sistema ? Possiamo pensarci dalle seguenti idee:
(1) Gli oggetti di servizio del sistema, come i lettori nel sistema di prestito della biblioteca;
(2) Persone che forniscono supporto per completare il lavoro, come il personale della biblioteca nel sistema di prestito della biblioteca, che ha bisogno di utilizzare il sistema per aiutare i lettori a completare il prestito, la restituzione dei libri e i promemoria;
(3) Manutentore del sistema: la persona responsabile dell'installazione, della manutenzione e della gestione del sistema. In questo caso, il sistema deve fornire funzioni pertinenti per aiutare tale personale a completare il lavoro di installazione, manutenzione e gestione;
(4) Dispositivi esterni: necessità di trasmettere informazioni o leggere informazioni da dispositivi esterni, come lettori di carte;
(5) Altri sistemi o sottosistemi: come il sistema finanziario nel sistema dei prestiti. Il sistema finanziario non è una funzione del sistema dei prestiti, ma il sistema dei prestiti deve trasmettergli informazioni per completare il lavoro dovuto in ritardo;
(6) Orario: in un momento programmato, si verifica automaticamente un evento specifico, come backup automatico, promemoria regolare, ecc.;
(7) Eventi specifici: ad esempio, la ricezione automatica degli ordini nel sistema di asporto è guidata da eventi di generazione degli ordini.
Quando identifichi i partecipanti , tieni presente quanto segue:
(1) I partecipanti si trovano all'esterno del sistema, non fanno parte del sistema;
(2) I partecipanti interagiscono con il sistema attraverso i confini del sistema;
(3) Sebbene le icone dei partecipanti siano rappresentate da icone a forma umana, i partecipanti non sono necessariamente persone e possono anche essere altri sottosistemi, altri sistemi, tempo, temperatura e altri fattori.
3. Relazioni tra i partecipanti
La relazione principale tra i partecipanti è la generalizzazione. La generalizzazione è rappresentata da una freccia triangolare aperta che punta a partecipanti più generali e termina all'estremità del partecipante “specifico”. Una relazione di generalizzazione è una relazione tra il generale e il particolare (concreto). In una relazione di generalizzazione, una descrizione astratta di un partecipante può essere condivisa da uno o più partecipanti concreti. La figura seguente illustra le relazioni generalizzate tra i partecipanti a un sistema di prestito bibliotecario:
Rapporto di generalizzazione tra i partecipanti al sistema di prestito bibliotecario
in pensione , ecc. sotto il lettore sono partecipanti "specifici". La generalizzazione del partecipante può essere intesa come: un partecipante "specifico" è un partecipante "generale", come un membro della facoltà che è una sorta di lettore. Nella generalizzazione degli attori, i casi d'uso eseguibili da un attore "generale" sono rappresentati come eseguibili da un attore "concreto" ("speciale").
1. Il concetto di casi d'uso
Un caso d'uso è un servizio di sistema o un'unità funzionale che può essere sperimentata dai partecipanti. Definisce un obiettivo che il sistema deve raggiungere. Un caso d'uso definisce solo un comportamento del sistema ma non rivela la struttura interna del sistema.
Il più grande vantaggio dei casi d'uso è che descrivono le funzioni del sistema dal punto di vista dell'utente. Graficamente, un caso d'uso è rappresentato da un'ellisse solida con il nome del caso d'uso all'interno o sotto l'ellisse:
Caso d'uso del prestito di libri
2. Identificare i casi d'uso
I casi d’uso possono essere identificati attraverso i seguenti punti:
(1) Di quali funzioni ha bisogno il partecipante dal sistema per supportare il suo lavoro?
(2) I partecipanti devono interrogare alcune informazioni nel sistema?
(3) I partecipanti devono modificare alcune informazioni nel sistema, come creare, modificare ed eliminare operazioni?
(4) I partecipanti devono essere informati di eventi specifici o cambiamenti nello stato del sistema?
(5) Quali eventi esterni nel sistema spingeranno il sistema a svolgere funzioni rilevanti in risposta?
(6) Il sistema fornisce funzioni rilevanti per aiutare il personale di manutenzione a effettuare la manutenzione del sistema?
3. Punti chiave di identificazione dei casi d'uso
(1) I casi d'uso identificati dovrebbero riflettere gli obiettivi del sistema, ovvero "cosa fare" piuttosto che "come farlo", il che significa che i casi d'uso non sono dettagli dell'implementazione del sistema;
(2) Definire i casi d'uso dal punto di vista dei partecipanti (utenti) piuttosto che dal punto di vista del sistema;
(3) i casi d’uso dovrebbero fornire risultati preziosi ai partecipanti, piuttosto che una raccolta di azioni;
(4) Evitare di cadere nella scomposizione funzionale e nella scomposizione graduale;
(5) Ciascun partecipante dovrebbe avere un caso d'uso eseguibile e ciascun caso d'uso dovrebbe essere associato ad almeno un partecipante.
4. Denominazione dei casi d'uso
Dopo aver determinato i casi d'uso del sistema, è necessario nominare ciascun caso d'uso. La denominazione dei casi d'uso deve descrivere gli obiettivi raggiunti dai partecipanti dal punto di vista dell'utente. È possibile utilizzare i seguenti metodi di denominazione:
verbo + oggetto
Cioè, il nome del caso d'uso dovrebbe essere sotto forma di una frase verbo-oggetto. Come scegliere i corsi, prendere in prestito libri, ordinare beni e pagare con carte di credito.
5. Granularità dei casi d'uso
La granularità dei casi d'uso si riferisce al grado in cui un caso d'uso perfeziona o integra le funzioni del sistema. Si può anche dire che sia il numero di servizi di sistema o unità funzionali inclusi in un caso d'uso. Se la granularità del caso d'uso è troppo grossolana o troppo ampia, il caso d'uso conterrà più funzioni di sistema e viceversa. Se la granularità dei casi d’uso è troppo grossolana, sarà difficile comprendere il sistema. Se la granularità è troppo fine, il modello dei casi d’uso sarà troppo grande, il che comporterà difficoltà nella progettazione. Se il caso d'uso è troppo dettagliato, potrebbe cadere in una scomposizione funzionale, come ad esempio:
Granularità dei casi d'uso iniziale
In effetti, molte attività nel sistema includono tali operazioni di aggiunta, eliminazione, modifica e controllo. Ciò non può fornire obiettivi significativi per gli utenti, ma ignorerà il reale scopo degli utenti.
Il suddetto "aggiungere, eliminare, modificare e controllare" non è altro che la gestione degli utenti, che è il vero scopo dei partecipanti. Potrebbe essere meglio gestire il caso d'uso di cui sopra nel modo seguente:
Riduzione della granularità dei casi d'uso
Il caso d'uso Gestisci utenti rappresenta un obiettivo o un'attività per gli amministratori di sistema. Se si devono aggiungere aggiunte, cancellazioni, modifiche e quesiti è meglio esprimerlo nel modo seguente.
Ottimizzazione della granularità del caso d'uso successivo
Un altro errore spesso commesso nella modellazione dei casi d’uso è quello di trattare i passaggi come casi d’uso. Ad esempio, il seguente sembra perfetto, ma è ovvio che i passaggi operativi sono considerati casi d'uso:
Passaggi operativi come esempi di errori di casi d'uso
I passaggi precedenti non sono altro che il completamento dell'obiettivo dell'utente come partecipante: la registrazione. Pertanto, dovrebbe essere modificato come segue:
Dopo l'ottimizzazione del caso d'uso
Nella modellazione dei casi d’uso, il terzo errore comune è trattare le attività del sistema come casi d’uso. Nel diagramma dei casi d'uso riportato di seguito, la creazione di oggetti di connessione, la creazione di oggetti di comando e l'esecuzione di istruzioni SQL sono attività all'interno del sistema che non possono essere percepite dall'utente. Non sono lo scopo dell'utente e all'utente non interessa. Quindi questo diagramma del caso d'uso è impreciso:
Esempio di errore del caso d'uso dell'attività di sistema
Il quarto errore comune nella modellazione dei casi d’uso è nominare i casi d’uso utilizzando una prospettiva di sistema.
Utilizzare la prospettiva del sistema per nominare esempi di errori di casi d'uso
Dei due diagrammi dei casi d'uso sopra riportati, qual è il migliore? Ovviamente, quello a destra è migliore di quello a sinistra, perché il caso d'uso a destra ha un nome dal punto di vista dell'utente, mentre il caso d'uso a sinistra ha un nome dal punto di vista del sistema, e gli utenti si sentiranno confusi dopo vederlo.
6. Specifica del caso d'uso
Il diagramma dei casi d'uso descrive generalmente i requisiti funzionali dell'utente (funzioni o servizi forniti dal sistema), ma ogni caso d'uso deve essere descritto in dettaglio in modo che le persone sappiano cosa dovrebbe fare specificamente il caso d'uso. In altre parole, il modello dei casi d’uso consiste essenzialmente in un diagramma dei casi d’uso e in una descrizione dettagliata di ciascun caso d’uso (specifica dei casi d’uso).
Una specifica del caso d'uso dovrebbe contenere il seguente contenuto:
(1) L'identificazione e il nome del caso d'uso;
(2) Partecipanti coinvolti nel caso d'uso;
(3) Una breve descrizione del caso d'uso;
(4) Altri casi d'uso correlati;
(5) Precondizioni per l'esecuzione del caso d'uso
(6) Flusso degli eventi di base;
(7) Flusso di eventi alternativo;
(8) Post-condizioni per l'esecuzione del caso d'uso;
(9) Altre informazioni, quali requisiti non funzionali, vincoli di progettazione, stato di revisione dei casi d'uso, preparatore, record di modifiche, ecc.
Le relazioni tra i casi d'uso comprendono principalmente tre tipologie: generalizzazione, inclusione ed espansione.
Quando più casi d'uso hanno attributi o comportamenti simili, possiamo astrarre la loro comunanza in un caso d'uso principale e altri casi d'uso come casi d'uso secondari di una relazione di generalizzazione. I casi d'uso secondari ereditano gli attributi e i comportamenti nel caso d'uso principale. La relazione di generalizzazione dei casi d'uso può essere intesa come diversi percorsi di implementazione per lo stesso scopo aziendale.
La relazione di generalizzazione è rappresentata graficamente da un'implementazione con una freccia a triangolo cavo che punta dal caso d'uso figlio al caso d'uso genitore.
Relazione di generalizzazione del diagramma dei casi d'uso
Nell'esempio precedente, " Metodo di pagamento 1 " e " Metodo di pagamento 2 " sono casi di sottouso di "Pagamento". Il caso d'uso principale "Pagamento" non fornisce metodi di pagamento specifici, ma fornisce solo gli attributi e le interfacce necessarie per il pagamento e implementa funzioni di pagamento specifiche nei casi d'uso secondari.
Durante il processo di modellazione del sistema, alcune funzioni devono essere utilizzate ripetutamente in diversi scenari aziendali. Queste funzioni utilizzate ripetutamente possono essere separate per formare un caso d'uso separato e, quando si eseguono funzioni correlate, le funzioni pubbliche separate possono essere incluse nel processo principale. La relazione di inclusione dei casi d'uso può descrivere questa situazione. Inoltre, se un caso d'uso di base ha troppe funzioni, può anche essere suddiviso in più piccoli casi d'uso. I casi d'uso contenuti sono chiamati casi d'uso del provider, mentre i casi d'uso che contengono altri casi d'uso sono chiamati casi d'uso del client.
In UML, la relazione di inclusione è rappresentata da una freccia tratteggiata con lo stereotipo <<include>>. La freccia punta dal caso d'uso di base (incluso caso d'uso/caso d'uso del cliente) al caso d'uso incluso (caso d'uso del fornitore).
Il diagramma dei casi d'uso contiene relazioni
Di seguito è riportato un esempio specifico. In questo esempio, il lettore desidera prendere in prestito i libri. Deve eseguire il caso d'uso del libro delle query prima di poter prendere in prestito il libro. Pertanto, il caso d'uso del libro delle query verrà incluso nel file caso d'uso del pre-prestito del libro Allo stesso tempo, il lettore deve: Quando prende in pre-prestito i libri, deve aver effettuato l'accesso al sistema e il sistema ha salvato il suo stato di accesso prima di poter eseguire l'operazione di pre-prestito, quindi il caso d'uso della verifica dell'identità sarà incluso anche nel caso d'uso del libro pre-prestito. Interrogare i libri non è solo una funzione di base richiesta da un lettore, ma anche un processo operativo necessario per altre funzioni. La verifica dell'identità non viene utilizzata solo durante il pre-prestito dei libri, ma anche quando si eseguono funzioni come interrogare i registri di prestito e pagare le multe. È più appropriato proporre la verifica dell'identità separatamente per formare un caso d'uso:
Rapporto di inclusione del libro in prestito anticipato del lettore
I casi d'uso di base forniscono punti di estensione, in cui è possibile aggiungere nuovi comportamenti. I casi d'uso di estensione forniscono una serie di frammenti di inserimento che possono essere inseriti nei punti di estensione del caso d'uso di base.
· Il caso d'uso di base fornisce solo punti di estensione senza conoscere alcun dettaglio del caso d'uso di estensione.
· Un caso d'uso base è completo anche senza un caso d'uso esteso, a differenza di una relazione di inclusione.
· Un caso d'uso può fornire più punti di estensione e ciascun punto di estensione può apparire più volte.
· In circostanze normali, l'esecuzione del caso d'uso di base non coinvolgerà il caso d'uso esteso. Le funzioni del caso d'uso esteso verranno eseguite solo quando si verificano condizioni o eventi specifici.
In UML, una relazione di estensione è rappresentata da una freccia tratteggiata con lo stereotipo <<extend>>. Le frecce indicano dai casi d'uso estesi ai casi d'uso di base.
Utilizzare la relazione di estensione del diagramma dei casi
L'esempio seguente è un frammento del diagramma dei casi d'uso in un sistema di prestito di biblioteca:
I lettori pagano multe per espandere le relazioni
In questo esempio, il pagamento di una multa è un caso d'uso di base per il lettore e un caso d'uso esteso per la restituzione del libro. Il "Pagamento della multa", come caso d'uso esteso della "Restituzione dei libri", verrà eseguito solo alle seguenti condizioni:
(1) I libri del lettore sono scaduti o hanno precedenti penali per altri motivi e non sono stati pagati per intero;
(2) Il lettore sceglie di pagare la multa contestualmente alla restituzione del libro.
Quanto sopra è il contenuto rilevante sui diagrammi dei casi d'uso UML. Tutti i casi dei diagrammi dei casi d'uso sopra riportati vengono disegnati utilizzando ProcessOn.
Mappa Mentale e Diagramma di Flusso Collaborativi Online Gratuiti Uso gratuito 
