Directriz: Estructuración de un modelo de implementación para aplicaciones J2EE
Esta directriz trata cómo estructurar el modelo de implementación para una aplicación J2EE.
Relaciones
Descripción principal

Introducción

En esta sección se presupone que el lector está familiarizado con la información general sobre J2EE como una plataforma de tecnología, tal como se trata en la sección Concepto: visión general de Java 2 Platform Enterprise Edition (J2EE) y Concepto: correlación del diseño al código. Algunos de los conceptos en estas directrices son propios de UML 1.4, mientras que es posible que lo esté utilizando en el contexto de un plug-in basado en UML 1.3. En el caso que se presenten dificultades en comprender algún aspecto, compruebe qué indican las dos especificaciones UML sobre dicho aspecto.

Estructuración del modelo de implementación

La sección Tarea: estructuración del modelo de implementación describe la forma en que crear una estructura del modelo de implementación que esté en gran medida alineada con la estructura en el modelo de diseño y que, a la vez, refleje todas las restricciones del entorno de desarrollo y que dé soporte al desarrollo paralelo y la integración incremental.

La estructura del modelo de implementación para una aplicación J2EE depende del entorno de implementación y desarrollo, sin embargo, en general, hay cuatro estructuras potenciales dentro de un modelo de implementación de J2EE:

  • Soporte de despliegue (módulos J2EE y descriptores de despliegue).
  • Estructura de directorios virtuales (páginas HTML, JSP).
  • Directorio Java para elementos desplegados en un servidor web (servlets, JavaBeans).
  • Directorio Java para elementos desplegados en un servidor de aplicaciones EJB.

Modelado de subsistemas de implementación

La vista de implementación en el Producto de trabajo: documento de arquitectura de software proporciona una visión general a alto nivel del modelo de implementación. Esto incluye la identificación de subsistemas de implementación. En una aplicación J2EE, podría ocurrir que los subsistemas de implementación no se correlacionasen con un único directorio en el sistema de archivos o en un único paquete en el modelo, puesto que el subsistema de implementación podría incluir elementos no Java de un modelo (como páginas HTML y JSP) y elementos Java de otro. Una estrategia ante esta situación es tener una estructura de empaquetado paralela en cada modelo. Los paquetes con el mismo nombre en cada modelo se asocian de forma implícita.

Es habitual que un subsistema de implementación proporcione la implementación para un único archivo de implementación desplegable (un archivo EAR, JAR o WAR). En este caso, la identificación de archivos que se despliegan podría servir para identificar los subsistemas de implementación.

Dentro de cada subsistema de implementación podría haber una representación de elementos físicos, formados por los directorios de implementación y los archivos de implementación. También podría haber elementos lógicos, formados por clases, componentes, paquetes, etc., que corresponderían a los elementos del Producto de trabajo: modelo de diseño, pero son un modelo preciso del código fuente (un modelo de ingeniería de doble sentido). Consulte la sección Concepto: correlación de diseño a código para obtener más información sobre las relaciones entre el modelo de diseño y el modelo de implementación.

Los modelos de ingeniería de doble sentido proporcionan una representación precisa del código fuente. In J2EE, cada paquete en un modelo Java representa un paquete Java, cada clase representa una clase Java, y así sucesivamente. Sin embargo, a menudo hay la necesidad de complementar los modelos de ingeniería de doble sentido con información adicional, tal como:

  • Diagramas en los que se muestra información que no se crea de forma automática como parte de la ingeniería de doble sentido.
  • Abstracciones de nivel superior del modelo.

El modelo de diseño es una abstracción que se realiza a partir de las clases, los componentes, los paquetes y así sucesivamente. Sin embargo, también podría haber la necesidad de abstracciones de nivel superior o diagramas adicionales para los elementos físicos (archivos y directorios). Dichos elementos se describen en las secciones posteriores.

Modelado de directorios de implementación

Generalmente la ingeniería de doble sentido sólo maneja un subconjunto de los directorios necesarios en el entorno de desarrollo. A menudo se necesitan directorios adicionales para organizar artefactos de prueba, unidades de despliegue, documentación, etc. Generalmente no es preciso modelar, puesto que los directorios se pueden visualizar como parte del sistema de archivos.

Modelado de archivos de implementación

Los archivos de implementación en general no se modelan a no ser que se proporcione el soporte de alguna herramienta de ingeniería de doble sentido o que se necesiten mostrar algunas relaciones no tan obvias.

Normalmente hay un archivo .java por cada clase o interfaz Java, y un archivo .class compilado por cada archivo .java. Por lo tanto, modelar estos archivos no es muy interesante.

En J2EE, un subsistema contiene normalmente uno o más archivos de archivado (archivos JAR, WAR o EAR).

La forma más correcta de modelar archivos de archivado es mediante una relación de composición desde el archivo de archivado a los archivos que contiene. Sin embargo, cuando los archivos .class compilados se combinan para formar un archivo JAR podría ser más útil mostrar una dependencia desde el archivo JAR a las clases e interfaces que implementa en última instancia.

Si el subsistema de implementación sólo crea un archivo JAR, quizás no será necesario modelar más; especialmente si todos los archivos que se pueden desplegar en el subsistema de implementación se presupone que son parte del archivo JAR.

Solapamiento de archivos de archivado

Es posible, pero en general poco recomendable, el definir dos archivos de archivado que contengan algunos de los elementos comunes. Por ejemplo, dos archivos EAR podrían contener algunos, pero no todos, JAR de EJB iguales; o dos JAR de EJB podrían contener los mismos EJB, pero distintos descriptores de despliegue.

Es mejor que los archivos de archivado no se solapen para mantener una correspondencia cercana entre los subsistemas de implementación y los archivos de archivado desplegables. Sin embargo, si el solapamiento es necesario, podría ser útil el modelarlos junto a las causas para dichos solapamientos.