Panoramica
Questa guida al tool prevede che sia stata definita la struttura di livello superiore del modello di implementazione
come descritto nelle Linee guida sulla struttura dei modelli per RSx. Le operazioni della guida
consentono di perfezionare questa struttura iniziale.
Le seguenti operazioni vengono effettuate in questa guida al tool:
L'approccio raccomandato è quello MDD - Model Driven Development (vedere Model
Driven Development and Model Driven Architecture). Se tale approccio viene seguito da un team di sviluppo, il
modello di implementazione sarà notevolmente influenzato dall'organizzazione del modello di progettazione. Una volta
identificati i sottosistemi di implementazione, li si dovrebbe modellare in pacchetti o sottosistemi nel modello di
progettazione. In generale, quando vengono identificati i pacchetti nel modello di progettazione, si dovrebbe
considerare in che modo associarli ai progetti specifici di tool. Solitamente i sottosistemi più ampi vengono
associati ai relativi progetti, mentre i pacchetti più dettagliati saranno abbinati a cartelle all'interno dei
progetti. Far riferimento alle sezioni delle Linee guida sulla struttura dei modelli per RSx che illustrano le strutture del
progetto e l'organizzazione interna dei modelli di implementazione e progettazione.
La Vista Implementazione può essere definita utilizzando i pacchetti di
<<prospettiva>> contenenti diagrammi che mostrano i rapporti di dipendenza tra i sottosistemi. A seconda di
quale tipo di trasformazione viene applicata al modello di progettazione, le dipendenze definite tra
pacchetti/sottosistemi possono essere associate a dichiarazioni di import 3GL e di dipendenza dal progetto nei metadati
di quest'ultimo.
Non appena viene creato il codice, è possibile produrre diagrammi UML più dettagliati che mostrano i costrutti del
livello di implementazione e le rispettive relazioni, creando diagrammi di classe direttamente nei progetti per poi
popolarli trascinando in essi artefatti di implementazione. Far riferimento agli argomenti della guida on line che
trattano Visual Editor UML per Java.
Se si richiede la rappresentazione nel modello di implementazione di classi, interfacce, pacchetti specifici ecc. a
partire da una libreria di codici, è possibile utilizzare le capacità di visualizzazione del codice del prodotto per
creare queste rappresentazioni. I seguenti file JAR contengono file che sarebbero interessanti ai fini di progettazione
e sviluppo delle applicazioni J2EE:
-
j2ee.jar, jsf-api.jar, soap.jar, soap-sec.jar (all'interno della directory lib)
-
core.jar, xml.jar, security.jar (all'interno della directory java\jre\lib)
Quando ci si deve riferire a un elemento contenuto in una di queste librerie del modello, eseguire le seguenti
operazioni:
-
Creare un nuovo progetto Java e aggiungere riferimenti a librerie.
-
Aprire il diagramma al quale si desidera aggiungere l'elemento visualizzato.
-
Passare alla prospettiva Java.
-
Trovare l'elemento (pacchetto, classe, interfaccia, ecc.) che si desidera aggiungere al modello.
-
Fare clic con il tasto destro sull'elemento e selezionare Visualizza > Aggiungi a diagramma attuale.
Se si devono rappresentare i veri progetti e pacchetti nei quali si pensa risiedano il codice ed i file correlati,
occorre un modello di panoramica dell'implementazione prima della creazione di qualunque codice. Per maggiori
informazioni, consultare gli argomenti specifici del modello di implementazione nel white paper delle Linee guida sulla struttura dei modelli per RSx.
Di seguito, una sequenza di fasi utili all'adattamento dei sottosistemi di implementazione:
-
Identificare i sottosistemi che sono fonti di problemi, come la dipendenza ciclica, utilizzando:
-
-
diagrammi degli argomenti e di navigazione
-
rilevamento strutturale
-
revisione del codice / analisi del codice strutturale.
-
Creare un nuovo sottosistema.
-
Spostare gli elementi identificati nel nuovo sottosistema.
-
Tracciare nuove dipendenze.
In un ambiente MDD, le dipendenze del modello di implementazione rifletteranno da vicino quelle definite esplicitamente
o implicitamente nel modello di progettazione. Le informazioni specifiche sono determinate dalle trasformazioni di
generazione di codice applicate al modello di progettazione.
Oltre al modello di input, sono necessari altri artefatti per attuare una trasformazione. Occorre definire la
trasformazione e le relative regole prima di dare luogo ad un processo di trasformazione.
Una regola di trasformazione fornisce una descrizione utilizzata dal processo di trasformazione per convertire un
elemento del modello di origine in zero o più elementi del modello di destinazione. Più precisamente, associa elementi
di un determinato livello di astrazione alle relative controparti che si trovano a un livello di astrazione inferiore.
Se si utilizza la trasformazione manuale, ci si deve assicurare che gli sviluppatori abbiano informazioni sufficienti
su come trasformare il modello di progettazione in codice. In sostanza, è necessario fornire loro una definizione di
trasformazione che includa una serie di regole di trasformazione. Questa ulteriore guida può essere realizzata sotto
forma di:
-
elementi tratti da profili documentati
-
note nel modello
-
informazioni aggiuntive nel Documento di architettura software
-
linee guida di sviluppo
Se viene utilizzato un modello della panoramica di implementazione, sarà l'occasione per mostrare le dipendenze
anticipate tra i progetti e i pacchetti, che torneranno utili a identificare i requisiti della build di sistema
(consultare Linee guida sulla struttura dei modelli per RSx).
In un ambiente MDD, secondo il tipo di trasformazione applicato al modello di progettazione, è possibile creare vari
tipi di artefatti distribuibili. Ad esempio, partendo da elementi come le classi di <<controllo>> ed
<<entità>> possono essere creati EJB di sessione ed entità per un target J2EE, che comprendono il codice
per le classi di implementazione più le interfacce più il contenuto descrittore di distribuzione che attribuisce EJB a
JAR EJB, associando questi JAR agli EAR.
Si può scegliere di modellare artefatti distribuibili a livello concettuale, utilizzando un modello di distribuzione.
In tal caso, li si dovrà modellare servendosi di nodi e artefatti UML. Al momento, le trasformazioni incluse nel
tool non rafforzano la semantica dei diagrammi per generare dati di distribuzione, quindi i diagrammi creati
saranno meramente concettuali e utili soltanto ai fini della documentazione.
Si possono anche rappresentare i veri artefatti di implementazione in questi diagrammi rilasciandoli sullo sfondo e
connettendoli (utilizzando le dipendenze) agli elementi concettuali del diagramma.
Una considerazione chiave che influenzerà la struttura delle risorse di test sarà la decisione di come crearle.
Si può scegliere di realizzare i test utilizzando le capacità di test del componente automatico. In questo caso, i
singoli progetti dello scenario di test sono appositamente configurati come parte del processo di creazione. Un
vantaggio significativo di questa funzione risiede nel fatto che si può utilizzare una generazione di codice iniziale e
servirsi poi degli stub del codice come guida alla creazione dello scenario di test.
Mantenere il repository del progetto organizzato come una serie o una gerarchia di directory. Si raccomanda di
conservare le risorse di test in directory di test separate, contenenti i vari tipi di test: di unità, di integrazione,
di sistema.
Se esiste una Vista implementazione separata, occorre mantenerla. La raccomandazione generale presentata nel white
paper Linee guida sulla struttura dei modelli per RSx è di utilizzare i pacchetti di
<<prospettiva>>, contenenti i diagrammi che mostrano i rapporti di dipendenza tra i sottosistemi.
Per assicurarsi che le dipendenze del sottosistema (e altre dipendenze) continuino a utilizzare procedure ottimali
adatte all'evoluzione del sistema, servirsi di Rilevamento strutturale, Revisione del codice, in generale, e Analisi
strutturale, in particolare, al fine di verificare che i modelli seguano le procedure ottimali.
Come sopra descritto, è anche possibile introdurre regole per l'applicazione delle dipendenze identificate. Nella parte
manuale dell'analisi, è consigliabile annotare le regole che non sono ancora state sviluppate e aggiungerle alla serie
di regole che riguarderanno l'iterazione successiva.
Può essere utile pubblicare modelli in formato html. Notare inoltre che è possibile copiare diagrammi su Microsoft Word
e altri programmi.
Per ulteriori informazioni, fare riferimento alla Pubblicazione di modelli e all'esercitazione Pubblicazione di un
modello nel Web.
|