Tarea: Incorporar elementos de diseño existentes
En esta tarea se describe cómo evolucionar y perfeccionar el modelo de diseño.
Objetivo
  • Analizar las interacciones de las clases de análisis para encontrar interfaces, clases de diseño y subsistemas de diseño
  • Perfeccionar la arquitectura, incorporando la reutilización donde sea posible.
  • Identificar soluciones comunes a los problemas de diseño encontrados de forma común
  • Incluir elementos de modelo de diseño significativos arquitectónicamente en el apartado Vista lógica del Documento de arquitectura de software.
Relaciones
RolesPrincipal: Adicional: Asistencia:
EntradasObligatoria: Opcional:
  • Ninguno
Externa:
  • Ninguno
Salidas
Pasos
Identificar oportunidades de reutilización
Objetivo Identificar dónde se pueden reutilizar los subsistemas y/o los componentes existentes basándose en sus interfaces.  

Busque subsistemas o componentes existentes que ofrezcan interfaces similares. Compare cada interfaz identificada con las interfaces proporcionadas por los subsistemas o los componentes existentes. Normalmente no encontrará una coincidencia exacta, pero sí aproximadas. Busque primero comportamientos y valores devueltos similares y, a continuación, considere los parámetros.

Modifique las interfaces que acaba de identificar para mejorar la coincidencia. A veces, puede realizar cambios menores en una interfaz candidata que aumentarán su coincidencia con la interfaz existente. Un cambio sencillo sería reorganizar o añadir parámetros en la interfaz candidata y, a continuación, factorizar la interfaz dividiéndola en varias interfaces, una o varias de las cuales coincidirán con las del componente existente, mientras que los "nuevos" comportamientos se ubicarán en una interfaz aparte.

Sustituya las interfaces candidatas por interfaces existentes cuando encuentre coincidencias exactas. Después de la simplificación y la factorización, si encuentra una coincidencia exacta con una interfaz existente, elimine la interfaz candidata y utilice simplemente la interfaz existente.

Correlacione el subsistema candidato con los componentes existentes. Observe los componentes existentes y el conjunto de subsistemas candidatos. Descomponga en factores los subsistemas para que se utilicen los componentes existentes siempre que sea posible para satisfacer el comportamiento necesario del sistema. Cuando un componente existente pueda realizar un subsistema candidato, cree la rastreabilidad entre el subsistema de diseño y el componente en el modelo de implementación.

Cuando correlacione subsistemas con componentes reutilizables, tenga en cuenta los mecanismos de diseño asociados con el subsistema; los requisitos de rendimiento o seguridad pueden anular la reutilización de un componente, aunque exista una coincidencia perfecta entre las firmas de operación.

Revertir la ingeniería de los componentes y las bases de datos
Objetivo Incorporar elementos de modelo potencialmente reutilizables de otros proyectos, orígenes externos o iteraciones anteriores. 

El código existente y las definiciones de base de datos se pueden 'limpiar' para que el trabajo realizado en proyectos o iteraciones anteriores esté disponible en el proyecto/iteración actual. Si se utilizan como filtro las posibles oportunidades de reutilización, el trabajo de ingeniería revertida se podrá centrar en los componentes que son reutilizables para la iteración actual.

Revertir la ingeniería de los componentes

En las organizaciones que crean sistemas similares, a menudo existe un conjunto de componentes comunes que proporcionan muchos de los mecanismos de arquitectura necesarios para un nuevo sistema. También puede haber componentes disponibles en el mercado que proporcionen los mecanismos de arquitectura. Los componentes existentes se deben examinar para determinar su idoneidad y compatibilidad en la arquitectura de software.

Los componentes existentes, ya sean componentes desarrollados en iteraciones anteriores que no se han incluido todavía en el modelo de diseño o componentes adquiridos, deben revertir la ingeniería y se deben incorporar en el modelo de diseño. En el modelo de diseño, esos componentes se representan normalmente como un subsistema con una o varias interfaces.

Revertir la ingeniería de las bases de datos

Las bases de datos y los datos que residen en ellas representan una de las fuentes más importantes de activos reutilizables. Para reutilizar las definiciones de clase implícitas contenidas en las bases de datos existentes, determine qué información utilizada por la aplicación reside previamente en las bases de datos existentes. Revierta la ingeniería de un conjunto de clases para representar las estructuras de base de datos que mantienen esta información. Al mismo tiempo, construya una correlación entre la representación de clases de la aplicación y las estructuras utilizadas en la base de datos. Para obtener más información sobre cómo revertir la ingeniería de las bases de datos, consulte Directriz de producto de trabajo: Revertir la ingeniería de bases de datos relacionales. Para obtener más información sobre la correlación entre clases y tablas en una base de datos relacional, consulte Directriz de producto de trabajo: Modelo de datos.

Actualizar la organización del modelo de diseño
Objetivo Tener en cuenta los nuevos elementos de modelo en la organización del modelo de diseño.
Volver a equilibrar la estructura del modelo de diseño cuando sea necesario.  

Como se han añadido nuevos elementos al modelo de diseño, a menudo es necesario volver a empaquetar los elementos del modelo de diseño. Al volverlos a empaquetar se consiguen varios objetivos: se reduce el acoplamiento entre paquetes y se mejora la cohesión en los paquetes del modelo de diseño. El objetivo final es que personas o equipos independientes puedan diseñar y desarrollar paquetes (y subsistemas) diferentes independientemente unos de otros. Aunque una independencia completa es prácticamente imposible de conseguir, si se reduce el acoplamiento entre paquetes, el desarrollo de sistemas grandes o complejos tiende a ser más fácil.

Una estructura de modelo 'plana' (en la que todos los paquetes y subsistemas residan en el mismo nivel conceptual en el sistema) es adecuada para un sistema pequeño; los sistemas más grandes necesitan una herramienta de estructuración adicional denominada 'creación de capas' (consulte Directriz de producto de trabajo: Creación de capas). Las reglas de creación de capas definen restricciones en las relaciones permitidas entre determinados tipos de paquetes. Estas reglas reconocen que determinadas dependencias no deben existir: la funcionalidad de aplicaciones no debe depender directamente de servicios específicos del sistema de ventanas o del sistema operativo; debe existir una capa intermedia que contenga los servicios lógicos de ventanas y de sistema operativo que aíslen la funcionalidad de la aplicación de cambios en servicios de implementación de nivel inferior. La creación de capas permite reducir el impacto del cambio: al forzar reglas que restringen las dependencias entre paquetes y subsistemas, reduciendo el grado de acoplamiento entre paquetes y subsistemas, el sistema se hace más robusto. El sistema tolera el cambio.

A medida que se añaden al sistema nuevos elementos de modelo, los paquetes existentes pueden aumentar demasiado para ser gestionados por un único equipo: el paquete se debe dividir en varios paquetes con una cohesión elevada en el paquete y un acoplamiento reducido entre los paquetes. Conseguir esto puede ser difícil: algunos elementos no se pueden colocar fácilmente en un determinado paquete porque están siendo utilizados por elementos de los dos paquetes. Hay dos soluciones posibles: dividir en elemento en varios objetos, uno en cada paquete (esto funciona cuando el elemento tiene varias 'personalidades' o conjuntos de responsabilidades desconectadas de alguna forma) o mover el elemento a un paquete en una capa inferior, para que todos los elementos de capas superiores puedan depender de él equitativamente.

A medida que aumenta la complejidad del sistema, se necesita un número mayor de capas para conservar una estructura que se pueda mantener y entender. No obstante, no suelen darse más de 7-10 capas ni siquiera en los sistemas más grandes, ya que la complejidad aumenta y la comprensión disminuye con el número de capas.

A continuación, se muestra un ejemplo de creación de capas, incluidas las capas de middleware y software del sistema:

Diagrama de diseño para una aplicación Java/Web

Ejemplo de capas de paquete de una aplicación basada en Java/Web. Nota: las dependencias del paquete TCP/IP normalmente no se modelarán explícitamente ya que el uso de servicios TCP/IP está encapsulado en Java VM, java.rmi y el navegador web. Aquí se incluyen sólo a modo de ilustración.

Asigne responsabilidades de los subsistemas y las capas a las personas o los equipos. Cada paquete o subsistema debe ser responsabilidad de una única persona (si el ámbito es pequeño) o un equipo (si el ámbito es grande).

Actualizar la vista lógica
Objetivo Garantizar que el Producto de trabajo: Documento de arquitectura de software (Vista lógica) permanezca actualizado.  

Cuando el diseño de clases, paquetes y subsistemas (elementos de modelo) es importante desde el punto de vista de la arquitectura, se deben incluir en el apartado Vista lógica de Producto de trabajo: Documento de arquitectura de software. Esto garantizará que los nuevos elementos de modelo significativos para la arquitectura se comuniquen a los miembros de otros equipos de proyectos.

Asimismo, el rol de arquitecto de software colabora con el rol de ingeniero de procesos para proporcionar instrucciones detalladas a los diseñadores e implementadores sobre cómo utilizar los elementos de diseño que se acaban de incorporar.



Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información