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