Concepto: Correlación de diseño a código
En esta directriz se describen varios opciones diferentes para pasar de un diseño a la implementación y se tratan las ventajas y las desventajas de estas propuestas.
Relaciones
Elementos relacionados
Descripción principal

Introducción

El diseño debe definir el sistema lo suficiente para que se pueda implementar sin ambigüedades. Lo suficiente varía de un proyecto a otro y de una empresa a otra.

En algunos casos, el diseño parece un esbozo, elaborado lo justo para garantizar que el implementador puede avanzar en el trabajo (una propuesta "esbozo y código"). El grado de especificación varía según la experiencia del implementador, la complejidad del diseño y el riesgo de que el diseño se malinterprete.

En otros casos, el diseño está tan elaborado que se puede transformar automáticamente en código. Esto suele implicar ampliaciones del UML estándar para representar la semántica específica del entorno y/o lenguaje.

El diseño también puede ser jerárquico, como el siguiente:

  • un modelo de diseño de alto nivel que esboza una visión general del sistema global
  • un modelo de especificación del subsistema que especifica de forma precisa las interfaces necesarias y el comportamiento de los principales subsistemas del sistema
  • un modelo de diseño detallado para las características esenciales de los subsistemas

El Guión de desarrollo debe definir cómo se realiza el modelo de diseño en el proceso específico del proyecto y cómo/si el modelo se relaciona con otros modelos y con la implementación. Los detalles deben capturarse en las Directrices específicas del proyecto.

Los apartados que siguen describen varias opciones diferentes para relacionar un diseño y la implementación, y tratan sobre las ventajas y desventajas de estas propuestas.

Esbozo y código

Una propuesta común de diseño es un esbozo a nivel bastante abstracto que, posteriormente, se pasa directamente a código. El mantenimiento del modelo de diseño es manual.

En esta propuesta, se permite que una clase de diseño sea una abstracción de varias clases de nivel de código. Es recomendable correlacionar cada clase de diseño con una clase "principal" que, a su vez, puede utilizar varias clases de "ayudante" para realizar su comportamiento. Puede utilizar las clases de "ayudante" para implementar un atributo complejo o construir una estructura de datos necesaria para implementar una operación. En el diseño, no se modelan las clases de "ayudante"; sólo se modelan los atributos clave, las relaciones y las operaciones que define la clase principal. El objetivo de este modelo es extraer los detalles que puede completar el implementador.

Esta propuesta se amplía para aplicarse a otros elementos del modelo de diseño. Es posible que tenga interfaces de diseño más abstractas que las interfaces de nivel de código, etc.

Ingeniería directa e inversa

En los entornos de ingeniería directa e inversa, el modelo de diseño evoluciona hasta un nivel de detalle en que se convierte en una representación visual del código. El código y su representación visual están sincronizados (con soporte de herramientas).

A continuación se muestran varias opciones para representar un modelo de diseño en un contexto de ingeniería directa e inversa.

Modelo de diseño de alto nivel y modelo de diseño detalladoIr a la parte superior de la página

En esta propuesta, se mantienen dos niveles de modelos de diseño. Cada elemento de diseño de alto nivel es una abstracción de uno o varios elementos detallados en el modelo directo e inverso. Por ejemplo, una clase de diseño puede correlacionarse con una clase "principal" y varias clase de "ayudante", igual que en la propuesta de "esbozo y código" descrita anteriormente. La rastreabilidad desde los elementos de modelo de diseño de alto nivel hasta los elementos de modelo directo e inverso puede ayudar a mantener la coherencia entre los dos modelos.

A pesar de que puede ayudar a extraer detalles menos importantes, esta ventaja debe valorarse en comparación con el esfuerzo necesario para mantener la coherencia entre los modelos.

Único modelo de diseño en desarrolloIr a la parte superior de la página

En esta propuesta, hay un solo modelo de diseño. Los esbozos iniciales de elementos de diseño evolucionan hasta que se pueden sincronizar con el código. Los diagramas, como los que se utilizan para describir realizaciones de guiones de uso de diseño, en un principio hacen referencia a las clases de diseño esbozadas pero, al final, hacen referencia a clases específicas de lenguaje. Las descripciones de alto nivel del diseño se mantienen según sea necesario, por ejemplo:

  • diagramas de la estructura lógica del sistema,
  • especificaciones del componente / subsistema,
  • mecanismos / patrones de diseño.

Un modelo de este tipo es más fácil para conservar la coherencia con la implementación.

Modelos de realización y especificación

Una propuesta relacionada es definir el diseño en términos de especificaciones para subsistemas principales, detallados para que las implementaciones del cliente se puedan compilar en ellos.

El diseño detallado de la realización del subsistema se puede modelar y mantener independientemente de este modelo de especificación.

Consulte el apartado Directriz de producto de trabajo: Subsistemas de diseño para obtener directrices relacionadas con las realizaciones y especificaciones del subsistema y sobre cuándo se deben utilizar.