Questa voce o sezione sull'argomento ingegneria del software non cita le fonti necessarie o quelle presenti sono insufficienti.

---

Puoi migliorare questa voce aggiungendo citazioni da fonti attendibili secondo le linee guida sull'uso delle fonti.

In UML, un diagramma dei casi d'uso (o Use Case Diagram, /ju:z keis daiəgraem/, o UCD) è un diagramma dedicato alla descrizione delle funzioni o servizi offerti da un sistema, così come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso. I diagrammi dei casi d'uso impiegati soprattutto nel contesto della Use Case View (vista dei casi d'uso) di un modello, e in tal caso si possono considerare come uno strumento di rappresentazione dei requisiti funzionali di un sistema. Tuttavia, è possibile ipotizzare l'uso degli UCD in altri contesti; durante la progettazione, per esempio, potrebbero essere usati per modellare i servizi offerti da un determinato modulo o sottosistema ad altri moduli o sottosistemi. In molti modelli di sviluppo software basati su UML, la Use Case View e gli Use Case Diagram che essa contiene rappresentano la vista più importante, attorno a cui si sviluppano tutte le altre attività del ciclo di vita del software (processi del genere prendono l'appellativo di processi Use Case Driven).

I model element principali utilizzati nei diagrammi dei casi d'uso UML sono tre: system, actor e use case.

Il sistema nel suo complesso è rappresentato come un rettangolo vuoto. Questo simbolo viene messo in relazione con gli altri nel senso che i model element che rappresentano caratteristiche del sistema verranno posizionati all'interno del rettangolo, mentre quelli che rappresentano entità esterne (appartenenti al dominio o al contesto del sistema) sono posizionati all'esterno. In molti diagrammi UML il simbolo per il sistema viene omesso in quanto la distinzione fra concetti relativi al sistema e concetti relativi al suo contesto si può in genere considerare implicita.

Gli attori sono rappresentati graficamente nel diagramma da un'icona che rappresenta un uomo stilizzato (stickman). Formalmente, un attore è una classe con stereotipo «actor». Praticamente, un attore rappresenta un ruolo coperto da un certo insieme di entità interagenti col sistema (inclusi utenti umani, altri sistemi software, dispositivi hardware e così via). Un ruolo corrisponde a una certa famiglia di interazioni correlate che l'attore intraprende col sistema.

Un caso d'uso è rappresentato graficamente come un'ellisse contenente il nome del caso d'uso. Formalmente, il caso d'uso è un classificatore dotato di comportamento; lo si potrebbe intendere come una classe di comportamenti correlati. Praticamente, un caso d'uso rappresenta una funzione o servizio offerto dal sistema a uno o più attori. La funzione deve essere completa e significativa dal punto di vista degli attori che vi partecipano.

La relazione fondamentale nei diagrammi dei casi d'uso è quella che congiunge gli attori con i casi d'uso a cui essi partecipano, ovvero l'associazione. Un attore può essere associato a un qualsiasi numero di casi d'uso, e viceversa. Pur non richiedendo ulteriori informazioni, l'associazione fra i casi d'uso e gli attori si considera implicitamente dotata di una semantica più specifica rispetto all'associazione generica UML; essa infatti implica uno scambio messaggi fra attori e casi d'uso associati.

Poiché il concetto di attore è derivato da quello di classe, e quello di caso d'uso deriva da quello correlato di classificatore, non deve stupire che possano essere espresse relazioni di generalizzazione sia fra attori che fra casi d'uso. In entrambi i casi, la semantica della generalizzazione può essere dedotta, almeno nelle linee generali, dal principio di sostituzione di Liskov. Un "sottoattore", quindi, deve essere in grado di partecipare a tutti i casi d'uso a cui partecipa il "superattore"; eventualmente può partecipare a use case aggiuntivi, oppure partecipare in modo diverso a qualche use case "ereditato". Un "sotto-caso d'uso" deve fornire lo stesso servizio generale del "super-caso d'uso", eventualmente producendo valore aggiuntivo, o fornendolo a qualche tipologia di attore aggiuntiva; o seguendo un procedimento parzialmente diverso per ottenere il risultato, e così via.

La relazione di inclusione fra casi d'uso, rappresentata da una linea tratteggiata con indicazione dello stereotipo «include», indica che la funzione rappresentata da uno dei due use case (quello alla base della freccia) include completamente la funzione rappresentata dall'altro (quello alla punta). Si può esprimere questa relazione anche con il verbo usa («uses» era uno stereotipo utilizzato in UML prima di «include»), a patto di ricordare che, almeno nel contesto della Use Case View, questo usa dev'essere esente da considerazioni implementative (come riferimenti impliciti al concetto di sottoprogramma).

La relazione di estensione fra casi d'uso, rappresentata da una linea tratteggiata con indicazione dello stereotipo «extend», indica che la funzione rappresentata dal caso d'uso "estendente" (alla base della freccia) può essere impiegata nel contesto della funzione "estesa" (il caso d'uso alla punta della freccia), ovvero ne rappresenta una sorta di arricchimento. Questa relazione viene spesso utilizzata per isolare in un caso d'uso a parte la specifica di attività opzionali o eccezionali che potrebbero aver luogo durante l'espletamento della funzione principale.

Si noti che le relazioni di estensione e inclusione rappresentano concetti piuttosto vicini, ma che l'orientamento delle frecce nei due casi si può descrivere come "opposto". La sottile differenza fra i due stereotipi è la seguente:

• «include» indica un frammento che viene sempre eseguito durante l'esecuzione del caso d'uso alla base della freccia;
• «extend» indica un frammento che può essere eseguito in determinate circostanze del caso d'uso alla punta della freccia.

Un diagramma dei casi d'uso viene generalmente corredato di una modellizzazione complementare che descrive le dinamiche con cui si sviluppano i diversi casi d'uso. Tali dinamiche possono essere espresse in testo libero (usando il tagged value standard Documentation Property) oppure più formalmente attraverso Activity Diagram o altri diagrammi UML dinamici.

Si riportano qui alcuni strumenti open source per la redazione di Use Case Diagram.

• Use Case Maker [1] – Strumento per la redazione di diagrammi dei casi d'uso
• Dia [2] – Programma per la creazione di grafici sviluppato come parte del progetto GNOME

• Wikimedia Commons contiene immagini o altri file su Use Case Diagram

Portale Informatica

Portale Ingegneria