analisi-disegno.com

Homepage  | Blog | Per essere avvisati in caso di nuovi documenti | In English

Ambito di applicazione dei casi d'uso

I casi d'uso vanno bene per descrivere i requisiti di ogni sistema? No.

I casi d'uso vanno bene per descrivere tutte le funzionalità di un sistema? No.

Qualcuno, iper-semplificando, pensa che i casi d'uso siano adatti a descrivere tutti i requisiti, tutte le possibili funzionalità, tutti i possibili sistemi. Non è vero.

C'è sistema e sistema

I casi d'uso vanno bene per descrivere le modalità di utilizzo di un sistema:

  • che abbia interazioni significative con qualcuno o qualcosa di esterno ad esso (gli attori)
  • in cui le interazioni siano di tipo operativo e strutturato

Esistono altre tipologie di sistemi, per le quali i casi d'uso sono meno adatti. Alcuni esempi:

  • Sistemi web (o parti di essi) costituiti esclusivamente da pagine statiche
  • Videogame "dinamici"
  • Sistemi di data warehouse
  • Sistemi CAD (Computer-aided Design)
  • Compilatori
  • ...

Per queste tipologie di sistemi, e consimili, i casi d'uso possono essere anche definiti, volendo. Sicuramente, però, non possono aiutare a specificare la maggior parte dei requisiti.

C'è funzionalità e funzionalità

I casi d'uso, secondo UML, possono essere usati per descrivere le modalità di utilizzo di qualunque sistema, a qualunque livello di dettaglio.

Esempi:

  • un sistema costituito da un unico modulo software, che contenga un algoritmo di calcolo più o meno complesso, e che venga richiamato da uno o più altri moduli
  • un modulo software che effettui accessi ad una serie di archivi, su richiesta di altri moduli
  • una singola classe, in un contesto object oriented

E' possibile specificarne la modalità di utilizzo in termini di casi d'uso?

Teoricamente sì, non c'è dubbio. Ma è utile?

I casi d'uso servono a descrivere la logica di interazione tra il sistema e ciò che è esterno ad esso. Non a specificare la logica interna di una qualunque funzionalità o di una qualunque parte di sistema. Esistono altre tecniche molto più adeguate, per farlo. Ad esempio i diagrammi di flusso (flow-chart), presenti anche in UML con il nome di activity diagram.

Torna a pagina introduttiva casi d'uso

analisi-disegno.com, servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.