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.
|