Come determinare cosa aggiungere ai diagrammi dei casi d'uso? 1 per ogni pulsante/modulo? Dovrebbero essere incluse cose come sort e search? O sono sotto "lista articoli" per esempio? Tuttavia, un elenco di elementi sembra essere capito?Caso Granularità di utilizzo. Dovrebbe essere ordinato/cercare?
Il diagramma Caso di utilizzo ha lo scopo di aiutare a definire le attività aziendali di alto livello che sono importanti, non un elenco di funzioni del sistema. Ad esempio, un sistema per l'utilizzo nel servizio clienti potrebbe comportare un compito di ricerca di ricerca di informazioni per aiutare qualcuno su una chiamata di supporto.
La maggior parte della letteratura descrive casi d'uso come punto di partenza per definire ciò che il sistema deve realizzare. La tentazione è sempre stata quella di essere il più completo possibile; aggiungendo sempre più dettagli per definire il caso d'uso fino a un livello funzionale (in termini di codice). Sebbene sia utile avere una comprensione completa dei requisiti, il diagramma Use Case non è inteso a fornire quel livello di documentazione.
Una cosa che peggiora il problema è la sintassi che non ho mai visto utilizzata in un progetto di lavoro. Non è che i termini non siano utili, è dovuto alla mancanza di consenso su quando usare entrambi i termini per un determinato caso d'uso. Gli artefatti UML prevedono un processo più incentrato sulla lingua aziendale anziché sul linguaggio di implementazione, e con ciò non intendo un linguaggio informatico. La tendenza di alcuni è stata quella di avvicinarsi ai diagrammi con una tendenza legalistica e preoccuparsi di cose come quando utilizzare per casi d'uso correlati o come esprimere la gestione degli errori come eccezioni a un elenco definito di attività di processo.
Se hai mai provato a utilizzare l'esempio di Automated Teller Machine (ATM), saprai cosa intendo. Nel sistema solare di apprendimento UML, l'esempio di ATM è un buco nero che ti risucchia nei dettagli. Evita di usarlo per comprendere UML o l'analisi e la progettazione orientata agli oggetti. Ha molti dei problemi, tipici dei domini del mondo reale, che distolgono dall'ottenere una comprensione generale anche se sarebbe un buon studio avanzato.
Sì, il codice verrà prodotto dagli artefatti UML, ma ciò non significa che debbano essere discussi come un trattato al Senato.
Il OMG UML spec dice:
I casi d'uso sono un mezzo per specificare usi il termine di un sistema. In genere, vengono utilizzati per acquisire i requisiti di un sistema, ovvero, cosa deve fare un sistema. I concetti chiave associati ai casi d'uso sono attori, casi d'uso e soggetto. L'argomento è il sistema in esame a cui si applicano i casi d'uso. Gli utenti e tutti gli altri sistemi che possono interagire con il soggetto sono rappresentati come attori. Gli attori modellano sempre le entità esterne al sistema.
Il comportamento richiesto del soggetto è specificato da uno o più casi d'uso, definiti in base alle esigenze degli attori. A rigor di termini, il termine "caso d'uso" si riferisce a un tipo di caso d'uso. Un'istanza di un caso d'uso fa riferimento a un'occorrenza del comportamento emergente conforme al tipo di caso d'uso corrispondente. Tali istanze sono spesso descritte dalle specifiche di interazione.
Un attore specifica un ruolo svolto da un utente o da qualsiasi altro sistema che interagisce con il soggetto. (Il termine “ruolo” è usato informale qui e non implica necessariamente la definizione tecnica del termine si trova altrove in questa specifica.)
Ora la maggior parte persone sarebbero d'accordo che le interazioni a livello di imprese e utenti sono lo sweet spot , ma non c'è limite.Pensa agli attori/ruoli che sono al di fuori del sistema/sistema principale su cui ti stai concentrando. Ma in una vista un sistema potrebbe essere un attore, ma in un altro l'implementatore di altri casi d'uso.
La normale granularità di usecase è l'obiettivo dello scenario, non il passaggio. –