E Brooks, en un artículo de 1987 titulado “No Silver Bullet: Essence and Accidents of Software Engineering”, compara a los proyectos de software con el hombre lobo: de ser algo familiar, de pronto se convierten en una pesadilla. En dicho escrito, el autor resalta algunas —para ese tiempo— potenciales “balas de plata”, que eliminarían este terror. Entre ellas, manifiesta la importancia que tienen los buenos diseñadores en el desarrollo de software. Los diseñadores de los que escribió Brooks, bien pueden ser los arquitectos de hoy.
Una Breve Historia de la Arquitectura de Software
Aunque el término “arquitectura de software”, tal y como lo concebimos ahora, aparece en 1992 con el trabajo de Perry y Wolf[1], sus antecedentes se remontan al menos hasta finales de la década de los sesenta. En 1968, Dijkstra habla de una estructuración correcta de los sistemas de software, aunque no la llama arquitectura como tal[2]. Posteriormente, en 1969, P. I. Sharp, comentando las ideas de Dijkstra, ya usa el término arquitectura de software al mencionar que quizá luego se hable de “la escuela de arquitectura de software de Dijkstra”, y al mismo tiempo lamentar que la industria de ese tiempo preste muy poca atención a ésta.
Durante la década de los setentas el concepto de arquitectura deambuló por el aire sin una semántica clara y carente de una expresión pragmática. En esta misma década, el diseño estructurado dio pie a la independencia entre el diseño y la implementación. Los trabajos de Parnas sobre técnicas de modularización en decisiones de diseño y familias de programas[3], fueron, sin duda, aportaciones esenciales y permanentes.
Las decisiones “tempranas” de diseño, argüía Parnas, probablemente permanecerían invariantes en el desarrollo de la solución; estas ideas se convierten luego en lo que hoy se conocen como decisiones arquitectónicas.
Rompiendo esquemas y acaparando la atención en la década de los ochentas, aparece el paradigma de la orientación a objetos. En esta década aparecen dos trabajos importantes de Mary Shaw, que retoman las abstracciones de alto nivel: “Técnicas de abstracción en lenguajes modernos de programación”[4] y “Los sistemas de gran escala requieren de abstracciones de alto nivel”[5].
Hacia finales de los ochenta y principios de los noventa, comienza a gestarse de manera más clara la idea de que las aplicaciones tienen una morfología, una estructura. El trabajo de Perry y Wolf[1] de 1992 es el punto de partida para lo que hoy conocemos como arquitectura de software. Por un lado, son los primeros que proponen un modelo para la arquitectura de software; este modelo contempla a la arquitectura formada por tres componentes: elementos, forma y razón. Los elementos pueden ser de procesamiento, datos o conexión; la forma se define de acuerdo a las propiedades de, y a las relaciones entre los elementos; la razón se contempla en términos de restricciones del sistema, que se derivan de los requerimientos del sistema.
Perry y Wolf profetizaron que: “la década de los noventas, creemos, será la década de la arquitectura de software”, lo cual se convirtió en realidad. A lo largo de esa década, salieron a la luz varios trabajos con propuestas relevantes, entre ellas, la programación basada en componentes[6], el surgimiento de los patrones y estilos[7], el modelo de 4+1 vistas[8], y lenguajes de descripción de arquitecturas (ADLs)[9] entre otras.
En la segunda mitad de los noventa aparecen los primeros libros de texto dedicados a la arquitectura de software. El año 2000 cierra esta década con dos trabajos clave: el modelo REST propuesto en la tesis de Roy Fielding que pone la atención en Internet y los modelos orientados a servicios[10]; y el trabajo de la IEEE, que genera una versión definitiva de la recomendación IEEE std 1471-2000[11].
También en este año se abren nuevas perspectivas para la arquitectura de software, aparecen las estrategias orientadas a líneas de productos y se procura insertar la arquitectura de software dentro del ciclo de vida, obligando a redefinir las metodologías referentes a él en términos de arquitectura[12].
Actualmente hay una cierta efervescencia alrededor de desarrollos centrados en arquitectura, métodos de análisis y diseño de arquitecturas (dentro del ciclo de vida), análisis de arquitecturas de software basados en escenarios, modelos de evaluación de arquitecturas de software y modelos orientados por la arquitectura entre algunos otros tópicos.
Definiciones, Definiciones, Definiciones...
Martin Fowler, en su artículo “Who needs an Architect?”[13], deja salir su cinismo (según él mismo lo expresa), y como primer intento, define arquitectura como: “una palabra que utilizamos cuando queremos hablar del diseño y queremos que se escuche como algo importante”. Encontrar una definición aceptada universalmente no es tarea fácil, de hecho no existe. Por el contrario, se puede literalmente nadar en un mar de definiciones[14]. Lo que existe es un consenso intuitivo de qué es arquitectura de software. Este consenso intuitivo involucra generalmente un diagrama: círculos o cuadros unidos por alguna línea, alguna identificación de estos elementos y poca cosa más. La interpretación recae en forma importante en quién la ve (y la puede entender) o la diseña, y seguramente fuera de este círculo lo que provoca es simplemente confusión.
La construcción de una definición textual de arquitectura de software se basa y se ha basado en la mayoría de los casos en interpretar estos diagramas y darles de alguna manera coherencia. Así podemos encontrar que las definiciones iniciales se refieren a componentes o elementos relacionados entre sí (estructura) primordialmente. Luego se le ha agregado que también las propiedades de los elementos son parte de la arquitectura; otros más se decantan por el conjunto de decisiones de diseño (sin marcar cómo podrían mostrarse en un diagrama), y algunos más aterrizan la definición como aquellos aspectos que son inmutables en un sistema de software o difíciles de cambiar. Una definición a la que se recurre más es la presentada por Bass, et al.[15]: “Una arquitectura de software de un programa o un sistema computacional es la estructura del sistema, la cual comprende elementos de software, las propiedades externamente visibles de esos elementos, y las relaciones entre ellos”.
El principal problema con las definiciones que se han dado (cientos) es que aunque tratan de ubicar una idea clara de lo que es arquitectura de software, terminan por ajustarse al entorno en cuestión y sólo establecen para ese momento un consenso. No es difícil encontrar que cada trabajo sobre arquitecturas, sobre todo los académicos, inician por adaptar o formular lo que para su contexto se entenderá por arquitectura de software.
Evidentemente esta debilidad alrededor de una definición formalmente aceptada no ha impedido que existan trabajos tanto prácticos como académicos, y por lo tanto, un desarrollo sustancial en la disciplina. Quizá el lector tenga la sensación de que entonces no hay problema. En parte sí, antes de la postulación de la ley de la gravedad las manzanas seguían cayendo igual; pero una vez formulada, el panorama se vio muy diferente.
A Futuro... Trabajo Básico por Hacer
Le propongo al lector un par de ejercicios. Examine cualquier diagrama que se ostente como representación de una arquitectura, luego intente tomar la definición mencionada anteriormente o cualquier otra y busque emparejarlas; seguramente tendrá algunas dificultades.
Otro ejercicio puede ser pasear un poco por el Proceso Unificado de Racional (RUP) que pregona ser un proceso orientado por casos de uso y centrado en la arquitectura; de nuevo, ajustar la definición de arquitectura de software empelada en ese momento (por el autor que escribe o diserta sobre RUP) con algunos de los artefactos que se proponen en este proceso no es una tarea sencilla... igual, encontrará dificultades. Para empezar, existe un cierto sentimiento dentro de la academia que estimula a pensar que los diagramas propuestos por UML no son precisamente una representación arquitectónica.
Como se puede apreciar, no todo es un lecho de rosas. La bala de plata aún está en construcción (aunque sería iluso pensar que algún día se terminará de construir) y la arquitectura de software es tan sólo un elemento importante.
Conclusión
La arquitectura de software, con alrededor de 15 años de vida (si consideramos su nacimiento a partir de 1992), ha emergido como una disciplina de gran importancia dentro de la ingeniería de software. Una arquitectura adecuada es pieza clave para lograr tanto los requerimientos funcionales como no funcionales de un sistema. Por otro lado, una arquitectura no adecuada puede ser catastrófica.
La arquitectura también juega un papel importante en otros aspectos del desarrollo de software:
• Mejora la comprensión de sistemas grandes y complejos.
• Permite una mejor comunicación entre los diferentes interesados (stakeholders) en el sistema.
• Mejora las posibilidades de reuso.
• Proporciona planos para la construcción.
• Toma en cuenta la posible evolución del sistema.
Durante la revisión de este artículo, Cuauhtémoc Lemus y Gerardo Padilla (CIMAT), a quien agradezco su tiempo, plantearon una pregunta importante e interesante: ¿cuál es el estatus de la arquitectura de software en las instituciones de educación y en la industria de software mexicanas? Por lo pronto no hay respuesta, pero por allí andaremos.
Referencias
1. Dewayne E. Perry y Alexander Wolf. “Foundations for the study of software architecture”, ACM SIGSOFT Software Engineering Notes, 17(4), pp. 40-52, Octubre de 1992.
2. Edsger Dijkstra. “Go-To statement considered harmful”. ACM Communications of the ACM, 11(3), pp. 147-148, Marzo de 1968.
3. David Parnas, “On the criteria for decomposing systems into modules” Communications of the ACM 15(12), pp. 1053-1058, December 1972
4. Mary Shaw, “Abstraction techniques in modern programming languages “ IEEE Software, pp. 10-26, October 1984.
5. Mary Shaw, “Large scale systems require higher level abstraction”, Proceedings of fifth international workshop on software specification and design. IEEE Computer Society, pp. 143-146, 1989.
6. Paul Clements, “Coming attractions in software architecture”, Technical report, CMU/SEI-96-TR-008, ESC-TR-96-008, jan. 1996.
7. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, “Design Patterns: Elements of reusable object-oriented software. Reading, Addison-Wesley, 1995.
8. Philippe Krutchen, “The 4+1 view model architecture”, IEEE Software 12(6), pp. 42-50, nov. 1995.
9. Paul Clements, “A survey of architecture descriptions languages” Proceedings of the International Workshop on Software Specification and Design, Germany, 1996.
10. Roy Thomas Fielding, “Architecture styles and design of network-based software architectures” PhD Thesis, California University, Irvine 2000.
11. Software Engineering Standards Committee of the IEEE Computer Society, IEEE Recommended practice for architecture description of software-intensive systems, IEEE Std 1471-2000, Approved 21 September 2000, IEEE-SA Standards Board, Print: ISBN 0-7381-2518-0 SH94869, PDF: ISBN 0-7381-2519-9 SS94869, available at (http://standards.ieee.org/).
12. “The open group architectural framework” Versión 8, document number I911, dec. 2002.
13. M. Fowler, “Who needs an Architect?”, IEEE Software, pp 11-13, Septiembre-Octubre 2003.
14. http://www.sei.cmu.edu/architecture/definitions.html#new_visitors.
15. L., Bass, P., Clements, R., Kazman, Software architecture in practice, SEI Series in Software Engineering, Second Edition, Addison Wesley, 2nd printing, October 2003.
Acerca del autor
Luis Felipe Fernández Martínez es profesor investigador del departamento de eléctrica y computación del Instituto de Ingeniería y Tecnología de la Universidad Autónoma de Ciudad Juárez. Durante el 2003 estuvo como investigador invitado del grupo de ingeniería de software del CIMAT y colaboró en la creación y desarrollo de la Maestría en Ingeniería de Software. Actualmente colabora en proyectos de investigación con el mismo grupo y es candidato a doctor por la Universidad Politécnica de Catalunya, Barcelona, España; su trabajo de tesis gira entorno a arquitecturas de software. lfernand@uacj.mx
- Log in to post comments