--- title: Modelo “4+1” vistas de Kruchten (para Dummies) url: https://jarroba.com/modelo-41-vistas-de-kruchten-para-dummies/ author: Richard [Admin Jarroba] date: 2012-03-31 modified: 2026-10-23 language: es license: CC BY-NC-SA 3.0 (https://creativecommons.org/licenses/by-nc-sa/3.0/) — attribution: "Modelo “4+1” vistas de Kruchten (para Dummies)", Richard [Admin Jarroba], jarroba.com categories: Ingeniería del Software --- # Modelo “4+1” vistas de Kruchten (para Dummies) > El modelo de vistas «4+1» de Kruchten, acorde al estándar IEEE 1471-2000, describe la arquitectura de un sistema software desde varios puntos de vista. El modelo “4+1” de Kruchten, es un modelo de vistas [1] diseñado por el profesor [Philippe Kruchten](http://philippe.kruchten.com/) 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. ![Retrato del profesor Philippe Kruchten, autor del modelo de vistas 4+1](https://jarroba.com/wp-content/uploads/2012/03/Kruchten-Jarroba.com_.png) ###### Foto de Philippe Kruchten Vale, si por ahora no te has enterado de nada y no estás en 3 o 4 de carrera de Ingeniería del Software (o derivados) no te preocupes es normal, y si estás en 3 o 4 de carrera y aun así no te has enterado de nada, ¡Ponte las pilas YA! Porque estas cosas te deberían (por lo menos) sonar. Bueno, vamos por pasos. Antes de entrar a explicar más en detalle el modelo de kruchten vamos a explicar e intentar dejar claro algunos conceptos como por ejemplo qué es un sistema software, qué es una vista y qué es un punto de vista. Lo primero es saber que es eso de “**un sistema software**”, el cual lo definimos con la siguiente “ecuación” (made in jarroba.com). #### Sistema software = Hardware + Software Efectivamente, a grandes rasgos un sistema software es un software (más o menos complejo) que “corre” en un determinado hardware (más o menos complejo). Por ejemplo, todo el rollo de los “cajeros automáticos” es un sistema software ya que en un “hardware” que llamamos “cajero”, se ejecuta algún tipo de programa (software) el cual nos permite realizar determinadas gestiones. 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. Bien, si no te ha quedado muy claro qué es esto de las vistas y los puntos de vista, vamos a explicarlo con una sencilla analogía del mundo de la arquitectura (de la arquitectura de las casas, edificios y esas cosas): 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 dé 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. ![Plano de una casa con salón comedor, baño, alcobas y cocina, con medidas, como ejemplo de una vista de arquitectura](https://jarroba.com/wp-content/uploads/2012/03/planoJarroba.com_.jpg) Bueno pues vistos los conceptos de lo que son las vistas y los puntos de vista, y habiendo explicado qué es un sistema software, uno ya se puede hacer a la idea de qué va el modelo “4+1” vistas de Kruchten para la descripción de arquitecturas de sistemas software ¿NO?. Pues sí, 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 vistas 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 qué información ha de haber en la documentación de cada una de estas vistas. [![Diagrama del modelo 4+1 de Kruchten: vistas lógica, de despliegue, de procesos y física, con la de escenarios en el centro](https://jarroba.com/wp-content/uploads/2012/03/Kruchten.png)](https://jarroba.com/wp-content/uploads/2012/03/Kruchten.png) **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. [![Diagrama 4+1 con la Vista Lógica resaltada: usuario final, funcionalidad y diagramas de clases, comunicación y secuencia](https://jarroba.com/wp-content/uploads/2012/03/logica.png)](https://jarroba.com/wp-content/uploads/2012/03/logica.png) **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 cómo está 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. [![Diagrama 4+1 con la Vista de Despliegue resaltada: programadores, gestión del software, diagramas de componentes y paquetes](https://jarroba.com/wp-content/uploads/2012/03/Despliegue.png)](https://jarroba.com/wp-content/uploads/2012/03/Despliegue.png) **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. [![Diagrama 4+1 con la Vista de Procesos resaltada: integradores, rendimiento y escalabilidad, diagrama de actividad](https://jarroba.com/wp-content/uploads/2012/03/Procesos.png)](https://jarroba.com/wp-content/uploads/2012/03/Procesos.png) **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. [![Diagrama 4+1 con la Vista Física resaltada: ingenieros de sistemas, topología del sistema, diagrama de despliegue](https://jarroba.com/wp-content/uploads/2012/03/fisica.png)](https://jarroba.com/wp-content/uploads/2012/03/fisica.png) **“+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 cómo 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 los diagramas de casos de uso de UML. [![Diagrama 4+1 con la Vista de Escenarios (+1) resaltada en el centro, asociada al diagrama de casos de uso](https://jarroba.com/wp-content/uploads/2012/03/+1.png)](https://jarroba.com/wp-content/uploads/2012/03/+1.png) Nota **NOTA MUY IMPORTANTE:** Hay que dejar claro que Kruchten **no dice de que manera se ha de documentar cada vista**; sino qué 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 info 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 una cosa que se llama UML (Lenguaje de Modelado Unificado), que mira tú por donde, representa vistas con diagramas que están formados por “símbolos”, que pertenecen a un LENGUAJE llamado UML (UML es un Lenguaje no una metodología) que conoce (o ha de conocer) todo ingeniero software. Y eso qué quiere decir, pues que un diagrama es una vista, con un punto de vista que ya está muy bien definido en UML. ¡¡A qué ahora las cosas empiezan a cuadrar!!. Pues eso, que con UML nos ahorramos el tener que documentar los puntos de vista al estar ya documentadas. Y otra cosa también muy importante, es que **cada uno puede representar las vistas “como le dé la gana” siempre y cuando estén reflejadas en el punto de vista** como ocurrirá en muchos casos en la vista física. 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] Artículo de Philippe Kruchtens “*Architectual Blueprints – the “4+1” View Model of Software Architecture*”: [Architectural 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](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](http://www.notei.com.mx/index.php?id=81) [5] [IEEE 1471-2000 — IEEE Recommended Practice for Architectural Description for Software-Intensive Systems (IEEE SA)](http://standards.ieee.org/findstds/standard/1471-2000.html)