Linea guida: Analisi delle variabilità
L'analisi della crea un modello che separa gli aspetti in cambiamento da quelli più stabili del modello del dominio. Questo consenta l'esternalizzazione dei tipi anticipati di modifiche e le loro regole corrispondenti, consentendo un'introduzione futura e non intrusiva delle modifiche al progetto esistente.
Relazioni
Descrizione principale

Introduzione

Il progettista del servizio deve essere consapevole che formando una Risorsa: Specifica del servizio è necessario bilanciare due forze in competizione;

  • Specializzazione; la necessità di assicurare che un servizio fa ciò che è richiesto, soddisfacendo la funzione identificata durante l'Attività: Analisi asset esistente.
  • Generalizzazione; la necessità di assicurare che un servizio sia quanto più riutilizzabile è possibile, poiché quei requisiti futuri non richiedono un'importante riprogettazione dei servizi esistenti.

A questo fine, il progettista potrebbe impiegare le tecniche comunemente chiamate analisi "Associazione e variabilità". Queste tecniche sono conosciute e sono state già documentate, in modo predominante nell'area della formulazione del modello [Coplien, Gabriel] e della progettazione della linea di prodotto software [GBS, JGBS01, JB02, MRR04, Parnas, SBM01]. Queste sono aree in cui il progettista bilancia anche le stesse forze nei modelli - la necessità di catturare la variabilità come parametri per il modello, per consentire l'applicabilità del modello in diverse situazioni.

Nella letteratura sui modelli [Coplien] viene descritta la comunalità come "l'essenza dell'astrazione", e la variabilità come "la spezia della vita" mentre [Gabriel] in modo più concreto descrive il rapporto tra l'associazione e l'astrazione -- una buona astrazione ha bisogno di riportare gli aspetticomuni nella soluzione mentre si specificano le variabilità degli elementi singoli.

L'astrazione nella programmazione è il processo di identificazione dei modelli comuni che hanno variazioni sistematiche; un'astrazione rappresenta il modello comune e fornisce un mezzo per la specifica di quali variazioni utilizzare.

In termini simili [Parnas] definisce una famiglia di programmi (oggi si tende a descrivere in termini di linee di prodotti software) in base alle proprietà comuni dell'insieme e le proprietà speciali dei membri singoli:

Un insieme di programmi viene considerato come costituente una famiglia, quando è importante studiare i programmi dall'insieme studiando prima le proprietà comuni dell'insieme e quindi determinando le proprietà speciali dei membri singoli della famiglia

Riporta variabilità

Molti sistemi sono costruiti con molto poca lungimiranza per incorporare le modifiche risultanti dai nuovi requisiti. L'analisi di associazione e variabilità crea un progetto elastico che si adatta molto meglio alle modifiche. Questo viene fatto evitando di proteggere o gli aspetti di cui si sa che verranno modificati tramite il processo di esternalizzazione: separando gli aspetti che cambiano in modo più rapido degli aspetti funzionali e strutturali del dominio da quelli più stabili a quelli che non cambiano. Tale tecnica consente al progetto del sistema di evolversi e di crescere a causa dei nuovi requisiti senza le alterazioni invasive. Durante l'analisi, le associazioni e le variabilità sono modellate in termini di Gerarchie del tipo. Ogni punto di variabilità identificata ed esternalizzata. Ad esempio, le istanze della variazione come Cliente organizzativo e Cliente singolo possono essere modellate come due realizzazioni di un Tipo di cliente che può essere quindi espanso in base alle necessità. Il tipo esternalizzato (ad esempio, il tipo cliente) è associato con le regole del cliente che misura tutti i clienti e consente di eseguire raffinamenti ed estensioni tramite tipi di regole specifiche per ogni tipo di cliente.

Il primo passo nell'analisi è l'identificazione delle dipendenze sul tipo sia dalla prospettiva funzionale (statica) che del processo (dinamica). L'identificazione dei tipi di processi che dipendono dai tipi di entità (funzionale) è un buon euristico per il refactoring del progetto:

  • Identificare gli elementi comuni di funzione e processo (ad esempio Prenotazione del processo di business).
  • Separare aspetti che cambiano da quelli che cambiano meno. Identificare i tipi chiave relativi alla funzione e al processo che devono cambiare o sono dipendenti (il tipo di prenotazione varia in base al tipo di cliente -- Se il tipo di cliente cambia, come risultato il tipo di prenotazione può cambiare).
  • Esternalizzare le variazioni e creare gerarchie del tipo con istanze conosciute (Il tipo di frequenza è preferito o regolare, la parte è organizzativa o singola).

Questi punti di variabilità sono una parte chiave della creazione dei sistemi che sono elastici e adattabili. Esternalizzando i punti di variabilità, è possibile modificarli senza impattare il resto della progettazione. Quindi, l'effetto ripple della modifica è contenuto e vincolato dai punti di variabilità. Un diagramma di classe UML che mostra questa gerarchia fornisce una roadmap per il progetto dettagliato e infine l'implementazione.

I principi di base del progetto di  associazione e variabilità sono quindi:

  1. Separare gli aspetti del dominio che cambiano da quelli che non cambiano
  2. Separare l'interfaccia dall'implementazione
  3. Reificare ciò che cambia. Se alcuni elementi del dominio sono in flusso costante, allora potrebbe essere garantito reificare quell'elemento in una classe (o a un livello più altro di riutilizzo).
  4. Creare asset ad ogni livello di riutilizzo. I livelli di riutilizzo sono: la classe di base, la gerarchia di eredità, la gerarchia di aggregazione, il cluster, il framework, il componente, il modello, l'architettura generica.
  5. Ogni elemento di riutilizzo ha le proprie regole di funzionamento oltre ai metadati necessari per descrivere in modo riflessivo e adattivo l'elemento di riutilizzo per le query di runtime per le funzioni del servizio

Riferimenti

[Arsanjani]    A. Arsanjani. Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules. Washington University Technical Report number:  wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

[Coplien]    J. O. Coplien. Multi-Paradigm Design for C++. Addison-Wesley Professional; 1st edition, 1998.

[Gabriel]    R. P. Gabriel. Patterns of Software: Tales from the Software Community. Oxford University Press, 1998.

[GBS]    J. van Gurp, J. Bosch and M. Svahnberg. Managing Variability in Software Product Lines. http://citeseer.ist.psu.edu/568368.html

[GHJV]    E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns. Addision-Wesley 1994.

[JGBS01]    J. van Gurp, J. Bosch, and M. Svahnberg. On the notion of variability in software product lines. In Proceedings 2nd Working IEEE / IFIP Conference on Software Architecture (WICSA), pages 45--54. IEEE Computer Society, 2001. http://citeseer.ist.psu.edu/vangurp01notion.html

[JB02]    M. Jaring, J. Bosch, Representing Variability in Software Product Lines: A Case Study, to appear in the Second Product Line Conference (SPLC-2), San Diego CA, August 19-22, 2002. http://citeseer.ist.psu.edu/jaring02representing.html

[MRR04]    Jurgen Meister, Ralf Reussner, and Martin Rohde. Managing Product Line Variability by Patterns. http://se.informatik.uni-oldenburg.de/pubdb_files/pdf/ManagingProductLineVariabilityByPatterns-Final.pdf

[Parnas]    D. L. Parnas. On the design and Development of Program Families. IEEE Transactions on Software Engineering, SE-2(1):1--9, 1976.

[SBM01]    A. Stephenson, D. Buttle and J. McDermid. Extending Commonality Analysis for Embedded Control System Families. Lecture Notes in Computer Science, Volume 1951, 2001. http://citeseer.ist.psu.edu/stephenson51extending.html

[SGB01]    M. Svahnberg, J. van Gurp, J. Bosch, A Taxonomy of Variability Realization Techniques, submitted June 2001. http://citeseer.ist.psu.edu/svahnberg01taxonomy.html