Guida al tool: Strutturazione del modello di implementazione utilizzando Rational Software Architect
Questa guida al tool descrive il modo in cui strutturare il modello di implementazione mediante l'ambiente di modellazione RSA.
Strumento: Rational Software Architect
Estende: Strutturazione del modello di implementazione mediante Rational Software Development Platform
Relazioni
Descrizione principale

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:

Definizione della struttura del modello di implementazione

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:

  1. Creare un nuovo progetto Java e aggiungere riferimenti a librerie.
  2. Aprire il diagramma al quale si desidera aggiungere l'elemento visualizzato.
  3. Passare alla prospettiva Java.
  4. Trovare l'elemento (pacchetto, classe, interfaccia, ecc.) che si desidera aggiungere al modello.
  5. 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.

Regolazione del sottosistema di implementazione

Di seguito, una sequenza di fasi utili all'adattamento dei sottosistemi di implementazione:

  1. 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.
  2. Creare un nuovo sottosistema.
  3. Spostare gli elementi identificati nel nuovo sottosistema.
  4. Tracciare nuove dipendenze. 

Definizione delle importazioni di ciascun sottosistema di implementazione

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).

Definizione della gestione dei programmi eseguibili (e di altri oggetti derivati)

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.

Definizione della gestione delle risorse di test

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.

Aggiornamento della vista implementazione

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.

Valutazione del modello di implementazione

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 icona della guidaPubblicazione di modelli e all'esercitazione icona della guidaPubblicazione di un modello nel Web.