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:
-
Separare gli aspetti del dominio che cambiano da quelli che non cambiano
-
Separare l'interfaccia dall'implementazione
-
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).
-
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.
-
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
|