articulan las decisiones de diseño que determinan las propiedades primarias de comportamiento y estructura de un programa (sistema de software). Las decisiones estratégicas se refieren a cuestiones globales, que afectan a todo el sistema, y tienen las implicaciones más importantes. Las decisiones estratégicas incluyen la elección del paradigma de programación (‘programación orientada a objetos’), el estilo arquitectónico (‘tuberías y filtros’), el marco de aplicación (‘Microsoft Foundation Classes’), los estándares de ingeniería de software basados en componentes (‘Enterprise JavaBeans’), y los principios de diseño (‘clase base universal’), así como las suposiciones que pueden llevar a un desajuste arquitectónico (‘El Servidor de Mensajes de Transmisión de Softbench esperaba que todos los componentes tuvieran una interfaz gráfica de usuario’) y las regularidades gobernadas por la ley (‘cada clase del sistema hereda de la clase C’). Debido a las consecuencias que conllevan, las decisiones estratégicas deben tomarse al principio del proceso de desarrollo de software y deben establecerse explícitamente antes de realizar cualquier diseño detallado.
En cambio, las declaraciones de diseño táctico articulan las decisiones de diseño que se refieren a un módulo específico. Las decisiones tácticas suelen describir un patrón de correlaciones entre una colección de módulos (objetos, procedimientos, clases, etc.) y otra. Intuitivamente hablando, las sentencias tácticas son «locales» en el sentido de que su alcance se limita a alguna parte del programa y no fuera de él. Las decisiones tácticas incluyen la elección de patrones de diseño (‘Factory Method’), refactorizaciones (‘Replace Conditional With Polymorphism’), y modismos de programación (‘counted pointer’), y normalmente se toman mucho más tarde que las decisiones estratégicas de diseño en el proceso de desarrollo de software.
Aunque estoy ampliamente de acuerdo con la regla general de global = estratégico y local = táctico, no debe considerarse un absoluto. Es posible que un segmento de un sistema tenga aspectos que influyan fuertemente en la arquitectura global (justificando el criterio de importancia de Booch). Esta es la razón por la que no mantengo la opinión de que los requisitos funcionales son el diseño y los no funcionales son la arquitectura.
Arnon Rotem-Gal-Oz, director de arquitectura de Nice Systems, identifica varios aspectos de la arquitectura en su presentación «Software Architecture». La arquitectura comprende los principales componentes de un sistema; sus relaciones e interacciones. Los datos y el comportamiento de estos componentes principales sólo son relevantes para la arquitectura desde el punto de vista de las interacciones entre estos componentes. Al igual que Booch, Rotem-Gal-Oz caracteriza la arquitectura como las partes del sistema más difíciles de cambiar. Al igual que Eden, Kazman e Hirshfeld, define la arquitectura como las decisiones de diseño que deben tomarse en las primeras fases del proceso.
El valor de las decisiones de diseño estratégicas y fundacionales debería ser obvio. Dado que estos aspectos del sistema son difíciles y costosos de cambiar, debería haber un incentivo considerable para tomar decisiones óptimas. Como señala Kevlin Henney en «What is Software Architecture?» en developerFusion:
La cuestión no es si un sistema tiene o no arquitectura, sino si su arquitectura es buena o no. Todos los sistemas tienen arquitectura, ya sea intencionada o accidental, explícita o implícita, buena o mala – ¡incluso los sistemas «sin arquitectura» tienen arquitectura!
Al haber relacionado la arquitectura con el coste del cambio, tenemos una forma sencilla de evaluar la calidad arquitectónica. No es que una buena arquitectura haga que un sistema sea barato de crear; es que también es barato de evolucionar. En otras palabras, una buena arquitectura es aquella en la que se minimiza la importancia de las decisiones de diseño. Se tiene la libertad de cambiar muchos aspectos de un sistema sin temor a que esos cambios sean difíciles, costosos o creen una cascada de errores. Una buena arquitectura es, por tanto, una arquitectura sostenible.
Dada la criticidad de estas decisiones de diseño, no tiene mucho sentido dejarlas al azar. Es poco probable que la arquitectura sostenible y flexible surja de forma orgánica. Se necesitará una planificación y coordinación suficientes por parte de alguien que desempeñe el papel de arquitecto (independientemente de si el papel es a tiempo completo o parcial). Las decisiones de diseño localizadas pueden entonces tomarse dentro de ese marco de forma descentralizada.
De vez en cuando escucho a la gente que sigue levantando el mantra ágil contra el Big Design/Requirements Up Front. La cosa es que el Manifiesto Ágil nunca dijo que se enterrara intencionadamente la cabeza en la arena con respecto al propósito del sistema. Era un empuje contra el hecho de pasar meses en el análisis sin que salga nada más que documentos, pero el objetivo era llegar a un punto medio. Nadie dijo nunca «sin diseño por adelantado» o «sin requisitos por adelantado».
(Udi Dahan de «A CQRS Journey – with and without Microsoft»)
Reposted from Form Follows Function