Actualidad

Revista del Instituto Tecnolgico de Informtica

Arquitectura del Software: arte y oficio

La arquitectura de un software puede entenderse como aquella estructura del programa que cohesiona las funcionalidades ms crticas y relevantes (necesarias para el sistema), y que sirve de soporte al resto de funcionalidades nales (necesarias para el usuario). Su especicacin es ampliamente aceptada como el problema central de diseo de un sistema de software complejo. Uno de los principios de las metodologas modernas de desarrollo de software es priorizar la denicin, el diseo, la implementacin y la evaluacin de la arquitectura del software. La esencia de este principio es dedicar los mnimos esfuerzos a implementar un prototipo estable de arquitectura que garantice la viabilidad del proyecto en las fechas ms tempranas posibles. Este artculo reexiona sobre la importancia de priorizar la arquitectura tanto para el producto de software como para el proceso de desarrollo, y sobre los benecios potenciales que esta prctica puede reportar. Introduccin Casi todos hemos observado alguna vez la construccin de un edicio. Comienza por los cimientos, luego las columnas y vigas, las distintas plantas, hasta tener un esqueleto de soporte. Despus se construyen paredes, suelos, puertas y ventanas, instalaciones elctricas y de fontanera, bancadas, etc. Basta un mnimo de sentido comn para ni siquiera imaginar la posibilidad de levantar una pared antes que las columnas. En resumen, primero se crea la estructura o esqueleto del edicio, y luego se ensamblan las distintas partes. La primera sirve de soporte a las segundas, que aportan la mayora de las funcionalidades bsicas del inmueble. Qu pasara si se cometen errores en una u otra? Si se olvida construir una columna y se detecta al nalizar el edicio, probablemente este no obtenga nunca la cdula de habitabilidad. Sin embargo, si lo que se olvida es instalar una baera o un armario empotrado se pierde solo una funcionalidad del inmueble (para el usuario nal), pero indudablemente ser habitable y dicho fallo ser probablemente subsanable con un esfuerzo relativamente pequeo. Esta forma de proceder es una estrategia general de solucin de problemas en multitud de disciplinas sociales y tcnicas. Una de ellas es la creacin de software. A diferencia de la construccin de un edicio comn, el software no se rige por leyes fsicas ni por procedimientos conocidos, sino que es inherentemente especco y experimental. Como indica su nombre, la caracterstica principal del software es ser soft, es decir, exible, elstico y, en general, muy especco para la solucin de una tarea concreta, sobre sistemas de hardware concretos, por personal con actitudes, aptitudes, formacin y experiencia concretas. Todo esto hace del diseo de un software particular una tarea generalmente nica, creativa, con las incertidumbres y riesgos que ello conlleva. Uno de los principios de las metodologas modernas de desarrollo de software es priorizar la denicin, el diseo, la implementacin y la evaluacin de la arquitectura del software, que es como se conoce al esqueleto o estructura del sistema. Desde el punto de vista de qu debe hacer el software, la arquitectura se dene a partir de un conjunto de requisitos crticos funcionales, de rendimiento, o de calidad. Considerando cmo el software debe dar solucin a tales objetivos, la arquitectura constituye el problema central de diseo, es decir, el conjunto de estructuras, clases y atributos principales del software y sus interfaces de comunicacin. Desde otro punto de vista ms tangible, la arquitectura se materializa en el conjunto de componentes de cdigo fuente y ejecutables que implementan Priorizar la arquitectura aporta beneficios al proceso de construccin del software. dicho esqueleto, lo que posibilita demostrar y evaluar en qu medida el diseo da solucin a aquellos requisitos crticos. Dado que no existe una teora establecida sobre cmo proceder, el diseo, implementacin y evaluacin de la arquitectura de un software complejo puede realizarse a travs de un proceso iterativo de prototipado, demostracin y correccin. Este proceso permite atender y resolver en los inicios del proyecto los riesgos asociados a los requisitos ms crticos y a las decisiones de diseo ms difciles, que son aquellos que ms pueden comprometer el xito del proyecto. As, el equipo de desarrollo debe disear, construir y estabilizar primero la arquitectura del software antes de disear e implementar el conjunto de componentes elementales que se integran en la arquitectura y que aportan las funcionalidades nales de usuarios. La esencia del principio de priorizar la arquitectura es dedicar los mnimos esfuerzos a garantizar la correccin de las partes ms importantes, costosas e indenidas del sistema, y cuyo prototipo permita una demostracin tangible de la viabilidad del proyecto. Descripcin de la arquitectura del Software El software tradicional, como nico proceso ejecutndose en un nico ordenador, no supone arquitecturas complejas ni grandes riesgos. Sin embargo, los sistemas actuales aprovechan componentes comerciales, cdigo abierto, sistemas distribuidos, nuevos y diversos lenguajes de programacin, entornos de alojamiento (hosting) y de ejecucin remota, y otras dependencias externas, que convierten a la arquitectura de un sistema en su producto tcnico ms crtico. Alcanzar una arquitectura estable que d garantas sobre la viabilidad del proyecto, se considera el punto de transicin entre lo que se suele denominar la fase de ingeniera

Actualidad
Revista del Instituto Tecnolgico de Informtica

Arquitectura del Software: arte y oficio

(denicin del producto y su solucin) y la fase de pro- para la arquitectura desde la perspectiva de los programaduccin (construccin, integracin, evaluacin y entrega dores; puede incluir componentes de prueba, comerciales, del producto). En la primera se toman las decisiones ms de simulacin, que luego pueden o no ser considerados importantes mientras que en la segunda se realizan los en la vista de entrega; puede ser modelado estticamente mayores gastos y esfuerzos. a travs del diagrama de componente. La clave del xito y a su vez la dicultad del principio de vista de entrega: describe los componentes ejecutables priorizar la arquitectura consiste en denir qu es y qu de la arquitectura, incluyendo la correspondencia entre no es la arquitectura. Si incluimos demasiados detalles procesos lgicos y recursos fsicos del entorno de exploperdemos la propiedad de conguracin mnima nece- tacin; puede ser modelado estticamente a travs del saria (o ms simple posible), que nos permite demostrar, diagrama de distribucin. con el mnimo esfuerzo y en fechas tempranas, la correccin de la solucin diseada. Si, por el contrario, denimos una conguracin ms simple de lo necesario, estaremos probablemente ignorando requisitos, riesgos, o interacciones crticas, lo cual impide dar garantas sobre el xito del proyecto antes de realizar los mayores esfuerzos y gastos de la Figura 1: Ejemplo de diagrama de distribucin (UML) de una arquitectura clienfase de produccin. te-servidor. Muestra la relacin entre los componentes crticos de mayor alcanDesde un punto de vista de gestin ce ignorando detalles de bajo nivel del diseo. Fuente: Kazman et al., CMU/SEIdel proceso de desarrollo, podemos 2004-TR-011, July 2004. identicar dos dimensiones para manejar la arquitectura: descripcin de arquitectura: subconjunto del modelo de Las vistas de casos de uso y diseo son generalmente diseo del software. Incluye elementos signicativos de necesarias en cualquier sistema, mientras que las tres la arquitectura y excluye el diseo de las componentes restantes dependen de la complejidad de su arquitectura. bsicas. Resuelve decisiones sobre qu desarrollar, qu Todas las vistas pueden ser modeladas dinmicamente reutilizar y qu comprar. Contiene notacin ad hoc (textos mediante los diagramas UML de comportamiento, es dey grcos) necesaria para comprender los modelos. Debe cir, los diagramas de secuencia, colaboracin y actividad. incluir tambin los criterios de evaluacin de la arquitec- Como se ha comentado antes, estas decisiones y diagratura. mas deben incluirse, argumentarse y relacionarse en el versin estable de arquitectura: subconjunto suciente documento de descripcin de la arquitectura. A modo de componentes ejecutables que permiten demostrar lo de referencia sobre qu aspectos considerar en la desantes posible que el mtodo de solucin (diseo, tecnolo- cripcin de la arquitectura, la organizacin IEEE dene ga, tiempo y costes estimados) puede resolver satisfac- el estndar IEEE Std 1471-2000 para tales efectos (ver toriamente la denicin del producto (objetivos, alcance, http://standards.ieee.org/reading/ieee/std_public/descriprendimiento, benecios, calidad). tion/se/1471-2000_desc.html). Desde una perspectiva tcnica, como se ha comentado antes, la arquitectura engloba requisitos crticos, decisiones de diseo, componentes de cdigo fuente, y compoBeneficios potenciales del principio nentes ejecutables, informacin que debe ser modelada e de priorizar la arquitectura incluida en el documento de descripcin de arquitectura. Este contexto de informacin puede ser representado a La estrategia de priorizar la arquitectura aporta signicatravs de las siguientes vistas y diagramas UML: vista de casos de uso: describe los casos de uso crticos tivos benecios en materia de correccin al proceso de de la arquitectura; puede ser modelado estticamente a construccin del software, entre ellos: evaluacin de la solucin (diseo + implementacin) travs del diagrama de casos de uso; vista de diseo: describe los componentes del mode- mediante demostraciones tangibles de sus capacidades lo de diseo signicativos para la arquitectura, es decir, desde fases muy tempranas de desarrollo; aquellos que aportan la estructura y funcionalidad bsica atencin temprana a riesgos relacionados con la arquidel sistema; puede ser modelado estticamente mediante tectura que, generalmente, coinciden con aquellos que pueden conducir a mayores daos; diagramas de clases y objetos; vista de proceso: describe interacciones en tiempo de propicia la construccin incremental del software (inteejecucin de los componentes de la arquitectura en un gracin temprana) y las correspondientes actividades de entorno distribuido, incluyendo distribucin lgica de pro- vericacin; cesos, hilos de control, comunicacin entre procesos; propicia el desarrollo orientado a demostraciones peripuede ser modelado estticamente a travs del diagrama dicas de productos funcionales; interfaces correctas permiten una cooperacin eciente de distribucin (deployment diagram); vista de componente: describe los componentes del entre diseadores e implementadores. conjunto de implementacin (cdigo fuente) signicativos

Actualidad
Revista del Instituto Tecnolgico de Informtica

Arquitectura del Software: arte y oficio

En las siguientes secciones explicaremos con ms detalle estos benecios. 1. Evaluacin basada en demostracin La razn principal que justica priorizar la arquitectura es demostrar lo ms pronto posible que la solucin (el diseo) es correcta para resolver el objetivo (los requisitos). Como ya se coment, la arquitectura es punto de transicin entre la fase de ingeniera, donde se toman las decisiones ms importantes, y la fase de produccin, donde se aquellas decisiones se traducen en los mayores gastos del proyecto. En la primera intervienen usualmente un mximo de 2 3 personas, quienes idean la solucin y toman las decisiones crticas. En la segunda fase, un equipo de desarrolladores de tamao variable en funcin de la complejidad del proyecto, colabora en la implementacin de la solucin durante un perodo de tiempo mayor. La arquitectura es la materializacin temprana, grosera y de mnimo coste de las decisiones ms importantes. El prototipo ejecutable de arquitectura debe permitir demostrar que la solucin ya es madura, es decir, que tales decisiones son efectivas para resolver los principales casos de uso del software que se va a construir antes de realizar los gastos ingentes asociados a la fase de produccin, en la cual un equipo de desarrolladores implementar e integrar la mayor parte del cdigo durante un perodo de tiempo casi siempre superior al de la fase de ingeniera. La arquitectura debe dar garantas de que la solucin diseada es realizable dentro de las restricciones de tiempo, personal, y presupuestos, o sea, que el proyecto es viable. 2. Atencin a riesgos relacionados con la arquitectura Otro principio esencial de los mtodos actuales de desarrollo de software es la gestin de riesgos relacionados con el proceso de desarrollo o con el producto de software. Este principio signica identicar al inicio del proyecto las dudas e incertidumbres que existen sobre qu hacer o cmo hacerlo, y denir planes para investigarlas y resolverlas. Si la arquitectura constituye los cimientos del software a construir, los riesgos relacionados con esta son lgicamente los ms crticos del proyecto, es decir, aquellos que pueden producir los mayores errores o daos. Centrarse rpidamente en el diseo, implementacin y estabilizacin de un prototipo de arquitectura implica tener que gestionar necesariamente dichos riesgos y resolverlos. As estaremos eliminando las mayores causas potenciales de errores graves. 3. Integracin temprana Un tercer benecio de priorizar la arquitectura es que propicia una estrategia incremental de construccin del software como forma de aplicacin del principio divide y vencers. Una arquitectura estable puede concebirse como una estructura de soporte del software, en la que se puedan ir integrando gradualmente las implementaciones de las diferentes funcionalidades nales. Cada nueva funcionalidad implementada e integrada es probada como unidad y como parte del todo en el que se inserta. Es decir, un nuevo requisito recin implementado puede ser inmediatamente validado desde la perspectiva del usuario en el contexto de la aplicacin en el que se usar nalmente. La integracin temprana permite dosicar los esfuerzos de realizacin de tests de integracin. Al integrar gradualmente cada funcionalidad en un prototipo de arquitectura previamente vericado y validado, la comprobacin de la nueva funcionalidad dentro del prototipo se simplica notablemente por reducirse las fuentes probables de error. Se deber comprobar tambin que se mantiene la correccin de todo el prototipo en su interdependencia con la nueva funcionalidad. 4. Demostraciones peridicas a clientes y usuarios Este procedimiento incremental de construccin garantiza que en cada instante del proceso de construccin del software exista un prototipo funcional validado, aunque parcialmente terminado. As, cada prototipo parcial permitira realizar demostraciones peridicas a clientes/usuarios nales con el propsito de detectar, tan pronto como aparezcan, desviaciones entre lo que estos esperan y el software implementado. Adems, puede planicarse la construccin de forma que se priorice la integracin de aquellas funcionalidades ms tiles a clientes/usuarios, para crear versiones parciales usables por ellos. Esta forma de hacer facilita por tanto la visibilidad del progreso, es decir, el seguimiento y revisin de planes a travs de la evaluacin precisa de los estados parciales del producto. Existen otras dos ventajas adicionales de esta prctica. Por un lado, refuerza la moral del equipo de desarrollo al presenciar avances tangibles y frecuentes. Por otro lado, mejora sensiblemente la satisfaccin y compromiso de clientes/usuarios al apreciar el desarrollo gradual de su producto, al sentirse partcipes del mismo, y al contar desde fechas tempranas con versiones usables, aunque incompletas. 5. Cooperacin eficiente a partir de interfaces de mdulos La interfaz de un mdulo de software se reere a la forma en la que dicho mdulo interacta con el resto del sistema: cmo se identica, cmo se activa, qu datos necesita, y qu resultados devuelve. La especicacin correcta de las interfaces de los mdulos de la arquitectura propicia la cooperacin y el paralelismo en la implementacin de estas partes. El responsable de cada parte observar el resto de las partes como cajas negras disponibles con las que sabr cmo interactuar. En general dichas partes
6

Actualidad

Actualidad
Revista del Instituto Tecnolgico de Informtica

Arquitectura del Software: arte y oficio

podrn desarrollarse en paralelo e integrarse posteriormente. Conclusiones Uno de los principios de las metodologas modernas de desarrollo de software es priorizar la denicin, el diseo, la implementacin y la evaluacin de la arquitectura del software, que es como se conoce al esqueleto de soporte del sistema. La arquitectura implementa los requisitos ms crticos a travs de las estructuras de programa de mayor alcance en el sistema. Por ello la arquitectura encierra los mayores riesgos del desarrollo. La clave del xito y, a su vez, la dicultad del principio de priorizar la arquitectura consiste en denir qu es y qu no es la arquitectura. Sus componentes deben ser los sucientes para garantizar la viabilidad del proyecto y, a su vez, los mnimos que permitan dar tales garantas con el mnimo gasto de tiempo, esfuerzo y recursos en general. Alcanzar una arquitectura estable reporta signicativos benecios al proceso de construccin del software, entre ellos la construccin incremental del software, la evaluacin frecuente mediante demostraciones peridicas, la resolucin de los riesgos ms peligrosos en etapas tempranas, el aumento de la satisfaccin y compromiso de clientes y usuarios, Algunas referencias recomendables para ampliar informacin sobre la arquitectura del software: http://www.sei.cmu.edu/architecture/denitions.html http://www.sei.cmu.edu/publications/documents/04. reports/04tr011.html http://www-306.ibm.com/software/rational/uml/ http://en.wikipedia.org/wiki/Software_architecture http://www.bredemeyer.com/whatis.htm http://www.softwarearchitectureportal.org/WICSA/ el mantener alta la moral del equipo de desarrollo, y una cooperacin ms efectiva entre sus miembros. A efectos prcticos, todo proceso de desarrollo de software, y en particular las metodologas de diseo y construccin, deben denirse a partir del reconocimiento de este protagonismo de la arquitectura dentro del producto de software y dentro del propio proceso.

Autor: Ramn Mollineda Ms informacin: otri@iti.upv.es

INSCRIPCIN ABIERTA

Las II Jornadas sobre Testeo de Software, organizadas por el Instituto Tecnolgico de Informtica, contarn con la participacin de expertos internacionales en el rea de software testing as como con profesionales interesados en debatir y compartir experiencias sobre los cambios que se estn produciendo en la calidad del software. Objetivo: Los benecios que aporta un buen sistema de testeo de software incluyen el cumplimiento de plazos, la disminucin de errores en el desarrollo e implantacin, la reduccin de costes y la mejora en la satisfaccin del cliente. La jornada pretende explicar la importancia y los fundamentos del testeo de software y describir los procesos bsicos que cada compaa moderna de software debe implementar para garantizar cierto nivel de calidad en sus productos de software. Finalmente, la jornada se dirige a la presentacin y explicacin de tcnicas, modelos y metodologas que se pueden utilizar para llevar a cabo un proceso bsico de testeo. Seminario complementario: Con el n de facilitar el aprovechamiento de las jornadas a todos los asistentes, se impartir en forma independiente un seminario previo que tendr por nalidad introducir los conceptos bsicos del testeo. El seminario tendr lugar el da 20 de abril de 16:00 a 20:00, en las instalaciones del ITI (Ciudad Politcnica de la Innovacin, Edif. 8G, UPV - Camino de Vera S/N, Valencia).

II JORNADAS DE TESTEO DE SOFTWARE

Una oportunidad para conocer las nuevas tcnicas, modelos y metodologas que sirven para mejorar la calidad de nuestro software. http://www.iti.upv.es/JTS2005 jts2005@iti.upv.es
21 y 22 de Abril de 2005 Saln de Actos Centro de Desarrollo de Turismo P de la Alameda, 37 Valencia
Colaboran:

10% DESCUENTO PARA INSCRIPCIONES ANTES DEL 4 DE MARZO