Como documentar la arquitectura de software

Sbado 01 de Noviembre de 2008 08:45 Escrito por Diego Gomez

Por lo general, se entiende por documentar software como solo hacer el Diagrama de Clases en el diseo. Por supuesto que documentar la arquitectura de software no es solo eso, y muchas veces los arquitectos no documentan los proyectos y no acompaan a los desarrolladores en el proceso de documentacin. Por lo que v hasta el momento, los arquitectos no se involucran de la forma adecuada en cada proyecto y solo definen de vez en cuando algo de la arquitectura general y luego se dedican a otras cosas... Empecemos con la definicin terica de IEEE en su clsica gua de recomendaciones IEEE 1471 (y tambin se encuentra en el libro "Software Architecture in Practice, 2nd Edition"): "La arquitectura de un sistema de software es la estructura o estructuras del sistema, que incluye elementos de software, las propiedades externamente visibles de esos estamos elementos en y la lo relacin entre ellos." :-). Evidentemente, esta definicin debe ser detallada, porque de lo contrario mismo Cuando hablamos de estructuras estamos hablando de estructuras estticas y dinmicas. Las estructuras dinmicas definen la forma en que el sistema funciona en tiempo de ejecucin, entonces slo un diagrama de clases no resolvera ese punto. Cuando hablamos de propiedades externamente visibles estamos hablando de las interacciones de un elemento o un sistema con su entorno exterior. Puede ser el flujo de informacin de entrada y de salida,

la forma en que el elemento responde a los estmulos externos y el contrato (la interfaz) de dicho elemento. Otra definicin importante, que encontramos en el excelente libro "SSoftware Systems Architecture: Working with stakeholders using viewpoints and perspectives" es que la arquitectura de software debe ser dirigida por las necesidades de las personas que participan en el proyecto: clientes, usuarios, el departamento de IT, soporte, produccin, operacin, etc. La arquitectura de software no puede ser pensada sin el contexto de los stakeholders. Esto puede parecer obvio, pero muchos sistemas por all se realizan sin la debida atencin a las necesidades de las personas involucradas. He visto un montn de gente escoger una arquitectura por ser la ola del momento, sin preguntarse profundamente si aquello satisface las necesidades del negocio. En resumen: Las arquitecturas debe ser creadas slo para satisfacer las necesidades de los stakeholders. Una buena arquitectura es aquella que cumple con xito los objetivos y las necesidades de sus stakeholders. Otra interesante definicin, procedente de RUP, es que la arquitectura de software es un conjunto de decisiones cruciales que restringen las consideraciones de diseo y programacin y que tienen un alto impacto para ser revertidas. Por ejemplo, si se determina que el sistema se har en JEE utilizando Struts 2, entonces los desarrolladores no pueden desarrollar el sistema utilizando la Spring MVC. Por otra parte, el cambio de Struts 2 a Spring MVC, por ejemplo, traera un alto impacto para la capa WEB de la aplicacin. Por otra parte, es el papel del arquitecto explicar los motivos detrs de la eleccin de determinados elementos arquitectnicos en detrimento de los dems. Tambin la realizacin de anlisis "buy vs. build", es decir, comprar o utilizar un componente de cdigo abierto en lugar de construirlo desde cero. O construir algo desde cero considerando que en el mercado existe ya algo listo para su uso.

El arquitecto tambin debe hacer hincapi y centrarse en los atributos de calidad del sistema, los llamados requisitos no funcionales. Debe verificar las necesidades de los stakeholders con respecto al rendimiento, escalabilidad, mantenimiento, seguridad, internacionalizacin, entre otros. Para tener una idea de las diferentes "reas" las cuales un arquitecto debe hacer frente, podemos volver al libro "Software Systems Architecture". El principio inicial definido por los autores es que "no se puede capturar las necesidades funcionales y las propiedades de calidad de un sistema complejo en un solo modelo comprensible". A partir de ah es que surge la necesidad de lo que ellos llaman Visiones y Perspectivas. RUP posee el 4+1 View Model. El IEEE establece un poco ms. Algunos de estos puntos de vista: Informativo, Concurrencia, Desarrollo, Despliegue, Operativo y Funcional. Ya algunas de las perspectivas importantes son: Seguridad, Rendimiento y Escalabilidad, Disponibilidad y Resiliencia, Evolucin, Accesibilidad, Internacionalizacin, Localizacin, Reglamentacin y Usabilidad. Ahora puede surgir una duda que es comn: debemos documentar estas cosas? Donde las documentamos? Por supuesto, no hay una respuesta genrica. Como todo en la Ingeniera del Software ... depende! Un sistema super simple no necesita ninguna documentacin. Un sistema super complejo (como un satlite o un Boeing) tendr una ms amplia documentacin. Sin embargo, para los casos que estamos ms acostumbrados a trabajar (sistemas y aplicaciones empresariales y corporativas) se recomienda tener al menos un "documento de arquitectura de software". No precisae ser un documento de Word en s. Puede ser una pgina de Wiki, una hoja A4, una cartulina, etc. Recomiendo que este documento sea breve y que tenga solamente la informacin esencial, tal como:

Elementos y los principales componentes del sistema. Capas del sistema. Mecanismos arquitecturales necesarios para el sistema. Tecnologas elegidas para hacer frente a cada capa y el Componentes comprados o de cdigo abierto que se Descripcin de los principales patrones de diseo utilizados y Definicin de la forma en que el acceso a sistemas externos

mecanismo y la motivacin detrs de estas opciones.

utilizarn y la forma en que se tom la decisin.

por qu la eleccin.

y / o legados. Adems, algunos equipos pueden sentir la necesidad de desarrollar diagramas UML. Estos diagramas relacionados con la arquitectura y el diseo estarn en el modelo de diseo (si usted usa RUP en el proceso de desarrollo). El equipo puede utilizar los diagramas de clase, actividad, secuencia, estados, componentes y despliegue para facilitar la comprensin visual de los elementos y sus relaciones (conforme la definicin de arquitectura de software por la IEEE). Reforzando y recordando siempre que las actividades relacionadas a la arquitectura se hacen de manera iterativa e incremental. Por lo tanto, cuidado de no caer en el modelo en cascada y estar durante largos perodos de tiempo tan slo escribiendo el documento de la arquitectura. Un buen y verdadero arquitecto es aquel que pone las manos en la masa y prueba con cdigo y con test que su arquitectura realmente va a satisfacer las necesidades de los stakeholders!!! Adems, el arquitecto debe ser una persona sociable e ir detrs de los stakeholders para validar sus decisiones arquitectnicas ms importantes. Bueno, esto es slo una punta de introduccin sobre la cuestin. Si alguien tiene ms preguntas puede dejar un comentario en este artculo!