Operazione: Esecuzione analisi orientata alla variazione
Questa attività è applicabile ad un numero di elementi di analisi e progettazione dove la progettazione della variabilità in tali elementi e della associazione dà un risultato più solido e flessibile.
Scopo

Analizzare gli elementi del modello forniti ed identificare quali di questi elementi sono comuni alle diverse applicazioni e separarli da quegli elementi che variano in diverse applicazioni. Identificando quegli elementi che variano dall'applicazione si era in grado di modellare esplicitamente i tipi di variabilità e documentarli per client degli elementi del modello.

Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio:
  • Nessuno
Facoltativo: Esterno:
  • Nessuno
Output
Descrizione principale

Questa attività potrebbe essere applicata ad un analisi o un modello di progettazione dove gli elementi del modello potrebbero beneficiare delle tecniche di seguito descritte. Le tecniche sono derivate dall'esperienza nel Product Line Engineering, dove gli elementi comuni sono ciò che unisce i prodotti nella linea del prodotto e la variabilità sono ciò che distingue i prodotti l'uno dall'altro, e nello sviluppo del prodotto dove gli elementi comuni sono la struttura del modello e la variabilità utilizzate per definire i parametri nel modello.

L'approccio è prima di identificare gli elementi del progetto in modo che siano comuni a tutte le applicazioni dell'elemento, quindi di identificare gli elementi che variano in ogni applicazione, ed infine di documentare la variabilità (qui sono utilizzati diversi approcci da domini diversi).

Esempio

Nel seguente diagramma di classe vengono visualizzati gli elementi dei un contratto legale, identificando che il contratto è tra due o più parti. Nell'identificare gli elementi comuni, si nota che gli elementi principali sono la struttura del contratto stesso e le diverse relazioni con le parti.

Tuttavia, un contratto legale potrebbe essere tra persone diverse, organizzazioni e agenzie di governo e così si nota che la Parte è un elemento variabile per tipo. Nel documentare questo viene definita una gerarchia del tipo per la parte e si indica quest'ultima come una classe astratta in modo che i tipi concreti devono essere utilizzati in un progetto effettivo.

Passi
Identificazione elementi comuni e variabili

L'identificazione degli elementi di un progetto che non cambia quando è utilizzato in diverse situazioni è spesso fatta meglio in modo iterativo. Utilizzando un insieme di scenari, creare i diagrammi di istanze e notare quando si confrontano i diagrammi di istanza per i diversi scenari quali elementi sono comuni in tutti i casi. Più scenari sono disponibili e ovviamente più punti di dati sono disponibili per l'utente e quindi si è in grado di convalidare i risultati e le assunzioni.

Nel descrivere gli elementi comuni in un modello, è spesso importante fornire alcune forme di elementi incapsulati per separare questi elementi dal resto del progetto. La scelta della tecnica di incapsulamento è ovviamente dipendente dal contesto, ma potrebbe essere:

  • L'introduzione di un pacchetto per possedere gli elementi cambia solo la proprietà degli elementi ma non il rapporto tra gli elementi o gli elementi al di fuori del pacchetto - questo viene più comunemente applicato ai modelli di analisi.
  • L'introduzione di un componente per possedere gli elementi non solo cambia la proprietà ma introduce anche un'incapsulamento formale in modo che è possibile scegliere di definire un'interfaccia esponendo gli elementi importanti al di fuori.
  • L'introduzione di una collaborazione UML 2.0 consente agli elementi comuni di essere definiti come parte della struttura composta della collaborazione e gli elementi variabili come ruoli; successivamente è possibile eseguire un binding dai ruoli dell'elemento variabile in elementi concreti. Questo è un approccio comune per definire i modelli di progettazione in UML. Notare che una collaborazione non possiede gli elementi stessi, solo i ruoli corrispondenti agli elementi.
  • L'introduzione di una classe del modello dove il modello corrisponde al tipo degli elementi variabili è un approccio comune in linguaggi come Ada, C++, Eiffel e ora Java che supporta la programmazione generica.
  • È possibile semplicemente scegliere di utilizzare uno spunto comune. È comune, ad esempio, utilizzare un digramma singolo (come mostrato nella descrizione principale) e colorare gli elementi comuni e variabili in modo diverso.

Esempio

Nel caso del contratto legale si sceglie di introdurre un componente che possiede gli elementi, come illustrato n ella figura di seguito riportata.

Moduli di variabilità del documento

La variabilità stessa prende un numero di forme diverse, ognuna delle quali potrebbe essere appropriata ed in alcuni casi più di una forma è presente in una data situazione. I tipi comuni di variabilità sono:

  • Variabilità per tipo - ad esempio, nel caso del contratto legale la variabilità è basata sulla gerarchia del tipo utilizzata per rappresentare il concetto "Party"; questo è una forma molto comune ed è facilmente descritto utilizzando UML come un diagramma di classe (come mostrato nella descrizione principale).
  • Variabilità per ruolo - in questo caso il tipo di elemento è generalmente immateriale (o almeno di importanza secondaria); è il ruolo che gioca che è di valore. Questo tipo di variabilità è spesso rilevata nello sviluppo del modello dove dovrebbe essere possibile applicare il modello al più ampio insieme di possibilità e in questo modo i parametri al modello sono definiti in termini di ruoli solo degli elementi forniti.
  • Variabilità di Implementazione - In questo caso l'elemento fornito è richiesto per eseguire alcune funzioni e quindi è necessario implementare una data interfaccia (o più formalmente un protocollo) da applicare. In tal caso, accade spesso  che il contenitore degli elementi comuni descriva l'interfaccia abbia un parametro del modello del tipo di interfaccia o per richiedere l'interfaccia.

Esempi

Il seguente diagramma dimostra la nozione di variabilità per ruolo, dove si dispone di una nuova "Vendita" di collaborazione che indica la relazione tra un venditore ed un acquirente come parti di un contratto. In UML è quindi possibile creare una ricorrenza di collaborazione che lega i ruoli "acquirente" e "venditore" agli elementi del modello effettivi.

In alternativa, si guarda al processo di vendita utilizzando un servizio a garanzia. Vengono riportate le funzioni richieste di tutti i servizi a garanzia come un'interfaccia, con un insieme di operazioni che corrispondono alle responsabilità necessarie che si prevede che il servizio a garanzia esegua. Con questo si crea una collaborazione del modello dove si utilizza l'interfaccia a garanzia come tipo di parametro del modello. Ora è possibile istanziare il modello fornendo la classe o il componente che realizza l'interfaccia IEscrowService.

Infine, è possibile semplicemente utilizzare un componente (o classe) per contenere gli elementi comuni e richiedere l'interfaccia IEscrowService utilizzando la relazione di <<utilizzo>> UML 2.0 come mostrato nel diagramma di seguito riportato. Questo approccio è sicuramente importante al livello del progetto poiché è anche un approccio di programmazione comune nello sviluppo basato sul componente o anche solo in linguaggi come Java.

La scelta della tecnica, dipenderà come al solito dalla situazione incluse le considerazioni come:

  • Il tipo di variabilità espressa, come visto precedentemente.
  • Se l' elemento è una parte di un'analisi, un progetto o un modello di implementazione.
  • Le abilità e le previsioni degli azionisti nel modello.

Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni