Durante esta actividad, es importante crear al menos un diagrama de clase que muestre las relaciones
entre los componentes técnicos y funcionales de cada componente de servicio. El modelado de UML estándar se aplica en
esta etapa. Se recomienda el uso de patrones para estructurar el gráfico de objetos resultante de forma que sea
extensible y esté abierto a cambios. Si se anticipa un grado mayor de cambios, es recomendable realizar un análisis de variabilidad en esta etapa.
Tal como describimos en la tarea anterior, cuando se diseñan cambios, o se anticipa un impacto importante en el diseño
y la estructura del sistema de TI como consecuencia de cambios empresariales futuros, entonces sería inteligente
emplear las técnicas de Análisis de variabilidad. Estas técnicas refactorizan los factores comunes y
externalizan las variaciones mediante patrones de diseño. Los factores en común y las variaciones descubiertas
previamente pueden utilizarse como punto de partida y pueden aumentar con el uso de patrones de diseño comunes como
Estrategia, Estado [i], Objeto de regla [ii], Objeto de tipo, etc.
El análisis realizado durante el diseño detallado identifica factores comunes, se centra en la creación de variaciones
conectables y entraña seis principios que ayudan a separar los aspectos más cambiantes de los menos de los sistemas de
software, aislando y encapsulando los cambios:
-
Separar y modelar los aspectos cambiantes de los no cambiantes del dominio: identificar, separar, encapsular y
externalizar variaciones en aumento.
-
Crear jerarquías de tipos para cada punto de variación.
-
Asignar tipos de regla a cada tipo de variación.
-
Implementar tres niveles de abstracción; utilizar metapatrón de herencia agregado
-
Empezar a partir de niveles de reutilización superiores a los objetos y crear activos en cada nivel de
reutilización; crear infraestructuras pequeñas alrededor de los puntos de variación. En general, cada
infraestructura no debería tener más de 7+-2 clases.
-
Cada elemento de reutilización tiene sus propios comportamientos. Externalizar el comportamiento como datos
configurables que se puedan leer en la aplicación para permitir un cableado ligero.
[i] Erich
Gamma, Richard
Helm, Ralph
Johnson, John
Vlissides, Design Patterns, Addision-Wesley 1994.
[ii] Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules,
Washington University Technical Report number: wucs-00-29, Proceedings of the Pattern Languages of Program
Design, 2000.
|