Come modellare l'accesso in due fasi in UML tramite i diagrammi Use Cases e Sequence correttamente?

Question

Come modellare l'accesso in due fasi in UML tramite i diagrammi Use Cases e Sequence correttamente?

#1 da (1 voti)

2

Devo creare una pagina di accesso per un'applicazione di base relativa alla contabilità. L'azione di accesso dovrebbe essere in due fasi:

L'utente inserisce il nome utente e la password e fa clic sul pulsante "Autorizza",
Dopo aver eseguito correttamente l'autorizzazione, l'utente deve impostare i parametri iniziali per la sessione corrente (vale a dire il mese e l'anno, l'unità per cui tenere conto, ecc.). I parametri disponibili tra cui scegliere dovrebbero essere presi dal server (possono variare a seconda dei privilegi dell'utente autorizzato, ecc.).

Vorrei descrivere queste azioni sopra in UML usando entrambi i diagrammi Use Cases e Sequence. Quindi per ora ho creato un diagramma del caso d'uso:

eundiagrammadisequenza:

Vorrei sapere se questi diagrammi sono corretti (specialmente se le relazioni con l'attore Server sono nella giusta direzione e se uso le relazioni include correttamente nei diagrammi Use Case anche se il diagramma Sequence ha senso ). Eventuali miglioramenti e suggerimenti apprezzati.

design uml use-case

posta Rafichu 20.10.2017 - 22:34

fonte

1 risposta

Leggi altre domande sui tag design uml use-case

Flusso di lavoro per la formattazione git / codice / commit hooks ecc Streaming dei dati dal sistema chiuso al cloud: approccio adeguato all'architettura

score 1 · Answer 1

Ci sono alcune cose sbagliate nei tuoi diagrammi.

Prima di tutto, il tuo uso degli attori. Un attore è qualcosa / qualcuno al di fuori del sistema che stai modellando che ha bisogno di interagire con il tuo sistema. Gli attori sono rappresentati da un bastone-uomo, perché sono tipicamente umani. Gli attori non umani possono esistere, ma è molto più difficile da dire per attori non umani se sono correttamente modellati come attori o se dovrebbero essere stati modellati come parte del sistema stesso.
I server, le stampanti, i display, ecc. Su cui il tuo software gira sono sicuramente attori non . Questi sono parte integrante del sistema che stai progettando.

Poiché gli attori sono per definizione al di fuori del tuo sistema, le interazioni dirette tra attori non ti interessano. Se si ha un diagramma di sequenza con una freccia di chiamata / evento tra due attori, allora deve essere possibile rimuovere quell'interazione senza cambiare il significato del diagramma di sequenza, o almeno uno degli attori dovrebbe aver fatto parte del sistema.

Un diagramma dei casi d'uso appropriato offre sorprendentemente piccole informazioni al lettore. Potrebbe essere meglio considerare un diagramma del caso d'uso come non molto più di un indice grafico ai casi d'uso esistenti e ai loro attori principali.

Un caso d'uso è un'interazione tra un attore e un sistema, in cui l'attore utilizza il sistema per raggiungere un obiettivo.

Nel tuo esempio, "login" è un caso d'uso corretto, ma non tutti gli altri. Sono solo passi che vengono presi come parte del caso d'uso "login". Per un corretto diagramma del caso d'uso, puoi semplicemente cancellare tutto a destra della casella d'uso "login".

Il modo normale per descrivere un caso d'uso è solo testo, anche se potrebbero essere usati diagrammi di supporto come diagrammi di sequenza o attività.