Instrucciones de la herramienta: Estructuración del modelo de implementación mediante Rational Systems Developer
Esta guía de la herramienta describe cómo estructurar el modelo de implementación mediante el entorno de modelado RSD.
Herramienta: Rational Systems Developer
Amplía: Estructuración del modelo de implementación mediante la plataforma de desarrollo de software Rational
Relaciones
Descripción principal

Visión general

En esta guía de la herramienta, se da por supuesto que se ha definido la estructura de nivel superior del modelo de implementación tal como se describe en las Directrices de estructura de modelo para RSx. Los pasos de esta guía de la herramienta permiten perfeccionar esta estructura inicial.

En esta guía de la herramienta se llevan a cabo los pasos siguientes:

Establecer la estructura del modelo de implementación

El enfoque recomendado es el desarrollo controlado por modelos (MDD) (consulte Desarrollo controlado por modelos y Arquitectura controlada por modelos). Si a este enfoque es seguido por el equipo de desarrollo, el modelo de implementación estará controlado en gran medida por la organización del modelo de diseño. A medida que se identifican los subsistemas de implementación, deben modelarse como paquetes o subsistemas en el modelo de diseño. Generalmente, al identificar los paquetes en el modelo de diseño, debe tenerse en cuenta cómo dichos paquetes se correlacionarán con los proyectos específicos de herramienta. Los subsistemas más amplios suelen correlacionarse con sus propios proyectos, mientras que los paquetes más detalladas suelen correlacionarse con las carpetas de origen de los proyectos. Consulte las secciones de las Directrices de estructura de modelo para RSx donde se tratan las estructuras de proyecto y la organización interna de los modelos de implementación y de diseño.

La Vista de implementación puede definirse mediante paquetes de <<perspectiva>>, que contienen diagramas que muestran dependencias entre los subsistemas. En función del tipo de transformación que se aplique al modelo de diseño, las dependencias que defina entre los paquetes/subsistemas podrán llegar a correlacionarse con declaraciones de importación 3GL y declaraciones de dependencia de proyecto en los metadatos del proyecto.

Una vez que se ha generado el código, se pueden crear diagramas UML más detallados, que muestran construcciones de nivel de implementación y sus relaciones, mediante la creación de diagramas de clase directamente en los proyectos. A continuación, dichos diagramas deben rellenarse arrastrando hasta ellos los artefactos de implementación. Consulte los temas de la ayuda en línea relacionados con el editor visual UML para Java.

Si requiere referencias para representar clases, interfaces o paquetes específicos, entre otros, de una biblioteca de código en el modelo de implementación, podrá utilizar las funciones de visualización de código del producto para crear dichas representaciones. Los archivos JAR siguientes contienen archivos que pueden resultarle interesantes a medida que diseñe y desarrolle aplicaciones J2EE:

  • j2ee.jar, jsf-api.jar, soap.jar, soap-sec.jar (todos en el directorio lib)
  • core.jar, xml.jar, security.jar (todos en el directorio java\jre\lib)

Cuando tenga que hacer referencia a un elemento de una de estas bibliotecas en el modelo, lleve a cabo los pasos siguientes:

  1. Cree un nuevo proyecto Java y añada referencias a las bibliotecas.
  2. Abra el diagrama al que desea añadir el elemento visualizado.
  3. Cambie a la perspectiva Java.
  4. Busque el elemento (paquete, clase, interfaz, etc.) al que desea añadir el modelo.
  5. Pulse el botón derecho del ratón sobre el elemento y seleccione Visualizar > Añadir a diagrama actual.

Si resulta necesario representar los proyectos y paquetes reales en los que espera que el código y los archivos relacionados se encuentren, antes de llevar a cabo la generación del código, puede resultar útil utilizar el modelo de visión general de la implementación. Para obtener más información, consulte los temas relacionados con el modelo Implementación en documento técnico Directrices de estructura de modelo para RSx.

Ajustar subsistemas de implementación

A continuación, se muestra una secuencia de los pasos que le ayudarán a ajustar los subsistemas de implementación:

  1. Identificar subsistemas que provocan problemas, por ejemplo, la dependencia cíclica mediante:
    • Diagramas de tema y de exploración
    • Descubrimiento de la arquitectura
    • Revisión de código / Análisis del código estructural
  2. Crear un subsistema nuevo
  3. Mover los elementos identificados al nuevo subsistema
  4. Dibujar dependencias nuevas 

Definir importaciones para cada subsistema de implementación

En un entorno MDD, las dependencias del modelo de implementación se parecerán bastante a las definidas explícita o implícitamente en el modelo de diseño. Los detalles están determinados por las transformaciones de la generación de código aplicadas al modelo de diseño.

Además del modelo de entrada, existen otros artefactos que son necesarios para llevar a cabo una transformación. Un proceso de transformación requiere una definición de transformación y sus reglas de transformación.

Una regla de transformación proporciona una descripción que el proceso de transformación utiliza para convertir un elemento del modelo de origen en cero o más elementos del modelo de destino. Específicamente, correlaciona elementos de un nivel de abstracción con sus copias más detalladas en un nivel inferior de abstracción.

Si utiliza la transformación manual, deberá asegurarse de que proporciona instrucciones suficientes a sus desarrolladores a medida que transforman el modelo de diseño en código. En esencia, deberá proporcionar una definición de transformación que incluya un conjunto de reglas de transformación. Estas instrucciones adicionales pueden tener el formato siguiente:

  • Elementos de perfiles documentados
  • Notas del modelo
  • Información adicional del documento de arquitectura de software
  • Directrices de desarrollo

Si se utiliza un modelo Visión general de implementación, éste será el lugar donde mostrar las dependencias anticipadas entre proyectos y paquetes, las cuales pueden resultar útiles a la hora de identificar los requisitos de creación del sistema (consulte Directrices de estructura de modelo para RSx).

Decidir cómo tratar ejecutables (y otros objetos derivados)

En un entorno MDD, en función del tipo de transformación que se aplique al modelo de diseño, se pueden generar varios tipos de artefactos desplegables. Por ejemplo, a partir de elementos como, por ejemplo, las clases <<control>> y <<entidad>>, se puede generar EJB de sesión y de entidad para un destino J2EE, que incluya el código de las clases de implementación más las interfaces más el contenido de descriptor de despliegue que asigna los EJB a archivos JAR EJB y correlaciona dichos JAR con EAR.

Puede optar por modelar artefactos desplegables en el nivel conceptual, mediante un modelo de despliegue. Si lo hace de este modo, los modelará mediante nodos y artefactos UML. En la actualidad, las transformaciones empaquetadas con la herramienta no optimizan las semántica de dichos diagramas para generar datos de despliegue; en consecuencia, los diagramas serán puramente conceptuales y útiles sólo como documentación.

Opcionalmente, también podría describir los artefactos de implementación reales en dichos diagramas soltándolos en el cuadro y conectándolos (mediante dependencias) a los elementos conceptuales del diagrama.

Decidir cómo tratar activos de prueba

Una consideración clave que influirá en la estructura de los activos de prueba será la decisión que afecte al modo en que se creen los activos de prueba.

Puede optar por utilizar las funciones de prueba del componente automatizado para crear pruebas. Si éste es el caso, entonces se configuran uno o varios proyectos de caso de prueba automáticamente como parte del proceso de creación. Un beneficio clave de la utilización de esta función es que se puede utilizar una generación de código inicial y utilizar los fragmentos del código para controlar la creación de casos de prueba.

Mantenga el depósito del proyecto organizado como un conjunto o jerarquía de directorios. Es recomendable mantener los activos de prueba en directorios de prueba separados que mantengan separados los diferentes tipos de prueba: prueba de unidad, prueba de integración, prueba de sistema, etc.

Actualizar la vista de implementación

Si existe una vista Implementación separada, se debe mantener. La recomendación general presentada en el documento técnico Directrices de estructura de modelo para RSx es la de utilizar los paquetes de <<perspectiva>> que contienen diagramas que muestran las dependencias entre los subsistemas.

Evaluar el modelo de implementación

Asegúrese de que las dependencias del subsistema (y otras dependencias) siguen las recomendaciones a medida que el sistema evolucione. Con este fin, utilice el descubrimiento de arquitectura, la revisión del código en general y el análisis de la estructura en particular para verificar que los modelos siguen las recomendaciones.

Tal como se ha mencionado anteriormente, es recomendable tomarse un tiempo para introducir reglas personalizadas que se puedan utilizar para aplicar las dependencias que haya identificado. Durante la parte manual de la revisión, es aconsejable anotar las reglas que todavía no se hayan desarrollado y añadirlas al conjunto de reglas para la iteración siguiente.

Puede resultar útil publicar los modelos en formato html. Así mismo, tenga en cuenta que dichos diagramas pueden copiarse en Microsoft Word y otros programas.

Para obtener más información, consulte icono de publicaciónPublicación de modelos y el tutorial icono de publicaciónPublicación de un modelo en un sitio web .