ID del material: GI11-8359-00
© Copyright International Business Machines Corporation 2007. Reservados todos los derechos. Derechos restringidos para los usuarios de Gobierno de EE.UU. - El uso, duplicación o distribución están restringidos por el GSA ADP Schedule Contract con IBM Corp.
La versión más reciente de este documento está disponible en
http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/readme/readme.html.IBM® Rational® Modeling Extension para Microsoft® .NET es una extensión de modelado de C# y CTS para productos de modelado UML de Rational. Esta familia de herramientas de diseño y desarrollo está compilada en la infraestructura Eclipse de código abierto. El software Modeling Extension para Microsoft .NET incluye plug-ins que permiten a los arquitectos de software y los desarrolladores dirigidos por modelo visualizar aplicaciones en C# y tipos de CTS, así como crear código en C# bien construido utilizando UML 2 (Lenguaje unificado de modelado).
Con Rational Modeling Extension para Microsoft .NET puede:
- Importar soluciones .NET desde Microsoft Visual Studio 2005 para crear una imagen duplicada de la solución en el proyecto Eclipse.
- Visualizar aplicaciones en C#.
- para análisis de dependencias y descubrimiento arquitectural, utilizando diagramas de exploración.
- para documentación de la estructura de la aplicación, utilizando diagramas de clase.
- para documentación implementada e interacciones de clase de situación hipotética, utilizando diagramas de secuencia.
- para representación de tipos .NET en diagramas de modelos UML como componente de la teoría "de modelado mixto" de operaciones.
- Transformar modelos UML en código C#.
- Transformar cambios del código C# en el modelo UML.
Para obtener los últimos detalles sobre los requisitos de instalación, consulte la versión actualizada de este archivo Readme en: http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/readme/readme.html.
También puede ver la guía de instalación del producto desde el Launchpad de instalación y en el directorio de documentos del CD del producto.
Rational Modeling Extension for Microsoft .NET requiere IBM Installation Manager v1.0.0.2 o posterior e IBM Rational Software Architect, IBM Rational Software Modeler o IBM Rational Systems Developer, versiones 7.0.0.1. La instalación del software no continuará si las versiones necesarias no están instaladas.
Para obtener información sobre la instalación de Rational Modeling Extension para Microsoft .NET, versión 7.0, consulte las instrucciones de instalación en la web en http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rme/70/docs/install_instruction/install.html.
También puede ver la guía de instalación del producto desde el área de ejecución de instalación y en el directorio de documentación del primer CD del producto.
El software de ampliación de modelado se puede instalar en la compilación de la fecha de disponibilidad general de 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. El procedimiento siguiente proporciona una visión general del proceso de instalación. Para obtener instrucciones más detalladas, consulte la Guía de instalación de IBM Rational Modeling Extension para Microsoft .NET.
Para realizar la instalación:
- Asegúrese de que se ha instalado un producto de modelado UML de Rational, tal como se especifica arriba .
- En IBM Installation Manager, seleccione con qué producto de sistema principal se instalará la ampliación de modelado.
La ampliación de modelado comparte el shell con el producto de sistema principal y utiliza la misma instancia de Eclipse.- Siga las indicaciones del asistente del Gestor de instalación para finalizar la instalación de la ampliación de modelado.
Estas notas del release incluyen información que no estaba disponible hasta después de finalizar la documentación del producto. Siga las siguientes recomendaciones y directrices cuando vaya a modelar aplicaciones .NET utilizando el perfil C#.
1. Visual Studio 2005 Standard o Professional Edition debe estar abierto cuando el producto de modelado UML de Rational se abra con la ampliación.
Nota: La Guía de instalación enumera a "Visual Studio 2005" como requisito de software. Esto se ha corregido para "Visual Studio 2005, Standard Edition o Professional Edition." No se da soporte a las ediciones Express.
2. Utilización de modelos importados previamente de Rational XDE a Rational Software Architect versión 6.x
Si tiene modelos que se han importado previamente de Rational XDE a Rational Software Architect versión 6.x y los ha migrado (o tiene la intención de hacerlo) a Rational Software Architect versión 7.0.0.1 y también utilizan la ampliación, deberá tener instalada la función Rational XDE Model Import de Rational Software Architect.
3. Cuando nombre paquetes en el modelo, no utilice ‘.’ (punto) en los nombres de paquete. Por ejemplo, si necesita paquetes anidados ‘xtools’ dentro de ‘ibm’ dentro de ‘com’, en lugar de nombrar un único paquete “com.ibm.xtools”, utilice la estructura jerárquica de paquetes y cree un paquete, “com,” que anide al paquete “ibm”, que a su vez anide el paquete “xtools”. Esta notación siempre ha sido una representación única y ayudará a reducir cambios de fusión falsos durante la transformación de código en modelo.
4. Aplique estereotipos en C# sólo cuando tenga que establecer algún valor específico en C# a través de las propiedades de estereotipo. De lo contrario, si el código idéntico se generara sin aplicar el estereotipo, la transformación de C# a UML asumiría que no se ha utilizado ningún estereotipo durante la anterior transformación de UML a C#, y la ventana Reconciliar se abriría mostrando un tiempo delta que sugiriera que el estereotipo debe eliminarse del modelo UML.
5. El perfil C# no define ninguna restricción actualmente, de modo que no se detectan las combinaciones no válidas de los estereotipos aplicados. Evite el uso de estereotipos de perfil no válidos. Por ejemplo, la aplicación tanto de <<CSharpClass>> como de <<CSharpInterface>> no es válida, y el resultado será un comportamiento imprevisible de la transformación.
6. Durante el modelado de tipos parciales, el usuario debería utilizar un tipo vacío como tipo parcial en el que cada componente se muestra como independiente. Incluya el tipo parcial vacío modelado (la fuente) y los tipos parciales definidos (con relaciones de dependencia con la fuente) en un solo paquete en el modelo. De esta manera, todos los componentes del tipo parcial se definen en un paquete en el modelo. El nombre de origen se utilizará como nombre de tipo y no se utilizará otro nombre de componente como nombre de tipo. Utilizando un modelo de correlación, se puede dirigir cada componente parcial a un archivo diferente. Durante la transformación de código a modelo, no se conocen los nombres utilizados por el usuario para cada uno de los componentes y, por lo tanto, la transformación genera nombres como <typename>_<filename>, que aparecerán como diferencia en el diálogo de fusión.
7. En C#, se pueden utilizar tipos genéricos sólo si especificamos los valores para los parámetros de tipo; por ejemplo, deberíamos construir un tipo nuevo para un tipo genérico mediante el enlace de sus parámetros de tipo. De manera que una clase de lista con el parámetro T se puede utilizar mediante el uso de la lista <String> etc. En UML, estos tipos construidos se representarán como enlaces de plantilla y los nombres de estos tipos no estarán durante la transformación de código a UML para generar el modelo temporal. De manera que los tipos construidos aparecen como nombres de tipo anónimo que se mostrarán como diferencias en el diálogo de fusión y el usuario tendrá que correlacionarlas a la plantilla real enlazándolas en el modelo de destino.
Los operadores sobrecargados se modelan como operaciones. Por ejemplo, suponga que espera sobrecargar los dos operadores siguientes en el contexto de la clase C1 y desea modelar esta tarea con Modeling Extension para Microsoft .NET.
Igual (==)
No igual (!=)Los pasos siguientes describen cómo se puede modelar la sobrecarga de operadores usando este ejemplo.
Requisitos previos:
Se debe haber creado o abierto un modelo UML.Para modelar los operadores sobrecargados:
- Cree una clase nueva en el modelo UML llamada C1.
- Agregue una operación nueva a la clase C1 y llámela operador !=. Este operador contendrá la implementación para el operador sobrecargado !=.
- Defina el operador de la siguiente manera.
a. Establezca la visibilidad de la operación recién creada en Público.
b. Establezca los calificadores de la operación recién creada en Estático.
c. Establezca el tipo de retorno de la operación recién creada en <Tipo primitivo>.
d. Agregue dos parámetros del tipo C1 a la operación recién creada y llámelos c1 y c2.- Agregue otra operación a la clase C1 y llámelo operador ==. Este operador contendrá la implementación para el operador sobrecargado ==.
- Defina el operador como en el paso 3.
El modelado del operador sobrecargado != y == en el contexto de la clase C1 ha finalizado.
Estas notas del release incluyen información específica de release como, por ejemplo, problemas y limitaciones que no estaba disponibles hasta después de finalizar la documentación del producto.
El usuario no recibe notificaciones del software de ampliación de modelado sobre la compilación incorrecta del código importado. Si el proyecto en C# importado contiene código con errores de sintaxis, el distintivo que indica errores en el software de ampliación de modelado no se mostrará en el Explorador de proyectos o en los diagramas del visualizador.
Método alternativo: Asegúrese de que el código en C# se compila satisfactoriamente en Visual Studio .NET antes de realizar una transformación y antes de importarla a Modeling Extension for Microsoft .NET.
- Modeling Extension for Microsoft .NET sólo reorganiza y se comunica con la primera instancia de Visual Studio 2005 que se abre. Ejecute sólo una instancia de Visual Studio a la vez en una máquina en la que se esté usando Modeling Extension for Microsoft .NET.
- Nunca cierre o abra una solución diferente (distinta a la que se ha importado) dentro de Visual Studio cuando se esté ejecutando Modeling Extension for Microsoft .NET.
- Mantenga siempre abierta una instancia de Visual Studio 2005; Modeling Extension para Microsoft .NET sólo reconocerá y se comunicará con la primera instancia de Visual Studio 2005.
- Si se importa una solución a Modeling Extension para Microsoft .NET, en el espacio de trabajo de Eclipse se crean proyectos de Eclipse para cada proyecto en C# correspondiente que esté presente en la solución. El proyecto creado en Eclipse tendrá el mismo nombre que el proyecto en C# de la solución de Visual Studio 2005. A continuación se comentan puntos importantes a tener en cuenta sobre los proyectos:
- Los proyectos creados en Eclipse tendrán enlaces a los archivos en C#, y los conjuntos de .NET utilizados en los proyectos en C# correspondientes de la solución Visual Studio 2005. Estos enlaces serán la única manera de Modeling Extension para Microsoft .NET de recuperar, actualizar y mostrar información sobre proyectos de Visual Studio 2005 y sus contenidos en Eclipse. De hecho, actúan como vista para los proyectos en C# de Eclipse.
- A excepción del uso de transformaciones de UML a C#, evite utilizar mecanismos Eclipse para modificar los proyectos importados. El uso de mecanismos Eclipse para renombrar estos proyectos o modificar su contenido puede llevar a obtener resultados imprevisibles. Concretamente, evite crear o añadir modelos UML (.emx) o archivos de diagramas (.dnx) a los proyectos. En lugar de eso, cree proyectos separados (como Proyecto UML) en Eclipse con este fin. Debe procurar evitar la creación de archivos de diagrama (.dnx) dentro de los proyectos importados, porque a medida que se creen diagramas nuevos, la infraestructura de visualización tomará de forma predeterminada como ubicaciones los proyectos en los que se encuentran los elementos visualizados.
- Puede cerrar y volver a abrir los proyectos importados con toda seguridad. Asimismo, puede suprimirlos con seguridad, pero no “elimine el contenido subyacente” (si realmente necesita suprimir un proyecto de Visual Studio y todo su contenido, hágalo desde Visual Studio).
- Una vez que la solución de Visual Studio 2005 se haya importado en Eclipse, evite renombrar proyectos en C# en Visual Studio 2005. Si debe renombrar un proyecto , siga los pasos siguientes:
- Suprima el proyecto Eclipse (importado) correspondiente (pero no “elimine el contenido subyacente”).
- Renombre el proyecto en Visual Studio.
- Vuelva a importar la solución de Visual Studio (la solución Modeling Extension for Microsoft .NET puede importar la solución de forma incremental; esta función también es útil para importar proyectos en C# añadidos recientemente a la solución Visual Studio 2005).
- Antes de realizar acciones en Modeling Extension for Microsoft .NET, asegúrese de que los proyectos en C# no contienen errores de sintaxis y que compilan satisfactoriamente en Visual Studio 2005. Modeling Extension for Microsoft .NET utiliza Visual Studio Code Model APIs para analizar los archivos en C#. Estas API devuelven resultados incorrectos y valores NULL si hay errores en los archivos en C#. Por ejemplo, si cambia un archivo en C# en Visual Studio, renueva el proyecto en Eclipse y ve que el archivo no se puede ampliar en Project Explorer, es posible que sea porque el cambio haya introducido los errores de sintaxis en C#.
La solución recomendada es cambiar a Visual Studio 2005, arreglar todos los errores de sintaxis, volver a compilar la solución y renovar el proyecto importado en Eclipse para obtener los cambios. Es especialmente importante que las soluciones de Visual Studio estén compiladas y limpias cuando se apliquen las transformaciones.- Modeling Extension for Microsoft .NET utiliza un mecanismo COM para sincronizarse con Visual Studio 2005. Es posible que las llamadas COM fallen o que se rechacen cuando Visual Studio esté ocupado. No trabaje en Visual Studio 2005 ni lo active cuando realice las operaciones siguientes en Modeling Extension for Microsoft .NET:
- Importar soluciones .NET
- Renovar el proyecto
- Ampliar los archivos o proyectos importados en Project Explorer (por ejemplo, ampliando la vista de árbol)
- Iniciar Modeling Extension for Microsoft .NET en un espacio de trabajo en el que la solución Visual Studio 2005 se haya importado previamente
- Componer un diagrama de visualización .NET
- Ejecutar una transformación de UML a C# o de C# a UML
- Si no piensa explorar el contenido de los tipos definidos en los conjuntos de infraestructuras .NET (por ejemplo, para buscar las operaciones o campos que contiene el tipo), utilice la opción "Obtener sólo tipos durante el análisis de conjuntos .Net" mientras importa la solución Visual Studio 2005 al espacio de trabajo de Eclipse. Esta opción está disponible en la primera página del asistente de importación de soluciones .NET. Esto acelera la importación de la solución y también la visualización de los tipos en C# y .NET.
- En Visual Studio 2005, habilite siempre la opción para cargar automáticamente los cambios. Al seleccionar el recuadro “Cargar cambios automáticamente" que está disponible en Entorno-> Página de documentos de la ventana Opciones, se habilita esta opción. Se puede abrir a través de “Herramientas-Opciones->Entorno->Documentos->Detectar si un archivo ha cambiado fuera del entorno ->Cargar cambios automáticamente, si se han guardado”.
- Puede cambiar la codificación de los proyectos en C# a través de Eclipse seleccionando la opción Propiedades del menú contextual de los proyectos importados. Tenga en cuenta que esta codificación necesitará más tiempo de lo normal ya que los proyectos de Visual Studio habitualmente son grandes.
Cuando se utiliza una interfaz, una clase o una estructura para definir el tipo de un elemento en una interfaz, clase o estructura externa, el nombre de tipo incluye el nombre de los tipos externos, si bien el tipo y el elemento están definidos en la misma clase. No se conoce ningún método alternativo actualmente. Problema que se abordará en una versión futura.
Por ejemplo, el modelo siguiente:
- OuterClass
+ InnerClass
+ attribute1 : InnerClassProporcionará los datos siguientes como parte del código generado para InnerClass, dentro de OuterClass.cs:
private OuterClass.InnerClass attribute1;
No se da soporte a la transformación directa de los caracteres Unicode presentes en un modelo UML, como los nombres de clase, documentación, etc. en este release. Todos los caracteres Unicode se generarán como '?' en los archivos en C# correspondientes.
Cuando Modeling Extension for Microsoft .NET está instalado con IBM Rational Software Modeler, la visita guiada viewlet que muestra las características de Modeling Extension for Microsoft .NET no está disponible en la sección Bienvenida al hacer clic en Visión general> Diferentes métodos de modelado... > Más información acerca de las transformaciones de modelos. La visita guiada está disponible en la galería de guías de aprendizaje.
Para ver la visita guiada en Rational Software Modeler, pulse Ayuda > Guías de aprendizaje, amplíe Visitas guiadasy, a continuación, pulse Transformar modelos UML al código C#. Pulse Iniciar visita guiada para iniciar el viewlet.
En algunos casos, cuando se vuelve a ejecutar una transformación de UML a C# con las opciones de correlación y crear relaciones de origen a destino, el código generado se corrompe. Por ejemplo, es posible que falte el símbolo "/" en los comentarios de código y que haya otros errores de código.
Esto sucede cuando la relación de manifiestos se mueve entre artefactos de manera que su uso puede combinar código en un archivo .cs o separar el código en dos archivos.
Este problema estará resuelto en un futuro release.
La primera vez que se ejecuta una transformación de C# a UML en un modelo de código importado de XDE, el recuadro de diálogo de reconciliación muestra muchas diferencias relacionadas con los estereotipos. Esto se debe a que la transformación de C# a UML no reconoce los estereotipos relacionados de XDE en el modelo importado. Este problema estará resuelto en un futuro release.
Método alternativo:
Realice una única transformación de "limpieza" inmediatamente después de haber importado el modelo de código de XDE (antes de realizar cambios en el modelo o código). Ejecute la transformación de C# a UML. Cuando aparezca el diálogo de reconciliación, acepte todos los cambios sugeridos para el modelo provisional (el modelo que se muestra en el panel de la izquierda). Los estereotipos se eliminarán del modelo persistente, de manera que las ejecuciones posteriores de la transformación de C# a UML dejarán de informar sobre las diferencias.
Piense en un modelo que contiene propiedades UML estereotipadas como <<CSharpProperty>>, <<CSharpField>>, etc., cuyo tipo no está establecido y el código fuente especifica tipos de los conjuntos como tipos de datos para estos elementos. Si la transformación de C# a UML se ejecuta en un modelo de destino y código de este tipo, la fusión mostrará correctamente el tipo de datos (cuál será una referencia de visualización de UML) que se establecerá para el elemento, pero después de que la operación finalice, el tipo de datos no aparecerá para esos elementos (valor nulo). Este problema es conocido y estará resuelto en un futuro release.
Si el nombre de un archivo modelo contiene el símbolo #, y está especificado como el destino de una transformación de C# a UML, el recuadro de diálogo de fusión no podrá mostrar los dos paneles con el modelo provisional y de destino para fusionar las diferencias. Este problema estará resuelto en un futuro release.
Si un modelo importado de XDE se especifica como destino de una transformación de C# a UML y un modelo de correlación también se especifica en la configuración de transformaciones, la transformación de C# a UML fallará con una Excepción de puntero nulo. Este problema sólo aparece en el caso de los modelos importados de XDE con un modelo de correlación.
Método alternativo:
Suprima el paquete <<Artefactos>> del modelo importado y, a continuación, ejecute la transformación. Al suprimir el paquete de artefactos no se pierde información, puesto que el modelo de correlación tiene información sobre varios archivos, etc. El problema estará resuelto en un futuro release.
Si un modelo de destino se crea con el botón Crear contenedor nuevo del editor de configuración de transformaciones, la atención se desvía a veces al modelo creado recientemente y el modelo nuevo no se selecciona en el panel de destino (donde la transformación de C# a UML es la transformación directa).
Método alternativo:
Cambie manualmente al editor de configuración y seleccione el modelo de destino. Este problema es conocido y estará resuelto en un futuro release.
Si una transformación de UML a C# se ejecuta con un modelo de correlación modificado de forma que lleve a la supresión de un archivo, y si el usuario selecciona suprimir el archivo en el recuadro de diálogo Supresión de archivos, ese archivo no se suprimirá realmente. Simplemente se eliminará del proyecto para conservar el contenido.
Posteriormente, si la transformación de UML a C# se ejecuta de nuevo, de forma que se vuelva a crear el archivo que se había suprimido (eliminado del proyecto) en el paso anterior, este archivo (creado de nuevo) tendrá el contenido antiguo (original) en lugar del contenido nuevo.
Método alternativo:
El método alternativo actual para este problema es suprimir este tipo de archivos del sistema de archivos después del paso 1. La lista de estos archivos se puede obtener de:
- el recuadro de diálogo Supresión de archivos, si la transformación no se ejecuta en silencio.
- la lista de archivos disponibles en el sistema de archivos en comparación con los archivos que pertenecen al proyecto si la transformación está configurada para ejecutarse en silencio.
- la lista de artefactos vacíos en el modelo de correlación (si hay alguno).
La repetición de la transformación de UML a C#, con la opción Crear relaciones de origen a destino seleccionada en la página Común de la configuración de transformaciones después de eliminar la etiqueta @generated del código en C#, lleva a la generación de una etiqueta URI adicional en el código. Esto se ha observado sólo con variables.
La etiqueta de URI tiene el formato siguiente:
//@C#_transform [
// _URI=platform:/resource/UML%20project/Blank%20Model%20t1.emx#_cd19cKJhEdurjYIa4vhLGA//]
La ejecución reiterada de la aplicación lleva a la generación de más etiquetas URI en el archivo en C#.
Método alternativo:
No hay ningún método alternativo conocido para este problema.
Si la etiqueta @generated para un método setter generado se elimina, y el tipo se modifica en el código antes de volver a ejecutar la transformación de UML a C#, se genera un método setter adicional.
El método alternativo es realizar la modificación del tipo en el modelo.
Cuando la transformación de UML a C# se ejecuta con la opción Sustituir elementos de UML, los literales de enumeración elegidos presentes en el modelo UML no se sustituyen. Si una enumeración E tiene dos literales, L1 y L2, y el paquete P contiene E, después de ejecutar la transformación, la enumeración E se sustituye correctamente por un atajo a la enumeración en C# generada en el código; pero los literales L1 y L2 aparecen en el paquete P después de la transformación.
Método alternativo:
No hay ningún método alternativo conocido para este problema.
El importador de modelos de código C# de XDE (Archivo -> Importar -> Otra -> Solución .Net de XDE) no migra los métodos setters de los indexadores en C# correctamente en algunos casos. Es posible que la importación de un proyecto en C# dentro de una solución .NET de XDE mediante la especificación del modelo UML correspondiente (archivo .emx; importado mediante el uso del importador de modelos base de XDE), y la posterior ejecución de la transformación de UML a C# con el modelo migrado como origen y el proyecto migrado como destino no den como resultado los mismos métodos setter que existían en el código antes de llevarse a cabo el proceso. En algunos casos, el método setter no se genera, y en otros casos, el método setter se genera con un parámetro adicional (con valor de nombre) que provoca un error de compilación, porque C# no permite utilizar el valor de nombre para un parámetro explícito del método setter.
Método alternativo:
No hay ningún método alternativo conocido para este problema.
Cuando una transformación de UML a C# se ejecuta con la opción Sustituir elementos de UML en la página Común del editor de configuración de transformaciones y se utiliza un modelo de correlación, la transformación no sustituye los elementos de UML en el modelo de origen para el que se generan los archivos de origen en las carpetas. Sólo los elementos de UML para los que se ha generado el código debajo de la carpeta root del proyecto de destino en C# se sustituyen por atajos a los elementos correspondientes en el código.
Método alternativo:
Después de ejecutar la transformación de UML a C#, por primera vez, el modelo de UML y el modelo de correlación se marcarán como incorrectos; ejecute la transformación una vez más sin realizar ningún cambio en la configuración de las transformaciones o en el modelo de correlación. Ahora, todos los elementos de UML del modelo se sustituirán por atajos.
Cuando los modelos de código Rational XDE se importan, cualquier modelo denominado "modelo de conjunto" (también conocido como "modelo de sistema" o "modelo de referencia") al que hagan referencia los modelos de código también se importará y se hará referencia a él dentro del entorno basado en Eclipse. Como consecuencia, el hecho de abrir el modelo de código importado puede tardar mucho tiempo.
Método alternativo:
Suprimir los modelos de conjunto importados cuando los modelos de código se hayan importado satisfactoriamente. Este método alternativo se puede utilizar si elige sustituir los elementos UML del modelo de código importado por referencias de código directo y utilizar la teoría de "modelado combinado" de operaciones o, por el contrario, elige conservar los elementos UML del modelo de código y utilizar la teoría de la “verdadera ingeniería directa e inversa (RTE)” de operaciones (transformación iterativa directa e inversa y reconciliación).Efectos del método alternativo:
1. La supresión de los modelos de conjunto agilizará mucho más la apertura y edición de los modelos de código importados.2. Es posible que el producto muestre avisos o “errores” acerca de modelos de referencia que “no aparecen” cuando se abre el modelo de código importado. Estos avisos se pueden ignorar.
3. Es posible que el producto muestre avisos o “errores” acerca de modelos de referencia que "no aparecen" cuando se ejecuta la validación en comparación con el modelo de código importado. Estos avisos o errores se pueden ignorar.
Ejemplo:
Imaginemos que tenemos un proyecto en C# de Visual Studio 2003 llamado Project1 con su correspondiente modelo base de XDE "Project1.mdx". Demos por sentado que este modelo hace referencia a los cinco modelos de sistema siguientes: System.mdx, mscorlib.mdx, System.Data.mdx, System.Web.mdx y System.Drawing.mdx.- Empiece por migrar el proyecto de VS 2003 a VS 2005 utilizando el programa de utilidad de migración de VS 2005
Importe el modelo de proyecto Project1.mdx utilizando la opción de importación de modelos de XDE (Archivo > Importar > Otros > Modelo de Rational XDE). Elija la importación de todos los modelos de referencia asociados (el importador necesita que se garantice la integridad de los modelos durante el proceso de importación).- El resultado es la creación de seis archivos .emx en el espacio de trabajo de Eclipse: “Project1.emx,” “System.emx mscorlib.emx,” “System.Data.emx,” “System.Web.emx” y “System.Drawing.emx.”
- A continuación, importe la solución Visual Studio 2005 (Archivo > Importar > Otra > Solución .NET). El modelo .mdx existente se detectará en esa solución y se le solicitará el nombre de los modelos de código importados, en este caso, “Project1.emx.” En ese momento, también se le ofrecerá la opción de sustituir los elementos de UML de Project1.emx por referencias al código en la solución importada. Utilice esa opción si desea practicar el “modelado mixto,” pero no’ lo utilice si desea practicar la “verdadera RTE”.
- El proceso de importación se habrá completado. La siguiente vez que abra el modelo “Project1.emx” la infraestructura de UML intentará cargar los cinco modelos de referencia y resolver las referencias de elementos en "Project1.emx" a elementos de dichos modelos de referencia. Éste es el motivo del retardo al abrir el modelo importado de XDE y trabajar con él.
- Para eliminar la penalización de rendimiento, sólo tiene que seleccionar y suprimir cada uno de los cinco modelos de conjunto importados. Tal como se ha indicado anteriormente, esta acción mejorará el rendimiento y aparecerán avisos o “errores” al abrir y validar “Project1.emx”, pero no repercutirán en ninguna de las operaciones de modelado y transformación que pueda desear llevar a cabo con “Project1.emx”.
Si una transformación de C# a UML se ejecuta en modalidad silenciosa y el resto de las opciones se selecciona en el editor de la configuración de transformaciones, la transformación fallará. Esto sucede, concretamente, cuando los nuevos cambios en el modelo de destino contienen elementos estereotipados (por ejemplo, <<CSharpStruct>>) que se van a fusionar en modalidad silenciosa. Este problema estará resuelto en un futuro release.
Si una transformación de C# a UML se ejecuta en un archivo de origen que contiene operadores sobrecargados como != o == para introducir estos operadores en el modelo de destino, el recuadro de diálogo de fusión no debería mostrar ningún cambio en la siguiente ejecución de la transformación sin cambios en el código. Sin embargo, el diálogo de fusión muestra cambios relacionados con el renombramiento de los parámetros incorrectamente.
Este problema estará resuelto en un futuro release.
En el caso de las transformaciones de C#, se debería utilizar un modelo de correlación para especificar la jerarquía que sigue el sistema de archivos para organizar el código. Todavía no se da soporte al renombramiento de clases, interfaces, etc. a través del modelo de correlación. El diseño de una aplicación en C# se puede realizar desde dos perspectivas:
1. Diseño de sistemas lógico
2 Diseño de sistemas físico (se especificará como modelo de correlación)
El modelo de diseño lógico contendrá normalmente los distintos espacios de nombres, los distintos tipos y la relación, atributos, funciones, etc. de herencia.
La perspectiva de diseño físico utilizando un modelo de correlación incluye la información de despliegue para la transformación de C#. Esto significa que puede controlar la forma en la que desea que la transformación coloque las diferentes construcciones lógicas en distintos archivos. De forma predeterminada, sin un modelo de correlación, la transformación de UML a C# generará cada tipo, por ejemplo, una clase o una interfaz, en un archivo cuyo nombre sea el mismo que el nombre del tipo pero colocado en la carpeta raíz del proyecto de Visual Studio. Por ejemplo, la clase "MyClass" se generará en un archivo llamado "MyClass.cs" en ausencia de un modelo de correlación. No obstante, si el usuario desea que el código se genere en un archivo denominado "Test.cs", debería especificarlo en el modelo de correlación mediante un artefacto que manifieste esa clase como "MyClass".
El modelo de correlación se utiliza sólo para especificar la carpeta o la jerarquía de archivos para generar código. Es posible que no se realice el renombramiento si se utiliza el modelo de correlación.
Tenga en cuenta que tanto el diseño lógico (modelo de origen de la transformación), como el diseño físico (modelo de correlación de la transformación) son sólo modelos UML. La única diferencia es que:
- Los paquetes UML en el modelo de origen lógico representan los espacios de nombre en C#.
- Los paquetes UML en el modelo de correlación representan las carpetas en el sistema de archivos.
Si la transformación de UML a C# se deshace después de haber ejecutado la transformación con una opción de Modelo de correlación habilitada y con la opción Sustituir elementos de UML seleccionada, el estado del modelo de correlación no será el correcto. Si la transformación de UML a C# se ejecuta de nuevo con el modelo de correlación incorrecto, los archivos en C# se generarán en una ubicación incorrecta.
Método alternativo:
El usuario tiene que deshacer manualmente los cambios en el modelo de correlación antes de ejecutar de nuevo la transformación de UML a C#. Esta acción se puede realizar cerrando el modelo de correlación sin guardar los cambios.
El soporte del software IBM Rational le proporciona asistencia técnica.
Para ver la información de contacto, las directrices o el material de consulta que necesitará cuando requiera soporte, lea la publicación IBM Software Support Handbook.
Para consultar las preguntas más frecuentes (FAQ), las listas de problemas conocidos y sus arreglos, así como otra información de soporte, visite el sitio web de soporte del software IBM Rational.
Para ver noticias y sucesos relacionados con el software Rational, y otra información, visite el sitio web del software IBM Rational.
Antes de ponerse en contacto con el soporte del software IBM Rational, recopile la información básica que necesitará para describir el problema. Cuando describa un problema a un especialista de soporte de software de IBM, sea lo más específico posible e incluya toda la información importante del problema, de forma que el especialista pueda ayudarle a solucionar eficazmente el problema. Para ahorrar tiempo, tenga a mano las respuestas a estas preguntas:
- ¿Qué versiones de software estaba ejecutando cuando se produjo el problema?
- ¿Tiene registros, rastreos o mensajes relacionados con el problema?
- ¿Puede reproducir el problema? Si es así, ¿qué pasos realiza para reproducirlo?
- ¿Existe alguna solución provisional del problema? Si es así, esté preparado para describir la solución provisional.
© Copyright IBM Corporation 2007. Reservados todos los derechos.
Esta información se ha desarrollado para productos y servicios ofrecidos en Estados Unidos. IBM puede no ofrecer los productos, servicios o características tratados en esta documentación en otros países. Consulte con el representante local de IBM para obtener información acerca de los productos y servicios que actualmente están disponibles en su localidad. Las referencias hechas a productos, programas o servicios IBM no pretenden afirmar ni dar a entender que únicamente puedan utilizarse dichos productos, programas o servicios IBM. Puede utilizarse en su lugar cualquier otro producto, programa o servicio funcionalmente equivalente que no vulnere ninguno de los derechos de propiedad intelectual de IBM. No obstante, es responsabilidad del usuario evaluar y verificar el funcionamiento de cualquier producto, programa o servicio que no sea de IBM.
IBM puede tener patentes o solicitudes de patente pendientes de aprobación que cubran alguno de los temas tratados en esta documentación. La entrega de esta documentación no le otorga ninguna licencia sobre dichas patentes. Puede enviar las consultas sobre licencias, por escrito, a la siguiente dirección:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
Estados Unidos
Para consultas sobre licencias relativas a la información de doble byte (DBCS), póngase en contacto con el departamento de propiedad intelectual de IBM en su país o envíe las consultas, por escrito, a:IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokio 106, JapónEl párrafo siguiente no se aplica en el Reino Unido ni en ningún otro país en el que tales disposiciones sean incompatibles con la legislación local: INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA ESTA PUBLICACIÓN "TAL CUAL" SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPLÍCITA O IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS O CONDICIONES IMPLÍCITAS DE NO VULNERACIÓN, DE COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO. Algunas legislaciones no contemplan la declaración de limitación de responsabilidad, ni implícitas ni explícitas, en determinadas transacciones, por lo que cabe la posibilidad de que esta declaración no se aplique en su caso.
Esta información puede contener imprecisiones técnicas o errores tipográficos. Periódicamente, se efectúan cambios en la información incluida en este documento; estos cambios se incorporarán en nuevas ediciones de la publicación. IBM puede efectuar mejoras o cambios en los productos o programas descritos en esta publicación en cualquier momento y sin previo aviso.
Los licenciatarios de este programa que deseen obtener información acerca del mismo con el fin de: (i) intercambiar la información entre los programas creados independientemente y otros programas (incluido éste) y (ii) utilizar mutuamente la información que se ha intercambiado, deben ponerse en contacto con:
Intellectual Property Dept. for Rational Software
IBM Corporation
20 Maguire Road
Lexington, MA
02421-3112
EE.UU.Tal información puede estar disponible, sujeta a los términos y a las condiciones adecuadas, incluyendo en algunos casos el pago de una cuota.
IBM proporciona el programa bajo licencia descrito en esta documentación, así como todo el material bajo licencia disponible, según los términos del Acuerdo de Cliente de IBM, del Acuerdo Internacional de Programas bajo Licencia de IBM o de cualquier otro acuerdo equivalente entre ambas partes.
La información concerniente a productos no IBM se ha obtenido de los suministradores de dichos productos, de sus anuncios publicados o de otras fuentes de información pública disponibles. IBM no ha comprobado dichos productos y no puede afirmar la exactitud en cuanto a rendimiento, compatibilidad u otras características relativas a productos no IBM. Las consultas acerca de las posibilidades de los productos no IBM deben dirigirse a los suministradores de los mismos.
Todas las declaraciones relativas a la dirección o a la intención futura de IBM están sujetas a cambios o anulación sin previo aviso y representan únicamente metas y objetivos.
Marcas registradas y marcas de servicio
Los términos siguientes son marcas registradas de International Business Machines Corporation en Estados Unidos o en otros países:
- developerWorks
- IBM
- Rational
Java y todas las marcas basadas en Java son marcas registradas de Sun Microsystems, Inc. en los Estados Unidos de América y/o en otros países.
Microsoft, Windows y Windows NT son marcas registradas de Microsoft Corporation en Estados Unidos o en otros países.
Intel y Pentium son marcas comerciales o marcas registradas de Intel Corporation o de sus subsidiarias en Estados Unidos o en otros países.
UNIX es una marca registrada de The Open Group en Estados Unidos y en otros países.
Linux es una marca registrada de Linus Torvalds en Estados Unidos o en otros países.
Los nombres de otras empresas, productos o servicios pueden ser marcas registradas o de servicio de terceros.