Nei progetti con molti casi d'uso, è valido creare diversi diagrammi di casi d'uso, uno per ogni schermo? O non dovrei guidarmi sulla GUI del software per farlo, perché?
Come chiarimento, il software esiste già e sto solo documentandolo per il mio progetto finale di laurea.
Poiché non esiste una relazione intrinseca tra un caso d'uso e uno schermo GUI, non ha realmente senso dividere i diagrammi del caso d'uso con la schermata della GUI a cui si riferiscono.
Per elaborare, un caso d'uso descrive come un attore esterno (una macchina o un essere umano) interagisce con un sistema per raggiungere un obiettivo particolare per quell'attore esterno. Se il caso d'uso non implica un'interazione con un essere umano, non ci sono nemmeno schermate della GUI. E se il caso d'uso fa coinvolge un attore umano, allora la GUI potrebbe essere qualsiasi cosa, da un singolo pulsante (ad esempio, per stampare il documento corrente alla stampante predefinita) a più schermate (es. in un IDE).
I buoni casi d'uso non menzionano nemmeno l'esistenza di una GUI. Specifica solo che l'attore X fornisce A, B e, opzionalmente, informazioni su C e lascia il come per il team di progettazione.
Se ci sono molti casi d'uso, può essere utile suddividerli in più diagrammi, ma ciò non dovrebbe basarsi su una scelta progettuale (come è organizzata la GUI). Le linee di divisione migliori sono
Penso che ti troverai nei guai mentre progetti un'applicazione pensando che esista una strong relazione tra i requisiti delle attività di un'applicazione e il numero di schermate (moduli, pagine Web, ecc.). Anche le semplici app CRUD hanno quell'unica esigenza con troppa complessità da gestire in questo modo.
Prendi l'esempio di una semplice griglia di inserimento dati con la possibilità di modificare i dati in linea. Abbastanza facile da avere un pulsante di aggiornamento, i controlli sono modificabili e ci sono i pulsanti Salva e Annulla. Per qualsiasi motivo, questo è fonte di confusione per gli utenti, quindi decidi di avere una schermata separata del record aggiornato. Non vedo perché dovresti tornare indietro e modificare il diagramma del caso d'uso poiché l'utente sta compiendo lo stesso compito.
Che cosa succede se inizi a utilizzare un fornitore di dati esterno (sito di quotazione di borsa) che aggiornerà questi dati attraverso un servizio? Ciò richiede di creare un altro caso d'uso, ma non ci sono schermate aggiuntive.
Molti sviluppatori possono entrare in questa trappola anche con la progettazione di basi dati. Non si crea automaticamente un nuovo modulo di immissione dati per ogni tabella e ogni modulo non richiede una tabella di database.
Sono d'accordo con Bart - i casi d'uso non sono suddivisi per schermata, si tratta di ciò che si vuole realizzare. Ad esempio, potresti avere un caso d'uso che descrive quali dati un cliente fornisce per creare un profilo cliente o quali dati l'utente fornirebbe per effettuare un pagamento.