Uml

[alka]

Ho un utente che interagisce direttamente con un sistema web, però agisce su dei dati/risultati che sono accessibili dall'applicazione web grazie a del lavoro svolto con un database e con un altro server e con in realtà un altro tipo di applicazione. [...]

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!