Documentación de Arquitectura

En entregas previas de esta sección, nos hemos enfocado en aspectos relativos a los requerimientos que influyen a la arquitectura, y a la manera de diseñar la arquitectura con el fin de satisfacer estos requerimientos. Para ser útil, este diseño necesita ser comunicado de forma adecuada. Así que en esta ocasión abordamos aspectos de comunicación del diseño y más particularmente en la actividad de documentación de la arquitectura.

La documentación del diseño de la arquitectura de software cumple varios propósitos importantes. Entre ellos están:

• Comunicar a los distintos involucrados el diseño y las decisiones que permitieron llegar a éste.

• Permitir realizar análisis y evaluación del diseño.

• Soportar las actividades de mantenimiento.

¿Cómo se documenta el diseño arquitectural? Para contestar esto, primero recordemos que hemos definido la arquitectura de software como un conjunto de estructuras compuestas por elementos con propiedades y relaciones entre ellos. Entonces, para documentar un diseño arquitectural requerimos poder representar estas distintas estructuras. De manera similar a lo que se hace en la construcción, en donde se tienen distintos planos para un mismo edificio, las estructuras del diseño arquitectural se documentan de forma separada a través de distintas vistas. Cada vista modela una parte del diseño arquitectural desde distintas perspectivas que pueden ser por ejemplo dinámicas, lógicas o físicas.

El concepto de vista

La documentación de una vista normalmente incluye una representación gráfica (es decir un diagrama) de la estructura que se está modelando. Aunque existe libertad con respecto a la notación usada, lo más común y conveniente es usar UML. Contar con diagramas que representan una estructura indispensable, pero generalmente no es suficiente para poder comunicar el diseño de forma adecuada. Así que al documentar una vista, conviene acompañar al diagrama de información adicional donde se expliquen decisiones de diseño, además de brindar mayor detalle sobre los elementos mostrados en el diagrama y las relaciones entre estos.

Cabe señalar además que puede ser necesario dividir el diagrama si la estructura es muy compleja. En ese caso, cada parte de la estructura se documenta como una vista individual y se incluye un diagrama de contexto que permite comprender la ubicación de la estructura dentro del sistema completo.

Enfoques de documentación

Es conveniente usar un enfoque preestablecido que sirve de guía en la elección y organización de las vistas. Estos son algunos enfoques populares:

4+1 Views. El enfoque (o modelo) 4+1 vistas es muy popular, particularmente porque está asociado al proceso de desarrollo RUP. Este modelo propone que se usen 5 vistas:

• Vista lógica. Modela elementos que soportan la funcionalidad que el sistema provee al usuario final de un punto de vista estático o dinámico mediante diagramas tales como clases, paquetes y secuencia.

• Vista de proceso. Esta vista opcional modela los aspectos dinámicos del sistema y captura aspectos tales como concurrencia y sincronización mediante diagramas tales como el de actividades.

• Vista de desarrollo. Modela la organización estática del software en su ambiente de desarrollo, típicamente mediante diagramas de componentes.

• Vista física. Modela el mapeo del software con el hardware, típicamente con diagramas de implantación.

• Vista de casos de uso. Esta es la vista adicional (+1) que es central al modelo y que agrupa escenarios de casos de uso principales. Para su representación se puede usar un diagrama de casos de uso acompañado de descripciones textuales de los escenarios. Las otras vistas deben permitir comprender la manera en que los escenarios de casos de uso son soportados por la arquitectura.

IEEE 1471. Es un estándar de la IEEE para la descripción arquitectural de sistemas intensivos de software. IEEE 1471 define un marco conceptual que relaciona los conceptos de sistema, descripción arquitectural y vista. En éste marco, las vistas se deben ajustar a un viewpoint (punto de vista), el cual especifica las convenciones para construir y usar una vista, e incluye elementos tales como los lenguajes que pueden ser usados para describir la vista así como los métodos de modelado y las técnicas de análisis que pueden ser aplicados a las representaciones de la vista. En IEEE 1471, una descripción arquitectural incluye uno o más viewpoints, los cuales se seleccionan con base en los involucrados hacia los cuales está dirigida la arquitectura.

Views and Beyond. Este enfoque, desarrollado por el SEI, establece que la documentación de una arquitectura de software involucra la elección de las vistas relevantes de la arquitectura, la documentación de cada una de esas vistas, así como la documentación de la información que aplica a más de una vista o a un conjunto de vistas en su totalidad. Los detalles del enfoque incluyen el método para elegir las vistas más relevantes para los involucrados de la arquitectura, plantillas estándar para documentar las vistas, información necesaria para documentar información que aplica a través de varias vistas, así como definiciones del contenido de las plantillas. A diferencia del enfoque 4+1 vistas, Views and Beyond no especifica el número de vistas a usar.

Ejemplo

Apliquemos el modelo 4+1 vistas al ejemplo que hemos venido desarrollando en artículos anteriores de esta sección. Recordando, el ejemplo hacía referencia a la “compañía xyz que se dedica a la comercialización de productos de diversos fabricantes”.

Vista de casos de uso. La vista de casos de uso incluiría un diagrama con los casos de uso primarios junto con descripciones de estos escenarios. Uno de los escenarios que debería incluir esta vista es el flujo principal del caso de uso primario “Realizar consultas del catálogo de productos”.

Vista lógica. La vista lógica (ver Figura 1) presenta los módulos para llevar a cabo las consultas al catálogo de productos, como son “consulta de productos” y “administrador de búsquedas”, además de los módulos necesarios para comprar productos específicos como son “carro de compras”, “pagos” y “administrador de compras”. Cabe señalar que el diagrama presentado muestra un segundo nivel de descomposición del sistema. Un tercer nivel de descomposición requeriría tomar los diferentes módulos y descomponerlos en componentes asociados a las tecnologías específicas utilizadas en el sistema. De un punto de vista dinámico, la realización del caso de uso “Realizar consultas del catálogo de productos” se aprecia en la Figura 2. Esta representación supone que se ha realizado una descomposición del sistema, de la cual surgieron los componentes especificados en el diagrama de secuencia, y supone además que se eligieron las tecnologías JSF para la capa de presentación y Spring Webservices para la capa de integración.

Vista física. La vista física muestra mediante un diagrama de implantación (deployment) de UML, la terminal por medio de la cual se va a utilizar el sistema, el servidor de aplicaciones en el que van a estar instaladas las capas de la aplicación: vista, negocio e integración, y sistemas en servidores externos a través de los cuales nuestro sistema va a obtener información.

Otras vistas. De forma similar sería necesario incluir la vista de desarrollo. La vista de proceso no es necesaria en éste ejemplo debido a que el sistema no requiere representar elementos de concurrencia o sincronización.

Conclusión

La documentación de la arquitectura es una actividad fundamental para poder realizar una comunicación adecuada del diseño. Es importante recalcar que no existen criterios precisos que permitan determinar el grado exacto de documentación que se debe realizar, y esto se debe determinar considerando diversos aspectos que incluyen a los involucrados, el tipo de proyecto y la experiencia del equipo de desarrollo.

Figura 1. Diagrama de paquetes asociado al caso de uso de consulta de catálogo de productos.

Figura 2. Diagrama de secuencia asociado al caso de uso de consulta de catálogo de producto.

Figura 3. Figura 3. Diagrama de implantación general al sistema.

.BIO

El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Ha realizado investigación en temas relacionados con arquitectura de software desde el año 2000 y en años recientes se ha enfocado en el estudio y la aplicación de métodos que apoyen al desarrollo de arquitectura de software dentro de la industria Mexicana. www.humbertocervantes.net
La MSc. Edith Valencia es arquitecto de software en la empresa QuarkSoft S.C. Cuenta con más de 10 años de experiencia profesional y obtuvo la maestría con honores en Ingeniería de Software en la Universidad de York en El Reino Unido. Sus áreas de interés incluyen arquitecturas de software, ingeniería de procesos de software y metodologías ágiles. evalencia@quarksoft.net

Referencias

[1] Kruchten Philippe, “Architectural Blueprints—The “4+1” View Model of Software Architecture”, IEEE Software 12, 1995
[2] IEEE Computer Society, “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”, IEEE Std 1471-2000, 2000
[3] Clements P. et al. Documenting Software Architectures, Views and Beyond. Addison Wesley, 2003