El famoso documento de Arquitectura … Conoce lo que debes hacer para hacerlo como un experto.

Al comienzo los desarrollos nos tenian Arquitectura, yo era de los programadores que hacia de todo, disñaba, cofdificaba, probaba, etc. Pero hoy en dia ya esta claro que hay que tener una Arquitectura para cualquier aplicacion, sea movil, web, etc. Que pasa si no lo haces? Bueno creo que tu aplicacion no durara mucho. Pero dentro de toda esta carreta quiero hablar de lo que realmente nos da valor en un 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, con sus depencias y conexiones. No se si te ha pasado pero siempre que voy a hacer una arquitectura pienso y ahora que plantilla utilizo?, No hay un estandar definido pero si hay algunas aproximaciones, entre ellas esta SAD, el cual 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 decision.
Este documento es 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 SAD provea información complementaría al código fuente.
El SAD se basa en el modelo de 4 + 1 vistas planteado por Philippe Kruchten. Este nos habla de 4 vistas principales que quiran en torno a una central que es la vista funcional, que en pocas palabras son los requerimientos… llamense casos de uso, historias de usuario o como quieras llamarlo. Para mi esta vista es la mas importante.
Para no aburrirlos, voy a mencionar brevemente lo que hace cada una de estas vistas lo cual les aseguro les va a servir en sus plantillas
  • Vista de casos de uso o historias de usuario
    • Audiencia: todas las partes interesadas del sistema, incluidos los usuarios finales.
    • Área: describe el conjunto de escenarios y / o casos de uso / o historias de usuario que representan alguna funcionalidad central significativa del sistema. Describe los actores y casos de uso para el sistema, esta vista presenta las necesidades del usuario y se desarrolla más a nivel de diseño para describir flujos y restricciones discretos con más detalle. Este vocabulario de dominio es independiente de cualquier modelo de procesamiento o sintaxis de representación (es decir, XML).
    • Artefactos relacionados: modelo de caso de uso, documentos de caso de uso

 

  • Vista lógica
    • Audiencia: Diseñadores.
    • Área: Requisitos funcionales: describe el modelo de objetos del diseño. También describe las realizaciones de caso de uso más importantes y los requisitos comerciales del sistema.
    • Artefactos relacionados: modelo de diseño

 

  • Vista de datos
    • Audiencia: especialistas en datos, administradores de bases de datos
    • Área: Persistencia: describe los elementos persistentes arquitectónicamente significativos en el modelo de datos, así como la forma en que los datos fluyen a través del sistema.
    • Artefactos relacionados: modelo de datos.

 

  • Vista de implementación
    • Audiencia: administradores de implementación.
    • Área: Topología: describe el mapeo del software en el hardware y muestra los aspectos distribuidos del sistema. Describe las posibles estructuras de implementación, al incluir escenarios de implementación conocidos y anticipados en la arquitectura, permitimos a los implementadores hacer ciertas suposiciones sobre el rendimiento de la red, la interacción del sistema, etc.
    • Artefactos relacionados: modelo de implementación.
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.
Andres Bedoya
Andres Bedoya

Deja un comentario


*