Il caso d'uso causa altri casi d'uso

Naviga le tue risposte
2

Sto facendo questo sistema indipendente di controllo dei droni che un utente può avviare e fermare. Quando il programma viene avviato, il drone connesso decolla, si libra e si gira per affrontare l'altro lato. All'inizio ho pensato ad un diagramma dei casi d'uso come questo:

Ilproblemaèchesembrachelosviluppatorepossaeseguire"Take off" ecc. anche se questo viene fatto solo dal sistema. Almeno, è così che lo interpreto dalla maggior parte degli esempi di casi d'uso. In questa altra domanda il caso d'uso incluso era qualcosa fatto unicamente dal sistema, ma era considerato inadatto per il diagramma del caso d'uso. Pertanto,

  • Rimuovere i casi d'uso inclusi?
  • Devo ancora descriverli nel flusso principale dei casi di utilizzo "Start" e "Stop" se li rimuovo?

Ad esempio, il flusso principale del caso d'uso "Start":

The developer starts the program. The drone takes off. The drone hovers in the air. The drone yaws to face the opposite direction.

  • Li tengo ma aggiungo un attore "FlightController" che si collega ai casi d'uso inclusi?

Grazie

    
posta Marthe Veldhuis 29.03.2018 - 10:42
fonte

1 risposta

2

Il tuo caso d'uso sembra corretto

Ogni caso d'uso di il sistema preso in considerazione (il tuo sistema di droni) è:

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

Ogni UC del tuo diagramma è conforme a questa definizione.

Il link actor / UC significa che l'attore è coinvolto nel caso d'uso. Qui capirò che il Developer è coinvolto nell'avvio. Ma voi non dite nulla dei casi inclusi, non darei per scontato che l'attore sarebbe direttamente coinvolto in essi anche se non potrei escluderlo neanche io.

L'aggiunta di FlightController non sarebbe corretta perché non è un attore nell'ambiente del tuo sistema, ma una parte di esso.

L'unica cosa che trovo confuso è il nome fuorviante di Start : la denominazione suggerisce che l'attore avrebbe solo l'obiettivo di avviarlo. Ma in realtà, l'obiettivo è eseguire un insieme predefinito di azioni.

Nota: nell'altra domanda a cui fai riferimento, è suggerito che il salvataggio nel database non è un UC perché non viene eseguito dall'utente. Va detto che in aggiunta il salvataggio nel database non è qualcosa di osservabile per l'utente. L'utente vede solo ciò che è nel database tramite altri casi d'uso. La tua situazione è leggermente diversa dal momento che il comportamento dei droni è osservabile e forse addirittura desiderato dall'utente

Alternativa

In alternativa, potresti comunque prendere in considerazione:

  • un caso d'uso limitato agli obiettivi dell'utente e in cui l'utente è realmente coinvolto (ad esempio, inizia il volo e termina).
  • utilizza un diagramma delle attività per descrivere i dettagli dei comportamenti che si verificano per il caso d'uso, specialmente se l'utente non è coinvolto

Potrebbe essere:

Il vantaggio principale è che è possibile migliorare la logica di volo e renderla più complessa senza perdere l'immagine grande che il diagramma del caso d'uso dovrebbe fornire.

    
risposta data 29.03.2018 - 17:22
fonte

Leggi altre domande sui tag

Come posso determinare come addebitare i costi per il supporto dei siti di SharePoint e dello sviluppo di SharePoint? [chiuso] Cosa significa "triage un problema" nella programmazione? [chiuso]