Diagrammi dei casi d'uso UML

In questa pagina viene brevemente discussa la problematica della raccolta e analisi dei requisiti di un software. Affinché tale operazione risulti pienamente efficace, si deve procedere alla documentazione di tali requisiti. In questo pagina discutiamo ciò che lo standard UML mette a disposizione a questo scopo: i diagrammi dei casi d’uso (use-case diagram).

Come tutti i diagrammi UML, anche i diagrammi dei casi d’uso sono rappresentazioni grafiche che seguono specifiche regole. I diagrammi dei casi d’uso contengono informazioni su:

• il sistema software in esame,
• gli attori che interagiscono con il sistema,
• i casi d’uso che coinvolgono gli attori ed il sistema e
• le relazioni tra casi d’uso e tra attori.

Cominciamo con il semplice esempio semplice mostrato nella figura sottostante.

Il diagramma è tutto contenuto in un rettangolo che rappresenta l’intero caso d’uso, in questo caso Videogame use case. All’interno di questo rettangolo troviamo un ulteriore zona denominata nell’esempio System boundary che rappresenta schematicamente il sistema software. Può succedere che questa delimitazione (sia del caso d’uso, sia del sistema) venga omessa in quanto sottintese.

La parte più importante del diagramma è rappresentata dagli attori indicati con delle persone stilizzate e u casi d’uso indicate con degli ovali. Nella figura sopra abbiamo un solo attore Player e 5 casi d’uso Start game, Load game, New game, Save game e View score. Inoltre esistono collegamenti di due tipi: uno tra attori e casi d’uso e uno tra casi d’uso. Un collegamento tra un attore e un caso d’uso indica che quell’attore interagisce con il sistema facendo un’azione che è indicata nel collegamento. Ad esempio nella figura vediamo che Player interagisce con il sistema premendo il bottone start (azione hits "start") a cui il sistema risponde attivando la procedura Start game. Il secondo tipo di collegamento, rappresentato da una freccia tratteggiata con etichetta <<extend>>, indica una relazione di specializzazione tra casi d’uso. Nell’esempio vediamo che ci Start game ha due possibili specializzazioni Load game e New game ad indicare la possibilità di iniziare un gioco precedentemente salvato o un nuovo gioco. Chiaramente entrambe queste azioni sono un “inizio di gioco”, ma il sistema farà operazioni diverse nei due casi, per questo motivo vengono suddivisi in casi specializzati.

Dall’analisi dei requisiti al diagramma dei casi d’uso

Vediamo ora come si possa procedere a descrivere i requisiti di un software in forma di diagramma UML dei casi d’uso. Consideriamo la seguente specifica del comportamento di una parte di un software gestionale.