Originariamente inviata da
alka
Lo
Use Case Diagram non è adatto alla rappresentazione che vuoi fare tu, perché ciò di cui stai parlando è un dettaglio architetturale e non ha nulla a che vedere con il caso d'uso.
Mi spiego meglio: se voglio creare un diagramma di casi d'uso per un bancomat, ciò che vedrò sarà il sistema, l'utente comune possessore del bancomat come attore, e le operazioni che si possono fare, tipo
prelievo,
deposito,
visualizzazione conto,
ricarica telefono, ecc.
Questi che ho indicato sono i casi d'uso. L'utente che si presenta al bancomat non ha come caso d'uso "l'interazione con il DB", che è un dettaglio architetturale: a lui interessa esclusivamente fare l'operazione per la quale si è presentato, poi come questa venga implementata ed espletata dal sistema con cui interagisce, sono "affari interni" che nulla hanno a che vedere con la fruizione della funzionalità, e pertanto vanno rappresentate - se lo si vuole fare - in altri diagrammi fatti apposta per questo, come un
Sequence Diagram se vuoi dare l'idea di come è implementata nello specifico una determinata feature, oppure un
Component Diagram se vuoi mostrare le parti del sistema che interagiscono (senza concentrarsi sul "come"), fino al
Class Diagram se vuoi rappresentare la struttura delle classi che implementano tali parti.
Nel diagramma dei casi d'uso, roba come "accedere al DB" non va nemmeno citata, a meno che non stiamo parlando di un software dedicato a un utente che fa il
Database Administrator, e allora ha senso nel contesto.
Ciao!
Rispondi quotando
