jueves, 25 de septiembre de 2008

DESVENTAJAS

Decisiones tempranas de diseño. La Arquitectura de Software representa la encarnación de las decisiones de diseño más tempranas sobre un sistema, y esos vínculos tempranos tienen un peso fuera de toda proporción en su gravedad individual con respecto al desarrollo restante del sistema, su servicio en el despliegue y su vida de mantenimiento. La arquitectura representa lo que el método SAAM una puerta de peaje: el desarrollo no puede proseguir hasta que los participantes involucrados aprueben su diseño.

Mas que desventajas la Arquitectura de Software presenta problemas que son la evaluación dominante de la trayectoria de la Arquitectura de Software es abiertamente positiva, en los primeros años del siglo comienzan a percibirse desacuerdos y frustraciones en el proyecto de la disciplina. Por empezar, está muy claro que la definición original del proyecto, formulada en círculos académicos, guarda poca relación con la imagen que se tiene de la Arquitectura de Software en las prácticas de la industria. Aún dentro de los confines de aquel círculo, a menudo las presentaciones distan de ser contribuciones desinteresadas y representan más bien posturas teóricas particulares que se quieren imponer por vía de la argumentación. Muchas de esas posturas son más programáticas que instrumentales. Un número desmesurado de artículos y ponencias destaca asimismo la frustración que muchos sienten por no haber podido consensuar una definición de la AS universalmente aceptada.

Vale la pena revisar el inventario de aspectos negativos elaborada por Clements y Northrop:

Los abogados de la distintas posturas traen sus sesgos consigo. En efecto, mientras las definiciones propuestas para la Arquitectura de Software coinciden en su núcleo, difieren seriamente en los bordes. Algunos autores requieren que la arquitectura incluya racionalización, otros piden más bien pasos para el proceso de construcción. Algunos exigen que se identifique la funcionalidad de los componentes, otros alegan que una simple topología es suficiente. En la lectura de los textos de Arquitectura de Software se torna esencial entonces conocer la motivación de sus responsables.

El estudio de la AS está siguiendo a la práctica, no liderándola. El estudio de la Arquitectura de Software ha evolucionado de la observación de los principios de diseño y las acciones que toman los diseñadores cuando trabajan en sistemas de la vida real. La Arquitectura de Software es un intento de abstraer los rasgos comunes inherentes al diseño de sistemas, y como tal debe dar cuenta de un amplio rango de actividades, conceptos, métodos, estrategias y resultados. Lo que en realidad sucede es que la Arquitectura de Software se redefine constantemente en función de lo que hacen los programadores.

El estudio es sumamente nuevo. Aunque sus raíces se prolongan en el tiempo, el campo de la Arquitectura de Software es realmente muy nuevo, según puede juzgarse de la reciente avalancha de libros, conferencias, talleres y literatura consagrado a ella.

Las fundamentaciones han sido imprecisas. El campo se ha destacado por la proliferación de términos inciertos, verdaderas amenazas para los no precavidos. Por ejemplo, la arquitectura definida como “la estructura global de un sistema” agrega confusión en lugar de reducirla, porque implica que un sistema posee una sola estructura.

El término se ha usado en exceso. El significado de la palabra “arquitectura” en su relación con la ingeniería de software se ha ido diluyendo simplemente porque parece estar de moda. Es posible encontrar referencias a las siguientes “clases” de arquitectura: específica de dominio, megaprogramación, destinatario, sistemas, redes, infraestructura, aplicaciones, operaciones, técnica, framework, conceptual, de referencia, empresarial, de factoría, C4I, de manufactura, de edificio, de máquina-herramienta, etcétera. A menudo la palabra “arquitectura” se usa de maneras inapropiadas.