'estendere' un caso d'uso non necessario quando è direttamente associato all'attore?

1

HounDipendentechepuòvisualizzaregliarticoli.ancheluipuòeffettuareilcheckoutdiunavoceinmodoindipendente(indipendentementedallagestionedegliarticolicasod'uso).Ilproblemaèchequandoundipendenteosservaglioggettipuòsceglieredicontrollarneuno.Quindipensocheunadelleseguentiopzionisiavera:

  1. larelazione"estendi" da visualizza elementi a verifica un elemento non è necessaria e deve essere eliminata
  2. l'associazione tra l'Employee e il checkout di un oggetto non è necessaria (non ne dubito che uno sia vero)
  3. Le opzioni 1 e 2 sono errate. sia l'associazione che la relazione 'estendi' sono vere e dovrebbero essere lì sul diagramma.
posta ghassen lassoued 13.05.2018 - 12:26
fonte

1 risposta

3

Se un caso d'uso ne estende un altro è indipendente dalle associazioni visibili tra attori e casi d'uso. Tuttavia, ogni volta che c'è un attore associato a un caso d'uso come "oggetti di verifica", è chiaro questa situazione richiede l'intervento dell'utente, che rende obbligatorio avere una parte caratteristica di visualizzazione di tale caso d'uso , non viceversa.

Pertanto, raccomando strongmente di non modellare "visualizza elementi" come caso d'uso da solo . Un dipendente non visualizza gli articoli "solo per divertimento", per casi di utilizzo reali, dovrebbe esserci uno scopo commerciale dietro di esso. Alcuni esempi, che hanno tutti bisogno di questa funzione di visualizzazione:

  • controllare alcune proprietà degli elementi ai fini della garanzia della qualità - poi il caso d'uso è "garanzia della qualità dei prodotti"

  • data tali elementi hanno un prezzo, quindi "pagare i punti" potrebbe essere un caso d'uso

  • "elementi checkout" (qualunque cosa significhi nel vostro contesto, dal momento che "checkout" e "voce" sono termini generici con molti significati diversi possibili)

La notazione dei casi d'uso UML è intesa per descrivere scenari di utilizzo per lo più indipendenti dall'interfaccia utente. Questa notazione e le relazioni "estende" e "include" sono progettate per un livello più alto di astrazione. Anche se il caso d'uso "checkout items" verrà avviato nell'interfaccia utente visualizzando prima gli elementi, questo è niente che proverei ad esprimere attraverso il modello, è solo un dettaglio dell'interfaccia utente.

Se ancora esorti a modellare "visualizza elementi" come un caso d'uso separato, forse per scopi di esercizio, allora consiglierei di tracciare una relazione "include" da un caso d'uso come "articoli da verificare" a "visualizza elementi" . Tuttavia, è IMHO ovvio che la maggior parte dei casi di utilizzo che coinvolgono l'interazione dell'utente con elementi hanno bisogno di una funzione di visualizzazione:. Gli utenti non vogliono cercare un po 'con gli oggetti alla cieca quando si opera su di loro

    
risposta data 13.05.2018 - 16:36
fonte

Leggi altre domande sui tag