Non sono sicuro che il mio diagramma sia corretto, è corretto avere questo numero di relazioni di inclusione?
Nota: lo scenario del mio sistema: l'utente accede alla pagina Web e inserisce qualsiasi account utente di Twitter, quindi il mio sistema raccoglierà i tweet dell'utente desiderato, li pulirà e pre-elaborerà, li classificherà, calcolerà il risultato della classificazione, infine mostrerà il risultato a l'utente.
Il caso d'uso deve dare l'immagine generale del sistema preso in considerazione, mostrando a cosa serve e come apporta valore agli attori nel suo ambiente.
Il concetto " value " è essenziale per l'identificazione di i casi d'uso: l'intento qui non è quello di descrivere in dettaglio come si comporta il sistema, né le sue interazioni interne. Riguarda lo scopo. Ogni caso d'uso nel diagramma deve essere:
the description of a set of sequences of actions and variants that a system performs that yield an observable result of value to an actor.
- Ivar Jacobson
Applichiamo questo al tuo esempio: raccogli i tweet , pulisci tweets , pre-processa i tweet , classifica i tweet e calcola i risultati tutti sembrano essere passi che, se non presi separatamente, non hanno alcun risultato osservabile e nessun valore per l'utente. Allo stesso modo, mostra risultati non è un caso d'uso indipendente: ha solo valore nel contesto della richiesta.
Ma quando leggo cosa fa il tuo sistema, capisco che l'utente vuole inserire un account Twitter e ottenere una classificazione. Questa è l'unica cosa che ha davvero valore per il tuo utente:
Seèl'unicocasod'uso,questodiagrammasarebbeunpo'eccessivo.Spontaneamente,sospettocheunsecondocasod'usopotrebbeessere:addestrailmotorediclassificazione(datochehaiqualchecomponenteML).
Sevuoirappresentarel'internodelcasod'uso,cioèlasequenzadiazionichevengonoeseguite,puoiprendereinconsiderazionel'utilizzodiun
Ci sono alcuni vantaggi: il flusso di elaborazione è evidenziato attraverso le frecce. Puoi anche mostrare join e fork nel tuo flusso di elaborazione. Alla fine puoi evidenziare quali oggetti vengono scambiati tra le fasi del processo. E non è necessario entrare nei dettagli tecnici dei componenti di terze parti (ad esempio in un caso d'uso si visualizzano sistemi indipendenti come attori, ma non librerie).
Non dovresti decomporre un caso d'uso come quello. Questo è solo un caso di uso semplice "Richiedi la classificazione dell'utente" con relativamente molti sistemi esterni come attori coinvolti.
La scomposizione per mostrare come viene elaborato il caso d'uso dovrebbe essere rappresentata su un diagramma separato. Vorrei suggerire il diagramma di sequenza a causa di più interazioni, ma il diagramma di attività farà anche (potrebbe essere meno chiaro).