ID Materiale: GI11-8359-00
© Copyright International Business Machines Corporation 2007. Tutti i diritti riservati. Limitazioni previste per gli Utenti del Governo degli Stati Uniti - L'uso, la duplicazione o la divulgazione sono limitati dal GSA ADP Schedule Contract con IBM Corp.
L'ultima versione di questo documento è disponibile all'indirizzo
http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/readme/readme.html.IBM® Rational® Modeling Extension per Microsoft® .NET è un'estensione per la creazione di modelli C# e CTS per i prodotti Rational per la creazione di modelli UML. Questa famiglia di strumenti di progettazione e sviluppo si basa sul framework Eclipse open-source. Il software Modeling Extension per Microsoft .NET include plugin che consentono ad architetti software e sviluppatori di modelli di visualizzare applicazioni C# e tipi CTS e di creare codice C# ben strutturato utilizzando UML 2 (Unified Modeling Language).
Con Rational Modeling Extension per Microsoft .NET è possibile:
- Importare le soluzioni .NET da Microsoft Visual Studio 2005 per creare un'immagine di mirror della soluzione nel progetto Eclipse.
- Visualizzare le applicazioni C#.
- per scoperta architetturale e analisi dipendenze, utilizzando diagrammi di navigazione
- per documentare la struttura delle applicazioni, utilizzando diagrammi di classe
- per documentare le interazioni di classi implementate e what-if utilizzando diagrammi di sequenza
- per rappresentare tipi .NET in diagrammi in modelli UML secondo i principi di funzionamento della "creazione di modelli misti".
- Trasformare modelli UML in codice C#.
- Trasformare le modifiche nel codice C# in un modello UML
Per gli ultimi dettagli sui requisiti di installazione, consultare la versione aggiornata del file readme all'indirizzo: http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/readme/readme.html.
È inoltre possibile visualizzare la guida all'installazione per il proprio prodotto dal launchpad di installazione e nella directory dei documenti del CD del prodotto.
Rational Modeling Extension for Microsoft .NET richiede IBM Installation Manager v1.0.0.2 o successivo e IBM Rational Software Architect, IBM Rational Software Modeler, o IBM Rational Systems Developer, versioni 7.0.0.1. L'installazione del software non continua se non sono installate le versioni richieste.
Per informazioni sull'installazione di IBM Rational Modeling Extension for Microsoft .NET, Versione 7.0, consultare le istruzioni di disinstallazione presenti sul Web, all'indirizzo http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/install_instruction/install.html.
È inoltre possibile visualizzare la guida all'installazione per il proprio prodotto dal launchpad di installazione e nella directory dei documenti del primo CD del prodotto.
È possibile installare questa funzione per utilizzarla con IBM Rational Software Architect v7.0.0.1, IBM Rational Software Modeler, v7.0.0.1, o IBM Rational Systems Developer, v7.0.0.1. La procedura di seguito riportata fornisce una panoramica del processo di installazione. Per istruzioni più dettagliate, consultare la guida all'installazione di IBM Rational Modeling Extension per Microsoft .NET.
Per effettuare l'installazione:
- Accertarsi che il prodotto per la creazione di modelli Rational UML, come indicato in alto, sia installato.
- In IBM Installation Manager selezionare il prodotto host con cui dovrà essere installata l'estensione di creazione modelli.
L'estensione di creazione modelli condivide la shell con il prodotto host e utilizza la medesima istanza di Eclipse.- Seguire la procedura guidata di Installation Manager per completare l'installazione dell'estensione creazione modelli.
Queste note al rilascio includono informazioni non disponibili prima del completamento della documentazione relativa al prodotto. Utilizzare le seguenti migliori pratiche e le linee guida quando si creano modelli delle applicazioni .NET utilizzando il profilo C#.
1. Ogni qualvolta viene aperto un prodotto di creazione modelli UML Rational con l'estensione, deve essere aperto Visual Studio 2005 Standard o Professional Edition.
Nota: nella guida all'installazione come requisito software viene elencato "Visual Studio 2005". Tale requisito viene corretto in "Visual Studio 2005, Standard Edition o Professional Edition." Le edizioni Express non sono supportate.
2. Utilizzo di modelli precedentemente importati da Rational XDE in Rational Software Architect versione 6.x
Se sono stati precedentemente importati modelli da Rational XDE in Rational Software Architect versione 6.x ed è stata effettuata (o si prevede di effettuare) la migrazione di tali modelli in un prodotto Rational Software Architect versione 7.0.0.1 utilizzando anche l'estensione, è necessario installare anche la funzione di Rational XDE per l'importazione di modelli dei prodotti Rational Software Architect installati.
3. Mentre si nominano i pacchetti nel modello, non utilizzare il carattere punto ‘.’ (.) nei nomi del pacchetto. Ad esempio, se sono necessari ‘xtool’ di pacchetti nidificati in ‘ibm’ in ‘com’, invece di denominare un singolo pacchetto “com.ibm.xtools”, utilizzare una struttura gerarchica di pacchetti e creare un pacchetto “com,” nidificato nel pacchetto “ibm” nidificato in “xtools”. Questa notazione ha sempre una rappresentazione unica, e sarà utile per ridurre al minimo modifiche di fusione non corrette nella trasformazione del codice in modello.
4. Applicare stereotipi C# solo quando è necessario impostare alcuni valori specifici di C# tramite le proprietà degli stereotipi. Altrimenti, se il codice identifico è stato generato senza applicare lo stereotipo, la trasformazione C#-UML assume che nessuno stereotipo è stato utilizzato durante la trasformazione UML a C# precedente, e la finestra Riconcilia si apre mostrando un delta che suggerisce che bisognerebbe eliminare lo stereotipo dal modello UML.
5. Il profilo C# al momento non definisce limiti, in questo modo le combinazioni non valide di stereotipi applicati non vengono rilevate. Evitare utilizzi non validi di stereotipi di profili. Ad esempio, l'applicazione di <<CSharpClass>> e <<CSharpInterface>> non è valida e risulta in un funzionamento della trasformazione imprevedibile.
6. Nella creazione modelli di tipi parziali, l'utente deve utilizzare un tipo vuoto come tipo parziale su cui ciascuna parte viene mostrata come parte dipendente. Includere il tipo parziale vuoto creato su modelli (la fonte) e i tipi parziali definiti (con relazioni di dipendenza all'origine) in un singolo pacchetto nel modello. In questo modo tutte le parti del tipo parziale sono definite in un pacchetto nel modello. Il nome dell’origine verrà utilizzato come nome tipo e il nome di un'altra parte non viene utilizzato come nome tipo. Utilizzando un modello di associazione, ciascuna parte parziale può essere diretta in un diverso file. Durante la trasformazione da codice a modello, i nomi utilizzati dall'utente per ciascuna parte non sono noti e quindi la trasformazione genera i nomi come <typenome>_<filename> che vengono visualizzati come una differenza nella finestra di dialogo di fusione.
7. In C#, possono essere utilizzati tipi generici solo se vengono specificati i valori di parametri di tipo; si dovrebbe costruire, cioè, un nuovo tipo per un tipo generico tramite l'associazione dei relativi parametri di tipo. In tal modo, una classe List con parametro T può essere utilizzata usando List<String> ecc. In UML i tipi costruiti in questo modo verranno rappresentati come binding di modelli e i nomi di tali tipi no, durante la trasformazione di codice in UML per generare il modello temporaneo. In tal modo, i tipi costruiti appaiono come nomi di tipi anonimi che verranno mostrati come differenza nella finestra di dialogo di fusione, e l'utente dovrà associarli all'associazione di modello effettiva nel modello di destinazione.
Gli operatori sovraccarichi vengono creati in base ai modelli come operazioni. Ad esempio, presumere di sovraccaricare i due operatori nel contesto di classe C1 e di voler creare un modello di quest'attività con Modeling Extension for Microsoft .NET.
Uguale (==)
Non uguale (!=)I seguenti passaggi descrivono come il sovraccarico degli operatori può essere creato in base ai modelli utilizzando questo esempio.
Prerequisiti:
creare un modello UML o aprirlo.Per creare il modello degli operatori sovraccarichi:
- Creare una nuova classe nel modello UML denominato C1.
- Aggiungere una nuova operazione alla classe C1 e nominare l'operatore !=. Questo operatore contiene l'implementazione per l'operatore sovraccarico !=.
- Definire l'operatore nel seguente modo.
a. Impostare la visibilità dell'operazione recentemente creata in Pubblica.
b. Impostare i qualificatori dell'operazione recentemente creata in Statici.
c. Impostare il tipo di restituzione dell'operazione recentemente creata in <Tipo primitivo>bool.
d. Aggiungere due parametri del tipo C1 nell'operazione recentemente creata e nominarli c1 e c2.- Aggiungere un'altra operazione alla classe C1 e nominare l'operatore ==. Questo operatore contiene l'implementazione per l'operatore sovraccarico ==.
- Definire l'operatore come nel passo 3.
La creazione di modelli dell'operatore sovraccarico != e == nel contesto della classe C1 è completa.
Queste note sul rilascio includono informazioni specifiche sulla versione, tra cui problemi e limitazioni non disponibili prima del completamento della documentazione relativa al prodotto.
Il software di estensione creazione modelli non effettua la notifica all'utente che il codice importato non è stato compilato correttamente. Se il progetto C# importato contiene errori di sintassi nel codice, nel software di estensione creazione modelli l'indicatore degli errori non verrà visualizzato in Esplora progetti o nei diagrammi del visualizzatore.
Soluzione temporanea:: Accertarsi che il codice C# venga compilato correttamente in Visual Studio .NET prima di importarlo in Modeling Extension per Microsoft .NET.
- Modeling Extension for Microsoft .NET riconosce e comunica solo con la prima istanza di Visual Studio 2005 che è aperta. Eseguire solo un'istanza di Visual Studio alla volta su una macchina dove si sta utilizzando Modeling Extension for Microsoft .NET.
- Se Modeling Extension per Microsoft .NET è in esecuzione, non chiudere o aprire una soluzione differente (oltre a quella importata) in Visual Studio.
- Tenere sempre aperta un'istanza di Visual Studio 2005; Modeling Extension per Microsoft .NET riconoscerà e comunicherà solo con la prima istanza di Visual Studio 2005.
- Quando viene importata una soluzione in Modeling Extension per Microsoft .NET, tale soluzione crea progetti Eclipse nello spazio di lavoro Eclipse per ogni progetto C# corrispondente. Il progetto creato in Eclipse avrà lo stesso nome del progetto C# nella soluzione di Visual Studio 2005. Di seguito vengono riportate alcune importanti considerazioni da tenere presenti punti riguardo i progetti:
- I progetti creati in Eclipse avranno collegamenti ai file C# e agli assemblaggi .NET utilizzati dai progetti C# corrispondenti nella soluzione Visual Studio 2005. Tali collegamenti rappresentano l'unica maniera per Modeling Extension per Microsoft .NET di richiamare, aggiornare e visualizzare informazioni sui progetti Visual Studio 2005 e sui relativi contenuti in Eclipse. Tali collegamenti, in effetti, hanno la funzione di visualizzare progetti C# in Eclipse.
- Con l'eccezione di utilizzare le trasformazioni UML-C#, evitare di utilizzare i meccanismi Eclipse per modificare i progetti importati. L'utilizzo dei meccanismi Eclipse per rinominare questi progetti o per modificarne i contenuti può portare a risultati non previsti. In particolare, evitare di creare o aggiungere modelli UML (.emx) o file di diagramma (.dnx) nei progetti. A tale scopo, invece, creare progetti separati (come il progetto UML) in Eclipse. È necessaria attenzione per evitare la creazione di file di diagramma (.dnx) nei progetti importati, poiché quando vengono creati nuovi diagrammi, il framework di visualizzazione inserisce in modo predefinito le posizioni nei progetti in cui risiedono gli elementi visualizzati.
- È possibile chiudere e riaprire i progetti importati in modo sicuro. È inoltre possibile eliminarli, ma non “eliminare i contenuti sottostanti” (se è necessario eliminare un progetto Visual Studio e tutti i suoi contenuti, fare ciò da Visual Studio).
- Una volta importata la soluzione Visual Studio 2005 in Eclipse, evitare di rinominare i progetti C# in Visual Studio 2005. Se è necessario rinominare un progetto allora seguire la procedura di seguito riportata:
- Eliminare il progetto (importato) Eclipse corrispondente (ma non “eliminare i contenuti sottostanti”).
- Rinominare il progetto in Visual Studio.
- Reimportare la soluzione Visual Studio (la soluzione di Modeling Extension for Microsoft .NET può importare in modo incrementale la soluzione: questa capacità è anche utile per l'importazione di progetti C# aggiunti nella soluzione Visual Studio 2005.
- Prima di eseguire le azioni in Modeling Extension for Microsoft .NET, accertarsi che i progetti C# non contengano errori di sintassi e che vengano compilati correttamente in Visual Studio 2005. Modeling Extension for Microsoft .NET utilizza le API dei modelli di codice Visual Studio per analizzare i file C#. Queste API restituiscono risultati non corretti e valori NULL se ci sono errori nei file C#. Ad esempio, se si modifica un file C# in Visual Studio, allora Aggiornare il progetto in Eclipse e si vede che il file non può essere espanso in Esplora progetto, ciò potrebbe essere perché gli errori di sintassi C# sono stati introdotti dalla modifica.
La soluzione preferibile è passare a Visual Studio 2005, correggere tutti gli errori di sintassi, ricreare la Soluzione e aggiornare il progetto importato in Eclipse per ottenere le modifiche. È particolarmente importante che le soluzioni in Visual Studio si trovino in uno stato pulito e costruito quando si applicano le trasformazioni.- Modeling Extension for Microsoft .NET utilizza un meccanismo COM per sincronizzare con Visual Studio 2005. Le chiamate COM possono avere esito negativo o essere rifiutate quando Visual Studio è occupato. Non lavorare su o rendere attivo Visual Studio 2005 quando si effettuano le seguenti operazioni in Modeling Extension for Microsoft .NET:
- Importazioni delle soluzioni .NET
- Aggiornamento progetto
- Espansione dei progetti importati o dei file in Esplora progetto (ad esempio, espandere la vista ad albero)
- Avvio di Modeling Extension for Microsoft .NET in uno spazio di lavoro in cui è stata precedentemente importata una soluzione Visual Studio 2005
- Composizione del diagramma di visualizzazione .NET
- Esecuzione di una trasformazione UML-C# o C#-UML
- Se non si prevede di esplorare il contenuto di tipi definiti in assemblaggi del framework .NET (ad esempio, per trovare quali operazioni o campi sono contenuti nel tipo), allora utilizzare l'opzione "Durante l'analisi degli assemblaggi .Net considera solo tipi" quando si importa la soluzione Visual Studio 2005 nell'area di lavoro Eclipse. Tale opzione è disponibile nella prima pagina della procedura guidata di Importazione soluzione .NET. In tal modo, l'importazione della soluzione viene effettuata più velocemente, così come la visualizzazione di tipi C# e .NET.
- In Visual Studio 2005, abilitare sempre l'opzione per caricare automaticamente le modifiche. Tale opzione viene abilitata selezionando la casella“Carica automaticamente le modifiche", disponibile nella pagina Ambiente-> Documenti della finestra Opzioni. È possibile aprire tale finestra tramite “Strumenti-Opzioni->Ambiente->Documenti->Rileva le modifiche di un file all'esterno dell'ambiente .>Carica automaticamente le modifiche salvate”.
- È possibile modificare la codifica di progetti C# tramite Eclipse selezionando l'opzione proprietà dal menu di contesto dei progetti importati. Tenere presente che tale codifica richiederà più tempo del normale, poiché i progetti Visual Studio generalmente hanno dimensioni maggiori.
Utilizzando una classe/struttura/interfaccia nidificata per definire il tipo di un elemento in una classe/struttura/interfaccia esterna, il nome del tipo include il nome dei tipi esterni, anche se il tipo e l'elemento vengono definiti nella medesima classe. Al momento non si conosce nessuna soluzione temporanea. Questo problema sarà riportato nelle versioni future.
Ad esempio il modello di seguito riportato:
- OuterClass
+ InnerClass
+ attribute1 : InnerClassProdurrà quanto segue come parte del codice generato per InnerClass, inOuterClass.cs:
private OuterClass.InnerClass attribute1;
La trasformazione di inoltro dei caratteri unicode presente in un modello UML, come i nomi classi, la documentazione ecc... non sono supportati in questo rilascio. Tutti i caratteri unicode verranno generati come '?' nei file C# corrispondenti.
Quando è installato Modeling Extension for Microsoft .NET con IBM Rational Software Modeler, la presentazione viewlet che dimostra che le funzioni Modeling Extension for Microsoft .NET non sono disponibili nella pagina di benvenuto facendo clic sulla Panoramica > Differenti approcci di modellamento... > Ulteriori informazioni relative alle trasformazioni. La presentazione è disponibile nella Galleria delle esercitazioni.
Per visualizzare la presentazione in Rational Software Modeler, fare clic su Guida > Esercitazioni, espanderePresentazioni, e quindi fare clic su Trasformazione dei modelli UML nel codice C#. Fare clic su Avvia presentazione per avviare il viewlet.
In alcuni casi, quando si esegue nuovamente la trasformazione UML-C# con l'associazione e si creano le opzioni di relazione origine a destinazione, il codice generato è corrotto. Ad esempio, potrebbe esserci un simbolo"/" mancante nei commenti del codice e altri errori di codice.
Questo si verifica quando la relazione manifest si sposta tra le risorse in modo che l'utilizzo possa combinare il codice in un file .cs o separare il codice in due file.
Questo problema verrà risolto in un rilascio futuro.
La prima volta che viene eseguita una trasformazione C#-UML su un modello del codice XDE importato, la finestra di dialogo di riconciliazione mostra molte differenze relative agli stereotipi. Questo perché gli stereotipi XDE relativi nel modello importato non sono riconosciuti dalla trasformazione C#-UML. Questo problema verrà corretto in un rilascio futuro.
Soluzione temporanea:
Eseguire una trasformazione di "pulizia" unica immediatamente dopo aver importato il modello del codice XDE (prima di eseguire le modifiche al modello o al codice). Eseguire la trasformazione C#-UML. Quando la finestra di dialogo di riconciliazione appare, accettare tutte le modifiche suggerite in favore del modello temporaneo (il modello mostrato nelpannello sinistro). Questo risulta nella rimozione degli stereotipi dal modello persistente in modo che le esecuzioni successive della trasformazione C#-UML non riporti più le differenze.
Considerare un modello che contiene le proprietà UML stereotipate come <<CSharpProperty>>, <<CSharpField>>, ecc. il cui tipo non è impostato e il codice di origine specifica i tipi dagli assemblaggi come tipi di dati per questi elementi. Se la trasformazione C#-UML viene eseguita su tale codice e modello di destinazione, allora la fusione mostra il tipo dati in modo corretto (che sarà un UML vizref) che verrà impostato per l'elemento ma una volta completata l'operazione, il tipo di dati manca per questi elementi (null). Questo è un problema conosciuto e verrò corretto in un rilascio futuro.
Se un nome del file del modello contiene un simbolo # ed è specificato come la destinazione di una trasformazione per C#-UML, la finestra di dialogo di fusione non riesce a mostrare i 2 pannelli con il modello temporaneo e di destinazione per l'unione delle differenze. Questo problema verrà corretto in un rilascio futuro .
Se un modello importato XDE viene specificato come la destinazione di una trasformazione C#-UML ed è anche specificato il modello di associazione nella configurazione della trasformazione, allora la trasformazione C#-UML non riesce con un eccezione Null Pointer. Questo problema viene visto solo per i modelli importati XDE con il modello di associazione.
Soluzione temporanea:
Eliminare il pacchetto <<Risorse>> dal modello importato e quindi eseguire la trasformazione. L'eliminazione del pacchetto delle risorse non porta alla perdita di informazioni poiché il modello di associazione avrà informazioni relative a diversi file, ecc. Il problema verrà corretto in un rilascio futuro.
Se un modello di destinazione viene creato utilizzando il pulsante Crea nuovo contenitore nell'editor di configurazione della trasformazione, a volte l'attenzione viene spostata in un modello appena creato ed il nuovo modello non viene selezionato nel pannello di destinazione (dove C#-UML è la trasformazione di inoltro).
Soluzione temporanea:
Passare manualmente all'editor di configurazione e selezionare il modello di destinazione. Questo è un problema conosciuto e verrò corretto in un rilascio futuro.
Se viene eseguita una trasformazione UML-C# con il modello di associazione modificato, in modo tale che questo possa portare all'eliminazione di un file, e se l'utente decide di eliminare il file nella finestra di dialogo Eliminazione file, quel file non viene effettivamente eliminato. Questo viene solo rimosso dal progetto per preservarne i contenuti.
Successivamente, se la trasformazione UML-C# viene nuovamente eseguita in modo tale che porti alla nuova creazione del file eliminato (rimosso dal progetto) nel passo precedente, questo file (ricreato) ha i contenuti precedenti (originali) invece dei nuovi contenuti.
Soluzione temporanea:
La soluzione temporanea per questo problema è di eliminare tali file dal filesystem dopo il passo 1. L'elenco di tali file può essere ottenuto da:
- la finestra di dialogo Eliminazione file, se la trasformazione non è in esecuzione non presidiata.
- l'elenco di file disponibili sul filesystem confrontati ai file che appartengono al progetto, se la trasformazione è configurata per essere eseguita in modalità non presidiata.
- l'elenco di risorse vuote nel modello di associazione (se ce ne sono).
La riapplicazione della trasformazione UML-C# con l'opzione Crea relazioni da origine a destinazione selezionata nella pagina Comune della configurazione di trasformazione dopo aver rimosso la tag @generated dal codice C# porta alla generazione di un'altra tag URI nel codice. Questo è stato osservato solo con le variabili.
La tag URI è della forma:
//@C#_transform [
// _URI=platform:/resource/UML%20project/Blank%20Model%20t1.emx#_cd19cKJhEdurjYIa4vhLGA//]
L'esecuzione multipla della riapplicazione porta alla generazione di più tag URI nel file C#.
Soluzione temporanea:
Non esiste alcuna soluzione per questo problema.
Se la tag @generated per un setter generato viene rimossa e il suo tipo viene modificato nel codice prima di rieseguire la trasformazione UML-C#, viene generato un altro setter.
La soluzione temporanea è di fare in modo che il tipo cambi nel modello.
Quando viene eseguita la trasformazione UML-C# con l'opzione Sostituisci elementi UML selezionata, i valori letterali di enumerazione presenti nel modello UML non sono sostituiti. Se un'enumerazione E ha due valori letterali, L1 e L2, e E è contenuto dal pacchetto p, allora dopo aver eseguito l'enumerazione della trasformazione E viene correttamente sostituito da una combinazione di tasti nell'enumerazione C# generata nel codice; ma i valori letterali L1 e L2 appaiono contenuti nel pacchetto p dopo la trasformazione.
Soluzione temporanea:
Non esiste alcuna soluzione per questo problema.
Il programma di importazione del modello del codice XDE C# (File -> Importa -> Altro -> Soluzione XDE .Net) in alcuni casi non migra i setter degli indicizzatori C# in modo corretto. L'importazione di un progetto C# contenuto in una soluzione XDE .NET specificando il modello UML corrispondente (file .emx; importato utilizzando il programma di importazione del modello di base XDE) e quindi eseguendo la trasformazione UML-C# con il modello migrato come l'origine ed il progetto migrato come destinazione, potrebbe non risultare negli stessi setter che esistevano nel codice prima del processo. In alcuni casi, il setter non viene generato con un altro parametro (con valore nominale) che risulta in un errore di compilazione--poiché C# non consente al valore del nome di essere utilizzato per un parametro esplicito del setter.
Soluzione temporanea:
Non esiste alcuna soluzione per questo problema.
Quando viene eseguita una trasformazione UML-C# con l'opzione Sostituisci elementi UML sulla pagina Comune dell'editor di configurazione della trasformazione e viene utilizzato un modello di associazione, la trasformazione non sostituisce gli elementi UML nel modello di origine per il quale i file di origine sono generati nelle cartelle. Solo gli elementi UML per i quali il codice viene generato nella cartella root del progetto di destinazione C# sono sostituiti da collegamenti agli elementi corrispondenti nel codice.
Soluzione temporanea:
Dopo aver eseguito la trasformazione UML-C# per la prima volta, il modello UML ed il modello di associazione verranno indicati come sporchi; eseguire nuovamente la trasformazione senza modificare la configurazione della trasformazione o il modello di associazione. Ora tutti gli elementi UML nel modello verranno sostituiti da collegamenti.
Quando i modelli del codice Rational XDE sono importati, tutti i "modelli di assemblaggio" (conosciuti anche come "modelli di sistema" o i "modelli di riferimento") a cui i modelli del codice fanno riferimento vengono importati e ad essi si fa riferimento nell'ambiente basato su Eclipse. Come risultato, l'apertura del modello del codice importato potrebbe impiegarci troppo tempo.
Soluzione temporanea :
Eliminare i modelli di assemblaggio importati una volta che i modelli del codice sono stati importati in modo corretto. Questa soluzione temporanea può essere utilizzata se si sceglie di sostituire gli elementi UML del modello di codice importato con i riferimenti del codice diretto e di utilizzare la teoria delle operazioni di "modellamento misto", oppure è possibile scegliere invece di conservare gli elementi UML del modello del codice ed utilizzare la teoria delle operazione “RTE (round-trip engineering) vere” (trasformazioni di inoltro e contrarie e riconciliazione).Effetti della soluzione temporanea:
1. L-eliminazione dei modelli di assemblaggio renderà l'apertura e la modifica dei modelli del codice importati molto più veloce.2. Il prodotto potrebbe visualizzare avvertimenti o “errori” relativi ai modelli di riferimento “mancanti” quando il modello del codice importato viene aperto. Questi avvertimenti possono essere ignorati.
3. Il prodotto potrebbe visualizzare avvertimenti o “errori” relativi a modelli di riferimento"mancanti" quando la convalida viene eseguita rispetto al modello del codice importato. Questi possono essere ignorati.
Esempio:
Presumere di avere un progetto Visual Studio 2003 C# chiamato Project1 con il modello di base XDE corrispondente"Project1.mdx". Presupporre che questo modello faccia riferimento ai seguenti cinque modelli di sistema: System.mdx, mscorlib.mdx, System.Data.mdx, System.Web.mdx, e System.Drawing.mdx.- Iniziare a migrare il progetto VS 2003 a VS 2005, utilizzando il programma di utilità di migrazione VS 2005
Importare il modello del progetto Project1.mdx, utilizzando l'importazione del modello XDE (File > Importa > Altro >Modello XDE Rational). Si sceglie di importare tutti i modelli di riferimento (il programma di importazione richiede che questo assicuri l'integrità del modello durante il processo di importazione).- Questo risulta nella creazione dei file six .emx nello spazio di lavoro di Eclipse che sono“Project1.emx,” “System.emx mscorlib.emx,” “System.Data.emx,” “System.Web.emx,” e“System.Drawing.emx.”
- Successivamente importare la soluzione Visual Studio 2005 (File > Importa > Altro > Soluzione .NET). Il modello .mdx di legacy verrà rilevato in quella soluzione e verrà chiesto di fornire il nome dei modelli di codice importati, in questo caso “Project1.emx.” A questo punto, viene anche data l'opzione di sostituire gli elementi UML di Project1.emx con riferimenti al codice nella soluzione importata. Utilizzare quella opzione se si desidera eseguire il “modellamento misto” ma non utilizzarlo se si desidera eseguire l'“RTE true.”
- Il processo di importazione è ora completa. Quando successivamente si apre il modello “Project1.emx”, il framework UML prova a caricare tutti i cinque modelli di riferimento e così a risolvere i riferimenti dagli elementi in "Project1.emx" agli elementi in quei modelli di riferimento. Questa è la causa del ritardo nell'apertura e nell'utilizzo del modello XDE importato.
- Per alleviare il carico delle prestazioni, semplicemente selezionare ed eliminare ognuno dei cinque modelli di assemblaggio. Come notato precedentemente, questo migliora le prestazioni e risulta nell'apparizione di avvertimenti o “errori” quando si apre e si convalida“Project1.emx” ma non influenza in modo negativo le operazioni di modellamento e trasformazione che si desidera eseguire con “Project1.emx”
Se una trasformazione C#-UML viene eseguita in modalità non presidiata e tutte le altre opzioni sono selezionate nell'editor di configurazione di trasformazione, la trasformazione non riesce. In modo specifico, questo accade quando le nuove modifiche nel modello di destinazione contengono gli elementi stereotipati (ad esempio, <<CSharpStruct>>) che devono essere uniti in modalità non presidiata. Questo problema verrà risolto in un rilascio futuro.
Se una trasformazione C#-UML viene eseguita su un file di origine che contiene gli operatori sovraccaricati come != o == per ottenere questi operatori nel modello di destinazione, sull'esecuzione successiva della trasformazione senza modifiche al codice, la finestra di dialogo di fusione non dovrebbe mostrare alcuna modifica. Tuttavia, la finestra di dialogo di fusione mostra le modifiche in modo non corretto relative alla ridenominazione dei parametri.
Questo problema verrà risolto in un rilascio futuro.
Per le trasformazioni C#, è necessario utilizzare un modello di associazione per specificare la gerarchia del filesystem di come dovrebbe essere organizzato il codice. La rinominazione delle classi, delle interfacce, ecc... tramite il modello di associazione non è ancora supportato. Il progetto di un'applicazione C# può essere eseguito in 2 prospettive:
1. Progetto sistema logico
2 Progetto sistema fisico (verrà specificato come modello di associazione)
Il modello del progetto logico normalmente contengono i diversi spazi nome, i diversi tipi e il rapporto di eredità, gli attributi, le funzioni ecc...
La prospettiva di progetto fisica che utilizza un modello di associazione include le informazioni di distribuzione per la trasformazione C#. Questo significa che si è in grado di controllare il modo in cui si desidera che la trasformazione posizioni i diversi costrutti logici in diversi file. Per impostazione predefinita, senza un modello di associazione, la trasformazione UML-C# genera ogni tipo, ad esempio una classe o un'interfaccia, in un file il cui nome è lo stesso del nome del tipo ma è posizionato nella cartella root del progetto Visual Studio. Ad esempio, la classe"MyClass" verrà generata in un file chiamato "MyClass.cs" in assenza di un modello di associazione. Tuttavia, se l'utente desidera che il codice sia generato in un file chiamato "Test.cs", questo deve specificare questo nel modello di associazione tramite la risorsa che manifesta quella classe "MyClass".
Il modello di associazione è utilizzato solo per specificare la cartella o la gerarchia di file per generare il codice. Non si può verificare nessuna rinominazione utilizzando un modello di associazione.
Notare che il progetto logico (modello di origine della trasformazione) ed il progetto fisico (modello di associazione di trasformazione) sono solo modelli UML. L'unica differenza è che:
- I pacchetti UML nel modello di origine logico rappresentano gli spazi nome C#.
- I pacchetti UML nel modello di associazione rappresentano le cartelle sul file system.
Se la trasformazione UML-C# viene annullata dopo aver eseguito la trasformazione con l'opzione del modello di associazione abilitata e con l'opzione Sostituisci elementi UML selezionata, il modello di associazione sarà in uno stato non corretto. Se la trasformazione UML-C# viene eseguita con il modello di associazione non corretto, i file C# sono generati in una posizione non corretta.
Soluzione temporanea:
L'utente deve annullare manualmente le modifiche al modello di associazione prima di eseguire nuovamente la trasformazione UML a C#. Un modo in cui è possibile eseguire questa operazione è di chiudere il modello di associazione e scegliere di non salvare le modifiche.
L'IBM Rational Software Support fornisce assistenza tecnica.
Per informazioni relative a contatti e linee guida o ai materiali di riferimento necessari al momento della richiesta di supporto, consultare IBM Software Support Handbook.
Per domande frequenti (FAQ), elenchi di problemi noti e correzioni, e altre informazioni di supporto, visitare la pagina IBM Rational Software Support.
Per notizie, eventi ed altre informazioni relative ai prodotti software Rational, visitare il sito Web IBM Rational Software.
Prima di contattare il supporto software di IBM Rational, raccogliere le informazioni di background necessarie per descrivere il problema. Nel descrivere un problema a uno specialista del supporto software IBM, è necessario essere quanto più specifici possibile e includere tutte le informazioni di background di rilievo, in modo che lo specialista possa essere d'aiuto per risolvere il problema in maniera efficace. Per guadagnare tempo, predisporre le risposte alle seguenti domande:
- Quale versione del software si stava eseguendo quando si è verificato il problema?
- Si è in possesso di log, tracce oppure messaggi relativi al problema?
- È possibile riprodurre il problema? In caso affermativo, quali sono i passi per riprodurlo?
- Esiste una soluzione temporanea al problema? In caso affermativo, predisporre una descrizione della soluzione temporanea.
© Copyright IBM Corporation 2007. Tutti i diritti riservati.
Queste informazioni sono state sviluppate per i prodotti e i servizi offerti negli Stati Uniti. È possibile che negli altri paesi IBM non offra i prodotti, i servizi o le funzioni illustrati in questa documentazione. Consultare il rappresentante locale IBM per informazioni sui prodotti e sui servizi attualmente disponibili nel proprio paese. Qualsiasi riferimento relativo a prodotti, programmi o servizi IBM non implica che solo quei prodotti, programmi o servizi IBM possano essere utilizzati. In sostituzione a quelli forniti da IBM, possono essere usati programmi, prodotti o servizi funzionalmente equivalenti che non comportino violazione dei diritti di proprietà intellettuale o di altri diritti di IBM. È comunque responsabilità dell'utente valutare e verificare la possibilità di utilizzare altri prodotti, programmi o servizi non IBM.
IBM può essere titolare di brevetti o domande di brevetto in corso relativi a quanto trattato nella presente documentazione. La fornitura di tale documentazione non implica la concessione di alcuna licenza su di essi. Chi desiderasse ricevere informazioni relative a licenze può rivolgersi per iscritto a:
IBM Director of Commercial Relations
IBM Europe
Schoenaicher Str.220
D-7030 Boeblingen
Deutschland
Per richieste di licenza relative a informazioni double-byte (DBCS) scrivere al seguente indirizzo:IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, JapanIl seguente paragrafo non è valido per il Regno Unito o per tutti i paesi le cui leggi nazionali siano in contrasto con le disposizioni in esso contenute: INTERNATIONAL BUSINESS MACHINES CORPORATION FORNISCE QUESTA PUBBLICAZIONE "NELLO STATO IN CUI SI TROVA" SENZA ALCUNA GARANZIA, IMPLICITA O ESPLICITA, IVI INCLUSE EVENTUALI GARANZIE DI COMMERCIABILITÀ E IDONEITÀ A UNO SCOPO SPECIFICO. Alcuni stati non consentono la rinuncia a garanzie esplicite o implicite in determinate transazioni, quindi la presente dichiarazione potrebbe non essere a voi applicabile.
Questa pubblicazione potrebbe contenere imprecisioni tecniche o errori tipografici. Le informazioni incluse in questo documento vengono modificate su base periodica; tali modifiche verranno incorporate nelle nuove edizioni della pubblicazione. IBM si riserva il diritto di apportare miglioramenti e/o modifiche al prodotto o al programma descritto nel manuale in qualsiasi momento e senza preavviso.
Coloro che detengono la licenza su questo programma e desiderano avere informazioni su di esso allo scopo di consentire: (i) uno scambio di informazioni tra programmi indipendenti ed altri (compreso questo) e (ii) l'uso reciproco di tali informazioni, dovrebbero rivolgersi a:
Intellectual Property Dept. for Rational Software
IBM Europe
20 Maguire Road
Lexington, MA
02421-3112
USAQueste informazioni possono essere rese disponibili secondo condizioni contrattuali appropriate, compreso, in alcuni casi, l'addebito di un canone.
Il programma su licenza descritto in questa documentazione e tutto il materiale su licenza ad esso relativo vengono forniti da IBM nei termini dell'IBM Customer Agreement, dell'IBM International Program License Agreement o di eventuali accordi equivalenti intercorsi tra le parti.
Le informazioni relative a prodotti non IBM sono state acquisite presso i fornitori di tali prodotti, gli annunci da loro pubblicati o altre fonti disponibili pubblicamente. IBM non ha verificato tali prodotti, quindi non può confermarne la qualità delle prestazioni, la compatibilità o altre dichiarazioni relative a prodotti non IBM. Eventuali quesiti sulle funzioni di prodotti non IBM dovrebbero essere indirizzati ai fornitori.
Tutte le istruzioni relative alla futura direzione o intenzione di IBM sono soggette a modifiche o a ritiro senza preavviso.
Marchi
I seguenti termini sono marchi IBM (International Business Machines Corporation) negli Stati Uniti e/o in altri paesi:
- developerWorks
- IBM
- Rational
Java e tutti i marchi basati su Java sono marchi di Sun Microsystems, Inc. negli Stati Uniti e/o negli altri paesi.
Microsoft, Windows e Windows NT sono marchi di Microsoft Corporation negli Stati Uniti e/o in altri paesi.
Intel e Pentium sono marchi di Intel Corporation o di società ad essa affiliate negli Stati Uniti e/o in altri paesi.
UNIX è un marchio registrato di The Open Group negli Stati Uniti e/o in altri paesi.
Linux è un marchio di Linus Torvalds negli Stati Uniti e/o in altri paesi.
Nomi di altre società, prodotti o servizi, possono essere marchi di altri produttori.