martes, 28 de febrero de 2012

Documento de Arquitectura de Software

El Documento de Arquitectura de Software (DAS), más conocido como SAD por sus siglas en inglés, es el documento que abarca absolutamente a todo el sistema. Si bien no hay un estándar definido, habitualmente se organiza por vistas, a través de las cuales pueden especificarse los distintos aspectos técnicos y funcionales, así como también las decisiones involucradas en cada incumbencia.

Se considera como un documento "vivo", que sufrirá modificaciones a lo largo de la construcción del sistema. Esto no significa que el arquitecto o algunos programadores aventajados tengan que sufrir el calvario de mantenerlo todos los días actualizado con el código, sino que se espera que sufra periódicas y tal vez espaciadas iteraciones en las que se publiquen nuevas versiones, con mejoras y hasta con nuevas secciones.

Se espera que el DAS provea información complementaría al código fuente.


Hace poco estuve leyendo esta interesante página en donde se provee una guía muy interesante sobre cómo construir un DAS. Yendo un poco más allá del viejo y querido modelo 4+1 de vistas diseñado por Philippe Kruchten, el artículo organiza, amplía, e incluso yo diría que actualiza, el modelo de vistas con algunas prácticas más modernas. Es cierto que de la experiencia (y sobre todo de las malas) se aprende; el software no es la excepción.


El artículo es muy recomendable. La organización que propone del documento está muy buena y los tips que ofrece para cada vista realmente son muy útiles. A mi parecer, me parece muy acertado que se comience exponiendo el contexto con lo que sería la Vista Funcional al comienzo, vista que en muchos DAS he visto que se expone al final, como si fuera un anexo.

Lo que le agregaría a la página y que me parece que hace falta es una Vista de Desarrollo, ítem que en la plantilla de RUP está bien presente. En la Vista de Desarrollo podría incluirse información relevante para la construcción de la aplicación. Es justamente una vista para desarrolladores: podría mostrar cómo está organizado el código a nivel proyectos, los nombres de los paquetes, en qué paquetes está implementada cada capa, nomenclaturas estándares, guía de programación con lineamientos y buenas prácticas para el lenguaje de programación, los frameworks y las herramientas que se están usando, etc.


Es interesante destacar que, al ser el DAS un documento "vivo" e iterativo, las Vistas pueden ser escritas en distintas fases del proyecto. Por ejemplo, la Vista Lógica incluye diagramas UML que están más cerca del análisis que del diseño. Los diagramas de clases del modelo de dominio pueden representar sólo los elementos más importantes, con los atributos más destacados, y hasta quizá no convenga siquiera especificarles un tipo. La Vista está orientada a comunicar el modelo de dominio y la arquitectura del sistema en fases tempranas del desarrollo. En cambio, la Vista de Diseño está orientado a fases mucho más tardías. Los diagramas UML serán detallados. En un diagrama de clases, todas las clases estarán representadas, con todas sus relaciones, con todos sus atributos y operaciones. Incluso estos diagramas podrían ser auto-generados con herramientas a partir del código fuente. Claramente esta vista sería muy útil para el mantenimiento del software, una vez que éste ya pasó a un ambiente productivo.