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:
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:
-
Cree un nuevo proyecto Java y añada referencias a las bibliotecas.
-
Abra el diagrama al que desea añadir el elemento visualizado.
-
Cambie a la perspectiva Java.
-
Busque el elemento (paquete, clase, interfaz, etc.) al que desea añadir el modelo.
-
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.
A continuación, se muestra una secuencia de los pasos que le ayudarán a ajustar los subsistemas de implementación:
-
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
-
Crear un subsistema nuevo
-
Mover los elementos identificados al nuevo subsistema
-
Dibujar dependencias nuevas
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).
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.
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.
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.
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 Publicación de modelos y el tutorial Publicación de un modelo en un
sitio web .
|