Tarea: Estructurar el modelo de implementación
En esta tarea se describe cómo establecer la estructura de los elementos de implementación basándose en las responsabilidades asignadas de los subsistemas de implementación y su contenido.
Disciplinas: Implementación
Relaciones
Pasos
Establecer la estructura del modelo de implementación
Objetivo Establecer la estructura del modelo de implementación.  

Al cambiar del 'espacio de diseño' al 'espacio de implementación', empiece por duplicar la estructura del modelo de diseño en el modelo de implementación.

Los paquetes de diseño tendrán sus correspondientes subsistemas de implementación, que contendrán uno o varios directorios y archivos (Artefacto: Elemento de implementación) que se necesitan para implementar los elementos de diseño correspondientes. La correlación del modelo de diseño al modelo de implementación puede cambiar, ya que cada subsistema de implementación se asigna a una capa específica en la arquitectura.

Cree un diagrama que represente la estructura del modelo de implementación (consulte Directrices: Diagrama de implementación).

Ajustar los subsistemas de implementación
Objetivo Adaptar la estructura del modelo para que refleje las restricciones del lenguaje de implementación o la organización del equipo. 

Decida si se debe modificar la organización de los subsistemas. Para ello, solucione pequeños problemas tácticos relacionados con el entorno de implementación. A continuación, se proporcionan algunos ejemplos de este tipo de problemas tácticos. Tenga en cuenta que si decide cambiar la organización de los subsistemas de implementación, también debe decidir si desea volver atrás y actualizar el modelo de diseño, o si prefiere que el modelo de diseño sea distinto del modelo de implementación.

  • Organización del equipo de desarrollo. La estructura del subsistema debe permitir que varios implementadores o equipos de implementadores continúen en paralelo sin demasiado solapamiento ni perturbaciones. Se recomienda que cada subsistema de implementación sea responsabilidad de un único equipo. Esto significa que puede dividir un subsistema en dos (si es grande) y asignar las dos partes a dos implementadores o dos equipos de implementadores,  en concreto si los dos implementadores (o equipos) tienen ciclos de compilación/release diferentes).
  • Declaraciones de tipos. Durante la implementación, puede darse cuenta de que un subsistema necesita importar productos de trabajo de otro subsistema, porque un tipo esté declarado en ese subsistema. Normalmente, esto ocurre cuando utiliza lenguajes de programación escritos como, por ejemplo, C++, Java y Ada. En este caso, y en general, se recomienda extraer las declaraciones de tipos en un subsistema aparte.

Ejemplo

Supongamos que extrae algunas declaraciones de tipo del Subsistema D en un nuevo subsistema Tipos, para que el Subsistema A sea independiente de los cambios en los productos de trabajo públicos (visibles) en el Subsistema D.

Ilustración de la extracción del subsistema de declaraciones de tipos

Las declaraciones de tipos se extraen del Subsistema D

.

  • Código heredado y sistemas de componentes existentes. Puede que tenga que incorporar código heredado, una biblioteca de componentes reutilizables o productos asequibles. Si no tienen un diseño modelado, se deben añadir subsistemas de implementación.
  • Ajustar dependencias. Supongamos que un subsistema A y un subsistema B tienen dependencias de importación entre ellos. No obstante, desea que B sea menos dependiente de los cambios en el subsistema A. Extraiga los productos de trabajo de A que importa B y coloque un nuevo subsistema de implementación A1 en una capa inferior.

Diagrama de Transferencia de agrupación de artefactos de ejemplo

Los productos de trabajo se extraen del subsistema A y se colocan en un nuevo subsistema A1.

Ahora que los subsistemas de implementación ya no tienen una correlación unívoca con paquetes/subsistemas en el modelo de diseño, puede realizar el cambio correspondiente en el modelo de diseño (si ha decidido mantener el modelo de diseño estrechamente alineado con el modelo de implementación) o realizar un seguimiento de la correlación entre los modelos de implementación y diseño (por ejemplo, mediante dependencias de rastreabilidad o realización). Si se debe realizar este tipo de correlación y cómo hacerlo es una decisión de proceso que se debe especificar en el  Producto de trabajo: Directrices específicas del proyecto.

Definir importaciones para cada subsistema de implementación
Objetivo Definir dependencias entre subsistemas.  

Para cada subsistema, defina qué otros subsistemas importa. Esto se puede hacer para conjuntos completos de subsistemas, lo que permite que todos los subsistemas de una capa importen todos los subsistemas de una capa inferior. Generalmente, las dependencias del modelo de implementación duplicarán aquellas del modelo de diseño, excepto donde se haya ajustado la estructura del modelo de implementación (consulte Ajustar subsistemas de implementación).

Presente la estructura en capas de los subsistemas en diagramas de componentes.

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

Los ejecutables (y otros objetos derivados) son el resultado de aplicar un proceso de compilación a un subsistema (o varios subsistemas) de implementación o una parte del mismo, por lo que lógicamente pertenecen al subsistema de implementación. No obstante, el arquitecto de software, en colaboración con el gestor de configuración, deberá decidir la estructura de elementos de configuración que se va a aplicar al modelo de implementación. 

Para facilitar la selección y la referencia, en concreto para el despliegue, la recomendación por omisión es definir elementos de configuración aparte que contengan los conjuntos de programas ejecutables que se pueden desplegar (qué programas ejecutables se despliegan en qué nodos se describe en el Modelo de despliegue). Por lo tanto, en el caso más simple, para cada subsistema de implementación habrá un elemento de configuración para los programas ejecutables desplegables y un elemento de configuración que contenga el origen, etc., que se utiliza para producirlos.  El subsistema de implementación se puede considerar que está representado por un elemento de configuración compuesto que contiene estos elementos de configuración (y quizás otros como, por ejemplo, activos de prueba).

Desde el punto de vista del modelado, una colección de programas ejecutables producidos por un proceso de compilación se puede representar como un Producto de trabajo: Compilación (que es un paquete) contenido en el subsistema de implementación asociado (que también es un paquete).  

Decidir cómo tratar los activos de prueba
Objetivo Añadir productos de trabajo de prueba al modelo de implementación. 

En general, los productos de trabajo de prueba y los subsistemas de prueba no se tratan de forma muy diferente de otro software desarrollado en Rational Unified Process. No obstante, los productos de trabajo y los subsistemas de prueba normalmente no forman parte del sistema desplegado, y a menudo no se pueden entregar al cliente. Por lo tanto, la recomendación por omisión es alinear los activos de prueba con el destino de prueba (p.ej., elemento de implementación de la prueba de unidad, sistema de implementación de la prueba de integración, sistema de prueba de sistema), pero mantener los activos de prueba en directorios de prueba aparte, por ejemplo, si el depósito del proyecto está organizado como un conjunto o jerarquía de directorios. Los distintos subsistemas de prueba (indicados para pruebas por encima del nivel de prueba de unidad) se deben tratar de la misma forma que otros subsistemas de implementación: como elementos de configuración diferentes.

Para el modelado, una colección de productos de trabajo de prueba se puede representar como un Producto de trabajo: Subsistema de implementación (un paquete). Para la prueba de unidad, este tipo de subsistema de prueba estará contenido normalmente en el subsistema de implementación asociado (probado). El arquitecto de software, en colaboración con el gestor de configuración, debe decidir si los productos de trabajo de prueba de este nivel se deben configurar conjuntamente con los elementos de implementación que prueban, o como elementos de configuración aparte. Para la prueba de sistema e integración, los subsistemas de prueba pueden ser iguales de los subsistemas de implementación que se están probando.

Actualizar la vista de implementación
Objetivo Actualizar la vista de implementación del documento de arquitectura de software. 

La vista de implementación se describe en el Documento de arquitectura de software. Este apartado contiene diagramas de componentes que muestran las capas y la asignación de subsistemas de implementación a las capas, así como las dependencias de importación entre los subsistemas.

Evaluar el modelo de implementación
Más información