Vistas y puntos de vista: ISO/IEC/IEEE 42010, 4+1 y Rozanski y Woods

Un sistema, muchas vistas

Ningún diagrama por sí solo puede describir un sistema real. Un dibujo que muestra cómo se divide en módulos el código de la plataforma de reparto de comida no dice nada sobre en qué servidores se ejecutan; un dibujo de servidores y redes no dice nada sobre lo que ocurre, paso a paso, cuando un repartidor acepta un encargo. Si intentas poner todo esto en una sola página, obtienes el conocido póster de arquitectura: decenas de cajas, líneas que significan seis cosas distintas y nadie capaz de responder a una pregunta precisa a partir de él.

La idea que resuelve esto es antigua y sencilla. Describe el sistema mediante varias vistas, cada una de las cuales muestra un conjunto de estructuras para un conjunto de inquietudes, igual que un edificio se describe con un plano de planta, un alzado, un plano eléctrico y un plano de fontanería. Cada una es una descripción parcial; juntas describen el todo. Esta idea sustenta la norma internacional, el modelo 4+1 de Kruchten, el catálogo de puntos de vista de Rozanski y Woods, el enfoque Views and Beyond del SEI y, de forma ligera, el modelo C4 de la sección siguiente. Esta sección explica el vocabulario que comparten y cómo elegir las vistas que necesita un sistema concreto.

Recuerda de la Sección 1.5 que una parte interesada es cualquiera que tenga un interés en el sistema y que una inquietud es cualquier asunto importante para una parte interesada. Las vistas existen para responder a inquietudes. Una vista que no responde a la inquietud de nadie es decoración.

El modelo conceptual de ISO/IEC/IEEE 42010:2022

ISO/IEC/IEEE 42010 es la norma internacional para la descripción de arquitectura. Su edición actual se publicó en 2022 y sustituyó a la edición de 2011. No te dice cómo diseñar, qué notación usar ni qué vistas dibujar; define los conceptos que debe contener una descripción de arquitectura y cómo se relacionan, para que las descripciones producidas con métodos distintos puedan compararse y comprobarse. Su modelo conceptual es el esqueleto común de casi todos los enfoques de documentación de este capítulo.

El modelo parte de la entidad de interés: aquello cuya arquitectura se describe, que puede ser un sistema de software, un sistema de sistemas, una línea de productos o una empresa (la edición de 2011 lo llamaba sistema de interés). La entidad tiene una arquitectura, y una descripción de arquitectura la expresa. Dentro de la descripción, las partes interesadas tienen inquietudes. Un punto de vista es una especificación reutilizable de convenciones para construir y usar un tipo de vista: nombra las inquietudes que enmarca, las partes interesadas típicas y los tipos de modelo (notaciones y convenciones de modelado) que deben usarse. Una vista aplica un punto de vista a una entidad concreta: aborda esas inquietudes para este sistema y está formada por componentes de vista, como diagramas, tablas y modelos, cada uno regido por un tipo de modelo (la edición de 2011 llamaba a los componentes de vista modelos de arquitectura).

En la práctica importan otros dos elementos. Las correspondencias registran relaciones entre elementos de la descripción, sobre todo, y es lo más útil, entre vistas: este contenedor de la vista de contenedores se ejecuta en aquel clúster de la vista de despliegue; este requisito lo aborda aquella decisión. Y las decisiones de arquitectura y su justificación forman parte de la descripción, vinculadas a las inquietudes que abordan. La edición de 2022 también define con más detalle dos conceptos que la edición de 2011 ya mencionaba, las perspectivas de las partes interesadas (formas de agrupar inquietudes) y los aspectos de arquitectura (características de la entidad que atraviesan las vistas), cambia el nombre de "marco de arquitectura" por el de marco de descripción de arquitectura y define lo que deben contener los marcos de descripción de arquitectura conformes, como la plantilla de documentación propia de una empresa.

El modelo de vistas 4+1 de Kruchten

Philippe Kruchten, entonces en Rational Software, publicó Architectural Blueprints: The "4+1" View Model of Software Architecture en IEEE Software en noviembre de 1995. El modelo de vistas 4+1 fue el primer enfoque multivista ampliamente adoptado y pasó a formar parte del Rational Unified Process. El argumento de Kruchten era que los diagramas únicos de la época intentaban captar demasiado a la vez, y que las distintas partes interesadas (usuarios finales, desarrolladores, ingenieros de sistemas, jefes de proyecto) necesitan vistas distintas.

Las cuatro vistas son estas. La vista lógica describe la funcionalidad que el sistema proporciona a los usuarios finales, normalmente como las abstracciones clave y sus relaciones (en UML, diagramas de clases y de estados). La vista de procesos aborda las inquietudes de tiempo de ejecución: procesos e hilos, concurrencia, distribución, rendimiento, escalabilidad y tolerancia a fallos. La vista de desarrollo (también llamada vista de implementación) describe la organización del software en su entorno de desarrollo: módulos, subsistemas, capas y sus dependencias, que importan a los programadores y a los directivos que planifican el trabajo. La vista física (o vista de despliegue) asigna el software al hardware y a las redes. El "+1" son los escenarios: un pequeño conjunto de casos de uso importantes, cada uno recorrido a través de las cuatro vistas, que ilustran la arquitectura y a la vez validan que las vistas encajan entre sí.

Los escenarios son la parte que más se olvida y, posiblemente, la más valiosa. Una vista aislada puede parecer ordenada mientras oculta una laguna; recorrer un escenario real, como "el cliente hace un pedido", a través de las vistas lógica, de procesos, de desarrollo y física pone al descubierto elementos que faltan y supuestos incoherentes. La misma idea reaparece en la vista de tiempo de ejecución de arc42, en los diagramas dinámicos de C4 y, en la Sección 4.8, en el consejo de explicar un sistema siguiendo una solicitud.

Rozanski y Woods: puntos de vista y perspectivas

Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, de Nick Rozanski y Eóin Woods (2.ª edición, Addison-Wesley, 2012), ofrece un catálogo de siete puntos de vista orientado a grandes sistemas de información, junto con una segunda idea complementaria: las perspectivas.

Sus siete puntos de vista son: contexto (las relaciones del sistema con las personas, los sistemas y las entidades externas que lo rodean), funcional (los elementos funcionales de tiempo de ejecución, sus responsabilidades, interfaces e interacciones principales), información (cómo se almacenan, gestionan, poseen y distribuyen los datos), concurrencia (qué partes se ejecutan de forma concurrente y cómo se coordinan), desarrollo (lo que necesitan los desarrolladores, los testers y quienes compilan: la estructura de módulos, el procesamiento común, los estándares y la organización de las líneas de código), despliegue (el entorno de ejecución y cómo se asigna el software a él) y operacional (cómo se instala, se migra, se administra, se monitoriza y se da soporte al sistema en producción).

Una perspectiva es el nombre que dan a una inquietud de calidad que atraviesa todas las vistas, como la seguridad, el rendimiento y la escalabilidad, la disponibilidad y la resiliencia, o la evolución (su catálogo también incluye la accesibilidad, los recursos de desarrollo, la internacionalización, la ubicación, la regulación y la usabilidad). Una perspectiva no es otra vista que dibujar. Es un conjunto de preguntas, tácticas y comprobaciones que se aplican a todas las vistas: para la seguridad, examinas la vista de contexto en busca de actores externos y límites de confianza, la vista de información en busca de datos sensibles, la vista de despliegue en busca de zonas de red, y así sucesivamente. Esto capta algo que las vistas por separado no pueden: las cualidades surgen del sistema en su conjunto, así que hay que comprobarlas en todas partes (compara con los modelos de calidad del Capítulo 2).

El punto de vista operacional merece especial atención porque muchos enfoques lo infravaloran. Quién instala el sistema, cómo se migran los datos desde el antiguo, cómo se gestiona la configuración, qué monitorizan los operadores y cómo se les alerta: son preguntas arquitectónicas cuyas respuestas dan forma al sistema, y dejarlas para justo antes de la puesta en producción es una causa clásica de lanzamientos fallidos.

Las tres categorías del SEI: módulos, componentes y conectores, asignación

El Capítulo 1 presentó la agrupación de las estructuras del SEI en tres tipos (consulta la Sección 1.1). Documenting Software Architectures: Views and Beyond usa la misma agrupación para organizar las vistas, y es la forma más útil de comprobar que un conjunto de vistas está completo.

Las vistas de módulos muestran unidades de implementación (paquetes, bibliotecas, espacios de nombres) y relaciones como es parte de, depende de y es un. Los estilos típicos son las vistas de descomposición, de usos, de generalización, de capas y de modelo de datos. Las vistas de componentes y conectores (C&C) muestran los elementos presentes en tiempo de ejecución (servicios, clientes, bases de datos, colas) y los conectores mediante los que interactúan (llamadas HTTP, mensajes, datos compartidos); los estilos típicos incluyen cliente-servidor, publicación-suscripción, tuberías y filtros, datos compartidos y multinivel. Las vistas de asignación asignan los elementos de software a cosas que no son software: al hardware y a la infraestructura en la nube (despliegue), al sistema de archivos y a los artefactos de compilación (implementación e instalación) y a los equipos (asignación del trabajo).

Las tres categorías se corresponden de forma natural con los otros enfoques. La vista de desarrollo de Kruchten es una vista de módulos, su vista de procesos una vista C&C y su vista física una vista de asignación. Los puntos de vista funcional y de concurrencia de Rozanski y Woods son principalmente C&C, su punto de vista de desarrollo es de módulos, y sus puntos de vista de despliegue y operacional son de asignación. Los diagramas de contenedores y de componentes de C4 de la sección siguiente son vistas C&C con cierto sabor de módulos, y los diagramas de despliegue de C4 son vistas de asignación. Cuando montes un conjunto de documentación, comprueba que contiene al menos una vista de cada categoría, porque cada una responde a preguntas que las otras no pueden responder.

Relacionar las partes interesadas y las inquietudes con las vistas

La herramienta más práctica de la norma es una tabla sencilla: enumera las partes interesadas y sus principales inquietudes y, después, nombra la vista o las vistas que abordan cada inquietud. Los huecos (una inquietud que ninguna vista aborda) muestran dónde está incompleta la descripción; las vistas que nadie necesita son candidatas a eliminarse. La tabla siguiente es una primera aproximación para la plataforma de reparto de comida.

Elegir el conjunto mínimo de vistas

La tentación, una vez que sabes que existen muchos puntos de vista, es producirlos todos. Resístela. Cada vista tiene que mantenerse coherente con el sistema y con las demás vistas, así que cada una añade un costo de mantenimiento. El objetivo es el conjunto más pequeño de vistas que responda a las inquietudes importantes de las partes interesadas importantes, siguiendo la regla de la Sección 4.1 de escribir para el lector. Views and Beyond describe un procedimiento parecido: construir una tabla de partes interesadas y vistas, combinar vistas cuando un diagrama pueda servir a varias necesidades y, después, priorizar.