Generalizzazione del caso d'uso rispetto all'estensione

Question

I diagrammi caso d'uso UML consentono due modi apparentemente equivalenti per dimostrare che un dato caso d'uso potrebbe essere realizzato in diversi modi, ovvero use case generalizations in contrasto con use case extensions. Ho visto il seguente esempio di base modellato usando entrambi gli approcci con uguale frequenza, a volte all'interno di un'unica sorgente.

Secondo me un'estensione un rapporto più debole di generalizzazione come una sostituzione diretta del caso dell'uso specializzato per il caso base dev'essere possibile generalizzazione ma non necessariamente nelle estensioni.

Mi sembra che la generalizzazione implichi una implementazione polimorfica, mentre l'estensione implica che si debba utilizzare una struttura di ramificazione.

void makePayment(const PaymentDetails* pd) 
{ 
    pd->pay(); 
} 

al contrario di

void makePayment(const PaymentDetails* pd) 
{ 
    switch(pd->type) 
    { 
     case EFT: 
       payViaEFT(pd); 
       break; 
     case PAYPAL: 
       payViaPayPal(pd); 
       break; 
     case CREDITCARD: 
       payViaCreditCard(pd); 
       break; 
    } 
} 

non è la fase Use Case troppo presto per problemi specifici, quali implementazione da modellare? Ci sono diagrammi UML molto più appropriati per questo. Esiste una regola ferrea su quale dei due usare e, in caso affermativo, di cosa si tratta?

Answer 1

Secondo me un interno è un rapporto più debole di generalizzazione come una sostituzione diretta del caso dell'uso specializzato per il caso base dev'essere possibile generalizzazione ma non necessariamente nelle estensioni.

Questo è vero.

Mi sembra che implica una generalizzazione polimorfico attuazione si desidera che il prolungamento implica una certa ramificazione struttura deve essere utilizzato.

Il diagramma non impone alcuna implementazione. Tuttavia, puoi interpretare un suggerimento dal diagramma. UML rimane indipendente dal linguaggio e dalla soluzione lì.

La fase di caso d'uso non è troppo presto per l'implementazione di questo specifico problema?

Bene, come indicato sopra, UML non applica alcun tipo specifico di implementazione. Tuttavia, qui vengono raccolti alcuni importanti requisiti funzionali che potrebbero influire notevolmente sulla pianificazione temporale e sul carico di lavoro. ("Pagare con carta di credito" è molto più complesso da gestire di "pagare in anticipo tramite bonifico bancario"). Quindi ti sforzerai di catturarlo ma rimani aperto a diversi approcci alla soluzione.

Ci sono diagrammi UML molto appropriati per questo.

È possibile utilizzarli in parallelo :) poiché sono viste diverse sullo stesso soggetto.

Esiste una regola dura e veloce su quale dei due da utilizzare e, in caso affermativo, di cosa si tratta?

Preferisco la generalizzazione in questo caso perché in effetti le estensioni suggeriscono erroneamente che ci potrebbe essere un modo di pagare senza utilizzare nessuna delle tre opzioni nominate. Come ti sei indicato.

Answer 2

Quando si modella con una relazione di estensione, il caso di utilizzo esteso (pagamento tramite xxx) viene eseguito quando il caso di utilizzo esteso (pagamento) si trova in una posizione precisa (data dal punto di estensione, tipo di pagamento) se la condizione per tale rapporto di estensione vale (ad esempio per "Pay via Paypal", la condizione sarebbe payment_type = PAYPAL). In questo modello, "Pay via Paypal" tratta solo i dettagli del completamento di una transazione di pagamento con Paypal, mentre "Effettua pagamento" specifica tutti i comportamenti che sono indipendenti dal metodo di pagamento (come il calcolo dell'importo totale e il salvataggio del risultato della transazione una volta che è stata eseguita).

D'altra parte, la generalizzazione (che è definita non solo per i casi d'uso, ma anche per qualsiasi classificatore) è un concetto più ampio, dal momento che non dettaglia (a livello di diagramma) i dettagli di quando e come i comportamenti sono eseguiti Se "Pay via Paypal" fosse una specializzazione di "Effettua pagamento", si ridefinire il comportamento di "Effettua pagamento", che potrebbe essere sostanzialmente diverso dal comportamento di "Paga con carta di credito".

Essendo un caso di utilizzo estensivo non significa che le alternative debbano essere codificate. Infatti, il tuo primo esempio è anche un'implementazione valida di una relazione di estensione, dal momento che pd->pay(pd) invocherà comportamenti diversi a seconda del tipo di pagamento selezionato. In realtà, utilizzare i modelli di diagramma del caso che cosa deve fare un sistema, mentre i dettagli di implementazione di basso livello sono meglio specificati nei diagrammi di attività.

Answer 3

Un esempio di un'estensione sarebbe un caso di utilizzo "Inserisci codice sconto". L'inserimento di un codice di sconto ha a che fare con l'esecuzione di un pagamento, ma non è necessario inserirne uno per effettuare il pagamento.

È possibile osservare la relazione "è un" per stabilire quale utilizzare. Pagare con PayPal "è un" effettuare il pagamento, un modo specifico di effettuare un pagamento. Inserisci il codice sconto non lo è. È qualcosa di aggiuntivo che puoi fare mentre effettui un pagamento.