El diseñador y el desarrollador
sólo ven el caso de uso en desarrollo sin importarles el sistema como un
todo. Cuando esto se hace así, y no por paquetes relacionados, corremos
el riesgo de no armar el “rompecabezas” con facilidad al final de la operación.
Y lo que es peor, muchas
veces durante el diseño e implementación del caso de uso no tenemos en cuenta
los lineamientos arquitectónicos impuestos a la solución. El producto termina
siendo una colcha de retazos mal cosidos. Esta situación convierte los hitos de
integración del producto, iteración tras iteración, fase tras fase, en un serio
dolor de cabeza para el arquitecto, los diseñadores y los mismos programadores.
Entonces surgen los reprocesos, el desperdicio de código, rediseños, y el
resultado final: un producto de mala calidad.
El tratamiento: la arquitectura del software. Una que
sirva como una gran lista de chequeo para los diseñadores y para los
implementadores del producto. La arquitectura de software es la
organización fundamental de un
sistema, formado por sus componentes,
las relaciones entre ellos
mismos y con el entorno, y los principios
que gobiernan su diseño y evolución (IEEE
1471-2000). Según Booch, Kruchten y otros, la
Arquitectura de Software incluye decisiones acerca de la organización de un
sistema de software como:
·
La selección de los elementos
estructurales que componen el sistema y sus interfaces
·
El comportamiento del sistema,
especificado en las colaboraciones entre esos elementos
·
La composición de estos elementos
estructurales y comportacionales en subsistemas más grandes
·
El estilo arquitectónico que guía
esta organización
Toda arquitectura de
software comienza por una arquitectura funcional o vista de casos de uso, un
subconjunto del modelo de casos de uso del sistema, compuesto a su vez por los
así llamados casos de uso o requisitos arquitectónicos. Después están la vista
lógica, que le habla a los analistas y diseñadores sobre la estructura del
software. La vista de implementación, que les cuenta a los programadores
detalles sobre el manejo del software. Por su parte, la vista de procesos habla
de desempeño, escalabilidad y puesta en marcha a los integradores del sistema.
Y también está la vista de despliegue que nos explica de manera lacónica la
topología del sistema, aspectos de la entrega del mismo, de instalación y de
comunicación subyacentes.
El diseño y la
implementación de todo el producto de software debe obedecer a estas
restricciones, casi leyes, impuestas por la arquitectura así descrita. Es lo
que hace posible que los casos de uso se diseñen en grupos heterogéneos de
paquetes o subsistemas diferentes.
Impacto en la calidad: Alto.
PD. Para saber sobre Arquitectura de Software,
específicamente sobre el modelo de las 4 + 1 vistas expuesto por Krutchen,
pueden tener en cuenta la siguiente referencia:
P.B. Kruchten, “The 4 + 1
View Model of Architecture,” IEEE Software, pp. 42–50, Nov. 1995. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=469759&isnumber=9910
También la
encuentran en:
Además, sobre análisis y diseño de casos de uso, en particular, sobre
realización de casos de uso, pueden visitar mi Lectura Fundamental 10:
Y sobre
programación orientada a objetos, pueden leer mi Lectura Fundamental 11: Orientación a Objetos: Un Enfoque Teórico Moderno
(Actualizado)
