I casi d'uso sono principalmente destinati all'interazione tra utente e sistema. Potrebbe essere utilizzato per l'interazione tra sistema e un altro sistema. Gli attori sono principalmente ruoli.
È facile documentare i casi d'uso per un'applicazione front-end come un portale in cui è possibile definire tutte le attività e il ruolo che svolge l'attività. Tuttavia se il sistema è un sistema di gestione degli ordini o di provisioning che un sistema a valle, come possono essere documentati i casi d'uso?
Esempio: un'applicazione di gestione degli ordini può essere responsabile dell'elaborazione degli ordini per tipo nuova installazione, cambio di servizio, cancellazione, riprogrammazione, sospensione, riavvio ecc. Queste transazioni potrebbero essere attivate da diverse fonti con diversi mezzi (chiamata di servizio, entrata posta in db quali polling dell'applicazione OM, ordine inserito nella coda jms, tuttavia presumo che questi non abbiano alcuna relazione con il caso d'uso). Una volta ricevuto l'ordine, l'applicazione Gestione ordini potrebbe dover interagire con diverse applicazioni (controllo del credito, spedizione, provisioning, attivazione, fatturazione, ecc.) In base al tipo di ordine.
Ho un'applicazione che riceve dati da un'applicazione upstream. La mia applicazione consuma i servizi web esposti da più applicazioni per svolgere un compito. I dati fluiscono attraverso più applicazioni prima di raggiungere il sistema a monte che invia messaggi alla mia applicazione. Le attività svolte dalla mia applicazione sono installate, disconnesse, sospendono, ripristinano ecc. Utilizzando più servizi che consuma.
Quando leggo post sul fatto di avere il sistema come attori, l'obiettivo principale sembra essere delimitare e definire correttamente le interfacce. Nello scenario precedente supponendo che il sistema upstream sia A, la mia applicazione è B e le applicazioni che la mia applicazione consuma sono C, D ed E.
- La mia aplicazione esegue l'installazione, la disconnessione, la restituzione e la sospensione. Sono queste le attività?
- L'attore principale sarà il sistema che invia messaggi alla mia applicazione? Non riesco a pensare a questo come a un ruolo e inoltre non ci sono interazioni tra l'applicazione upstream e la mia applicazione dopo il punto in cui la mia applicazione riceve un messaggio.
- Come posso definire le applicazioni esterne che la mia applicazione consuma? come attore o attività? o non mi importa di questi diagrammi del caso d'uso?
Quando esegui un'interazione tra l'utente e un sistema per acquistare un prodotto, elencherai la serie di interazioni tra te e il software. Tuttavia, quale software internamente non è specificato.
Qui nel mio caso, poiché si tratta di un sistema a valle, il sistema a monte invia un solo messaggio e non vi è alcuna serie di interazione. Quindi sono in bilico su come dovrei definire gli scenari.