Linea guida: Generalizzazione dei casi d'uso
La generalizzazione viene utilizzata quando vengono individuati due o più casi d'uso che hanno in comune dei comportamenti, delle strutture e degli scopi. Questa linea guida descrive come utilizzare questa relazione.
Relazioni
Descrizione principale

Spiegazione

Un caso d'uso primario (parent) specializzarsi in uno o più casi d'uso secondari (child) che rappresentano dei formati più specifici del parent. Né il parent né il child sono necessariamente astratti, anche se il parent nella maggior parte dei casi lo è. Un child eredita tutta la struttura, il comportamento e le relazioni del parent. I child dello stesso parent sono tutti delle specializzazioni del parent. Questa è la generalizzazione applicabile ai casi d'uso (per ulteriori informazioni sul concetto di generalizzazione applicato alle classi vedere Linee guida: Generalizzazione).

La generalizzazione viene utilizzata quando vengono individuati due o più casi d'uso che hanno in comune dei comportamenti, delle strutture e degli scopi. Quando questo accade, è possibile descrivere le parti condivise in un nuovo caso d'uso, spesso astratto, che viene quindi specializzato da casi d'uso secondari (child).

Esempio:

Diagramma descritto nella figura.

I casi d'uso Ordine telefonico e Ordine via Internet sono delle specializzazioni del caso d'uso astratto Effettua ordine.

In un sistema Gestione degli ordini, i casi d'uso Ordine telefonico e Ordine via Internet condividono buona parte della struttura e del comportamento. Viene definito un caso d'uso generale Effettua ordine, in cui vengono definiti la struttura ed il comportamento comuni. Il caso d'uso astratto Effettua ordine non deve essere completo di per sé ma fornisce un framework generico comportamentale che i casi d'uso secondari possono poi rendere completo.

Il caso d'uso principale (parent) non è sempre astratto.

Esempio:

Considerare il sistema Gestione degli ordini dell'esempio precedente. Si supponga di voler aggiungere un attore Impiegato registro ordini, che può inserire degli ordini nel sistema per conto del cliente. Questo attore avvierebbe il caso d'uso generale Effettua ordine, che ora deve disporre di un flusso di eventi completo, descritto per il caso d'uso. I casi d'uso child possono aggiungere un comportamento alla struttura fornita dal caso d'uso parent ed inoltre modificano il comportamento nel parent.

Diagramma descritto nella figura.

L'attore Impiegato registro ordini può creare un'istanza del caso d'uso generale Effettua ordine. Effettua ordine può anche essere specializzato dai casi d'uso Ordine telefonico o Ordine via Internet.

Il caso d'uso child dipende dalla struttura (consultare Linea guida: Caso d'uso, la discussione sulla struttura del flusso di eventi) del caso d'uso principale. Il caso d'uso child può aggiungere ulteriore comportamento al parent inserendo nel comportamento ereditato i segmenti relativi oppure dichiarando le relazioni di inclusione (e di estensione) al caso d'uso child. Il child può modificare i segmenti del comportamento ereditato dal parent, anche se deve essere eseguito prestando la massima attenzione, in modo da conservare l'intento del parent. La struttura del caso d'uso parent viene conservata dal child. Ciò significa che tutti i segmenti di comportamento, descritti come fasi o flussi secondari del flusso di eventi del parent, devono ancora esistere ma il contenuto dei segmenti di comportamento può essere modificato dal child.

Se il parent è un caso d'uso astratto, potrebbe contenere dei segmenti di comportamento non completi. Il child deve quindi completarli e renderli significativi per l'attore.

Non è necessario che un caso d'uso parent abbia una relazione con un attore, se si tratta di un caso d'uso astratto.

Se due casi d'uso child specializzano lo stesso parent (o base), le specializzazioni sono indipendenti le une dalle altre, cioè vengono eseguite in istanze di casi d'uso separate. Questo è diverso dalle relazioni di estensione o di inclusione, dove diverse aggiunte modificano implicitamente o esplicitamente un'istanza di caso d'uso che esegue lo stesso caso d'uso base.

Per riutilizzare il comportamento fra i casi d'uso del modello possono essere usati sia la generalizzazione del caso d'uso che la relazione di inclusione. La differenza è che con la generalizzazione del caso d'uso, l'esecuzione dei child dipende dalla struttura e dal comportamento del parent (la parte riutilizzata), mentre in una relazione di inclusione l'esecuzione del caso d'uso base dipende solo dal risultato della funzione che il caso d'uso d'inclusione (la parte riutilizzata) esegue. Un'altra differenza è che in una generalizzazione i child condividono le similitudini di scopo e struttura, mentre nella relazione di inclusione i casi d'uso base che riutilizzano la stessa inclusione possono avere degli scopi completamente diversi, ma necessitano entrambi che venga eseguita la stessa funzione.

Esecuzione della generalizzazione del caso d'uso

Un'istanza di caso d'uso che esegue un caso d'uso child seguirà il flusso di eventi descritto per il parent, inserendo ulteriore comportamento e modificando quello definito nel flusso di eventi del caso d'uso child.

Diagramma descritto nella figura.

L'istanza del caso d'uso segue il parent, con il comportamento inserito o modificato come descritto nel child.

Descrizione della generalizzazione del caso d'uso

In generale, non viene descritta la relazione di generalizzazione stessa. Invece, nel flusso di eventi del caso d'uso child si specificano come vengono inserite le nuove fasi nel comportamento ereditato e come quest'ultimo viene modificato.

Se il child specializza più di un parent (ereditarietà multipla), è necessario affermare esplicitamente nella specifica del child come vengono inserite nel child le sequenze di comportamento provenienti dai parent.

Esempio di utilizzo

Considerare le seguenti strutture in fasi per i casi d'uso di un semplice sistema telefonico:

Effettua chiamata urbana

  1. Il chiamante solleva il ricevitore.
  2. Il sistema presenta il tono.
  3. Il chiamante compone i numeri.
  4. Il sistema disattiva il tono.
  5. Il chiamante immette il promemoria del numero.
  6. Il sistema analizza il numero.
  7. Il sistema individua la parte corrispondente.
  8. Il sistema collega le parti.
  9. Le parti si scollegano.

Effettua chiamata interurbana

  1. Il chiamante solleva il ricevitore.
  2. Il sistema presenta il tono.
  3. Il chiamante compone i numeri.
  4. Il sistema disattiva il tono.
  5. Il chiamante immette il promemoria del numero.
  6. Il sistema analizza il numero.
  7. Il sistema invia il numero ad un altro sistema.
  8. Il sistema collega le linee.
  9. Le parti si scollegano.

Il testo in blu è molto simile nei due casi d'uso. Se i due casi d'uso sono simili, si prende in considerazione di unirli in un unico caso d'uso, dove i flussi alternativi secondari mostrano la differenza fra le chiamate urbane e quelle interurbane.

Se, tuttavia, la differenza fra loro è significativa ed è immesso un valore che mostra chiaramente nel modello di casi d'uso la relazione fra chiamata urbana e chiamata interurbana, possiamo estrarre il comportamento comune in un nuovo caso d'uso più generale, denominato Effettua chiamata.

In un diagramma di casi d'uso la relazione di generalizzazione creata viene illustrata come segue:

Diagramma descritto nella figura.

I casi d'uso Effettua chiamata urbana ed Effettua chiamata interurbana ereditano dal caso d'uso astratto Effettua chiamata.