Modelo “4+1”

El modelo “4+1” de Kruchten, es un modelo de vistas [1] diseñado por el profesor Philippe
Kruchten y que encaja con el estándar “IEEE 1471-2000” (Recommended Practice for
Architecture Description of Software-Intensive Systems [5]) que se utiliza para describir la
arquitectura de un sistema software intensivo basado en el uso de múltiples puntos de vista.
Lo primero es saber que es eso de “un sistema software”, el cual lo definimos con la
siguiente “ecuación”
Sistema software = Hardware + Software
Otra cosa de la que habla este modelo de Kruchten es sobre los conceptos de vista y puntos
de vista, pues bien una vista no es mas que una representación de todo el sistema software
desde una determinada perspectiva, y un punto de vista se define como un conjunto de
reglas (o normas) para realizar y entender las vistas.

Si un arquitecto nos muestra un plano de una casa (como la de la siguiente imagen), nos
esta mostrando una vista de la casa y como no tenemos ni idea de arquitectura, cuando nos
explique o nos de un documento en el que explique que un determinado símbolo del plano
representa a una puerta u otro símbolo representa una mesa, nos estará dado un punto de
vista para que podamos entender el plano de la casa. Si mas tarde nos mostrase otro plano
(o maqueta) de la casa, nos estaría dando otra vista de la casa y nos tendrá que explicar el
nuevo punto de vista, es decir, que nos tendrá que explicar que significa cada símbolo u
objeto de esa nueva vista.
Lo que propone Kruchten es que un sistema software se ha de documentar y mostrar (tal y
como se propone en el estándar IEEE 1471-2000) con 4 vistas bien diferenciadas y estas 4
vistas se han de relacionar entre sí con una vista más, que es la denominada vista “+1”.
Estas 4 vista las denominó Kruchten como: vista lógica, vista de procesos, vista de
despliegue y vista física y la vista “+1” que tiene la función de relacionar las 4 vistas
citadas, la denominó vista de escenario.
Cada una de estas vistas ha de mostrar toda la arquitectura del sistema software que se esté
documentando, pero cada una de ellas ha de documentarse de forma diferente y ha de
mostrar aspectos diferentes del sistema software. A continuación, pasamos a explicar que
información ha de haber en la documentación de cada una de estas vistas.

Vista Lógica: En esta vista se representa la funcionalidad que el sistema proporcionara a

los usuarios finales. Es decir, se ha de representar lo que el sistema debe hacer, y las
funciones y servicios que ofrece. Para completar la documentación de esta vista se pueden
incluir los diagramas de clases, de comunicación o de secuencia de UML.
Vista de Despliegue: En esta vista se muestra el sistema desde la perspectiva de un
programador y se ocupa de la gestión del software; o en otras palabras, se va a mostrar
como esta dividido el sistema software en componentes y las dependencias que hay entre
esos componentes. Para completar la documentación de esta vista se pueden incluir los
diagramas de componentes y de paquetes de UML.

Vista de Procesos: En esta vista se muestran los procesos que hay en el sistema y la forma
en la que se comunican estos procesos; es decir, se representa desde la perspectiva de
un integrador de sistemas, el flujo de trabajo paso a paso de negocio y operacionales de los
componentes que conforman el sistema. Para completar la documentación de esta vista se
puede incluir el diagrama de actividad de UML.
Vista Física: En esta vista se muestra desde la perspectiva de un ingeniero de
sistemas todos los componentes físicos del sistema así como las conexiones físicas entre
esos componentes que conforman la solución (incluyendo los servicios). Para completar la
documentación de esta vista se puede incluir el diagrama de despliegue de UML.

“+1” Vista de Escenarios: Esta vista va a ser representada por los casos de uso software y
va a tener la función de unir y relacionar las otras 4 vistas, esto quiere decir que desde un
caso de uso podemos ver como se van ligando las otras 4 vistas, con lo que tendremos una
trazabilidad de componentes, clases, equipos, paquetes, etc., para realizar cada caso de uso.
Para completar la documentación de esta vista se pueden incluir el diagramas de casos de
uso de UML.
NOTA MUY IMPORTANTE: Hay que dejar claro que
Kruchten no dice de que manera se ha de documentar cada vista;
sino que es lo que hay que documentar en cada vista, es decir que
cuando se diga que la vista lógica se puede documentar de forma
gráfica con un diagrama de clases de UML, no quiere decir que esa
vista se tenga que documentar con ese diagrama, sino que ese
diagrama (por sus características) puede documentar esa vista.
Kruchten no define en ningún sitio “puntos de vista” para hacer
vistas, solo define la información que ha de tener cada vista. Lo que
pasa que a día de hoy mucho software se hace bajo el paradigma de
la programación orientada a objetos. Y casualmente existe UML
(Lenguaje de Modelado Unificado), que representa vistas con
diagramas que están formados por “símbolos”,

Una vez explicadas las vistas que propone Kruchten y la forma de

documentarlas, se puede apreciar que es un modelo bastante bueno
para documentar la arquitectura de un sistema software “complejo”,
ya que todos los “Stakeholders” (personas interesadas en el
proyecto, desde el usuario del sistema hasta el “manda más” de la
empresa) pueden entender el sistema software que se esté
desarrollando desde diferentes perspectivas.
Para terminar, solo recomendar la utilización de este modelo “4+1”
vistas de Kruchten para la documentación de arquitecturas de
sistemas software siguiendo el estándar “IEEE 1471-2000”.

Bibliografía
[1] Articulo de Philippe Kruchtens “Architectual Blueprints – the “4+1” View Model of
Software Architecture”: http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-
architecture.pdf
[2] Wikipedia: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
[3] “Software Engineering: Principles and Practice”, 3rd Edición de Hans van Vlient. May
2008.
[4] http://www.notei.com.mx/index.php?id=81
[5] http://standards.ieee.org/findstds/standard/1471-2000.html