Operazione: Esecuzione progetto orientato 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
Ruoli | Principale:
| Aggiuntivo:
| Assistenza:
|
Input | Obbligatorio:
| Facoltativo:
| Esterno:
|
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
© Copyright IBM Corp. 1987, 2006. Tutti i diritti riservati.
|
|