Documento de Arquitectura

Agenda

- Como documentamos la arquitectura de un sistema- Para que y para quien documentamos- Modelo 4+1- Vista Lógica- Vista de Desarrollo- Vista de Procesos- Vista Física- Vista de Escenarios- Conclusión

Documento de Arquitectura

Si nos pidieran documentar la arquitectura del último sistema en que hemos participado, que haríamos?

Ejemplo 1:

El sistema tendría una Arquitectura Web basada en plataforma Microsoft, o sea, un cliente usando un InternetExplorer 6.0, un servidor corriendo IIS y los componentes de sistema desarrollados en ASP.NET accediendo a otro servidor que contendría los datos dentro de un SQL Server 2008

Muchas veces nos encontramos con diagramas como los mostrados a continuación:

Ejemplo 2:

Ejemplo 3:

Ejemplo 4:

Ejemplo 5:

Ejemplo 6:

Sin embargo lo primero que tenemos que preguntarnos cuando escribimos un documento es a quien esta dirigido. Entonces, a quien esta dirigido un Documento de Arquitectura?

En realidad existen muchos interesados o stakeholders de un documento de arquitectura, e incluso estos pueden tener distintos intereses y conocimientos. Dentro de un equipo de trabajo podemos encontrar: analistas, desarolladores, testers, lideres de proyectos, arquitectos, clientes, gente de infraestructura, de despliegue, usuarios, administradores de bases de datos, etc. Entonces como escribir un único documento o diagrama que pueda explicar la arquitectura propuesta para resolver cierto problema?

Modelo 4 + 1

Es muy complejo capturar la arquitectura de software en un sólo modelo (o diagrama). Para manejar esta complejidad se representan diferentes aspectos y características de la arquitectura en múltiples vistas. Una vista es “una presentación de un modelo, la cual es una descripción completa de un sistema desde una particular perspectiva” (Kruchten, 1995). El modelo más aceptado a la hora de establecer las vistas necesarias para describir una arquitectura software es el modelo 4+1 (Kruchten, 1995).

Modelo 4 + 1Este modelo define 4 vistas principlaes: Vista Lógica (Logical View), modelo de objetos, clases, entidad – relación, etc.

Vista de Proceso (Process View), modelo de concurrencia y sincronización.

Vista de Desarrollo (Development View), organización estática del software en su entorno de desarrollo (librerías, componentes, .ear, .jar, dll, etc.).

Vista Física (Physical View), modelo de correspondencia software - hardware (aspectos de distribución en máquinas, por ejemplo)

En esta vista se habla principalmente de los requerimientos funcionales del sistema y de lo que el sistema debe de hacer, las funciones y servicios que se han definido.

Se enfoca en lo que se ha definido como dominio de la aplicación, clases y objetos principales que forman el corazón o "core" de la aplicación.

Esta vista la vamos a complementar con los diagramas UML:Diagrama de ClasesDiagrama de PaquetesDiagrama de Secuencia

Vista Lógica

En esta vista se va a mostrar principalmente como está dividido el sistema de software en componentes, y muestra las dependencias entre estos componentes.

Los componentes físicos incluyen archivos, componentes compartidos, módulos, ejecutables, etc.También va a mostrar la organización y las dependencias entre el conjunto de componentes, y como se comunican entre ellos.

Esta vista la vamos a complementar con los diagramas UML:Diagrama de ComponentesDiagrama de Paquetes

Vista de Desarrollo

Vista de Procesos

Se tratan algunos requisitos no funcionales. Ejecución, disponibilidad, tolerancia a fallos, integridad, etc. Esta vista también especifica que hilo de control ejecuta cada operación identificada en cada clase identificada en la vista lógica. La vista se centra por tanto en la concurrencia y distribución de procesos.

Esta vista la vamos a complementar con los diagramas UML:Diagrama de Clases (con estereotipos <process>)

Vista Física

En la Vista Física se representa como están distribuidos los componentes entre los distintos equipos que conforman la solución incluyendo los servicios.Los elementos definidos en la vista lógica se mapean a componentes de software o de hardware.

Esta vista la vamos a complementar con los diagramas UML:Diagramas de Despliegue

Vista +1

La Vista +1 o Vista de Escenarios, va a ser representada por los casos de uso, que justamente muestran el propósito del sistema y para la cual existen las otras cuatro vistas.

Esta vista la vamos a complementar con los diagramas UML:- Diagrama de Casos de Uso

Conclusiones- Permite a través de diferentes vistas analizar distintas perspectivas del problema, focalizandose en el problema en cuestión- Concentra en un único documento las principales decisiones tomadas sobre el sistema- Permite a nuevos integrantes del equipo entender la arquitectura del sistema y ubicarse dentro de la solución- Permite discutir con todos los stakeholders las distintas decisiones y validarlas en una etapa temprana