Use Case Diagram
Da Wikipedia, l'enciclopedia libera.
In UML, gli Use Case Diagram (UCD o diagrammi dei casi d'uso) sono diagrammi dedicati alla descrizione delle funzioni o servizi offerti da un sistema, così come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso. Sono 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, non è impossibile 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 processo 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 (si parla di processi use case driven)
Indice |
[modifica] Elementi di modello
I model element principali utilizzati nei diagrammi UML sono tre: system, actor e use case.
[modifica] System
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.
[modifica] Actor
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.
[modifica] Use Case
Un caso d'uso è rappresentato graficamente come un'ellisse contenente il nome del caso d'uso. Formalmente, lo Use Case è un classifier dotato di comportamento; lo si potrebbe intendere come una classe di comportamenti correlati. Praticamente, uno use case 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.
[modifica] Associazioni
[modifica] Actor e use case
L'associazione fondamentale negli Use Case Diagram è quella che congiunge gli attori con i casi d'uso a cui essi partecipano. Un attore può essere associato a un qualsiasi numero di casi d'uso, e viceversa. Pur non richiedendo ulteriori informazioni, l'associazione fra gli use case e gli actor si considera implicitamente dotata di una semantica più specifica rispetto all'associazione generica UML; essa infatti implica uno scambio messaggi fra attori e use case associati.
[modifica] Generalizzazione
Poiché actor è un concetto derivato da quello di classe, e use case deriva da quello correlato di classifier, 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 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.
[modifica] Inclusione
La relazione di inclusione fra use case, 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 scevro da considerazioni implementative (come riferimenti impliciti al concetto di sottoprogramma).
[modifica] Estensione
La relazione di estensione fra use case, rappresentata da una linea tratteggiata con indicazione dello stereotipo «extend», indica che la funzione rappresentata dallo use case "estendente" (alla base della freccia) può essere impiegata nel contesto della funzione "estesa" (lo use case alla punta), ovvero ne rappresenta una sorta di arricchimento. Questa relazione viene spesso utilizzata per isolare in uno use case 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".
[modifica] Esempio
[modifica] Descrizione dinamica
Uno Use Case Diagram viene generalmente corredato di una modellizzazione complementare che descrive le dinamiche con cui si sviluppano i diversi use case. 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.
