Unidad 2:

Modelo 4+1, vistas

de Kruchten y
diagramas UML

Ingeniería de Diseño
 Página 1 de 20

Introducción .................................................................................................... 2
1. Patrones de arquitectura de software ....................................................... 3
2. El Modelo 4+1 Vistas de la Arquitectura de Software................................ 4
2.1 Explicación del modelo 4+1 vistas ........................................................................... 4
2.2 Diagramas UML ............................................................................................................. 5

3. Vista +1 de escenarios ................................................................................. 5

3.1 Diagrama de Casos de Uso ............................................................................................ 5
3.2 Documentando la especificación de casos de uso ....................................................... 6
4. Vista de procesos ...................................................................................... 7
4.1 Diagrama de actividad .................................................................................................. 7
5. Vista Lógica ............................................................................................... 8
5.1 Diagrama de Clases ....................................................................................................... 9
5.2 Diagrama de Secuencia ............................................................................................... 10
6. Vista de desarrollo .................................................................................. 12
6.1 Diagrama de componentes ......................................................................................... 12
6.2 Diagrama de paquetes ................................................................................................ 14
7. Vista física ............................................................................................... 16
7.1 Diagrama de despliegue.............................................................................................. 17
Conclusiones ................................................................................................. 19
Referencias bibliográficas.............................................................................. 20
 Página 2 de 20

Introducción
El Análisis y Diseño Orientado a Objetos (ADOO) es un enfoque de análisis en ingeniería
de software que modela un sistema como un grupo de objetos que interactúan entre sí
(Booch, 2007). Luego de varios enfoques para ADOO, aparece el Lenguaje Unificado de
Modelado (UML) que modela sistemas de software y es ampliamente utilizado. En esta
unidad se desarrollarán diagramas UML para crear una arquitectura de software con
enfoque del modelo 4+1.

El modelo 4+1 es un modelo de vistas (Kruchten, 1995) que encaja con el estándar
ISO/IEC/IEEE 42010: 2011, Ingeniería de sistemas y software - Descripción de la
arquitectura y se utiliza para describir la arquitectura de un sistema de software basado
en el uso de múltiples puntos de vista.

El modelo 4+1 describe la arquitectura de software usando cinco vistas compatibles,

permitiendo a los distintos stakeholders (interesados en el proyecto) encontrar lo que
necesitan saber acerca de esta. Las cinco vistas son:

Vista de Escenarios Presenta los actores y sus casos de uso teniendo un

o Vista +1 enfoque para el usuario final.
Muestra las funciones y servicios del sistema, siendo
Vista Lógica útil para los usuarios finales, clientes, programadores y
especialistas en datos.
Diagrama el comportamiento del sistema en tiempo de
Vista de Procesos ejecución, y tiene una perspectiva del diseñador o
integrador de sistemas.
Se ocupa de la gestión del software y presta servicios al
Vista de Desarrollo
administrador de software y al programador.
Muestra la topología de los componentes físicos del
Vista Física sistema y tiene un enfoque pensado para los
diseñadores o ingenieros de sistemas.

El modelo 4+1 ha sido utilizado con éxito en numerosos proyectos de desarrollo de

software.
 Página 3 de 20

1. Patrones de arquitectura de software

Pensemos, por ejemplo, en las arquitecturas de las iglesias y podremos encontrar
portadas románicas, góticas, renacentistas y barrocas, entre otras. El objetivo de estas
arquitecturas es darle forma a la estructura física que tendrá la construcción. Del mismo
modo, pero aplicado al software, existen modelos para construir las estructuras de un
sistema a ser programado; a dichos modelos les llamaremos arquitectura de software.
PREGUNTA

¿Alguna vez te has preguntado si el software a gran escala se

puede estructurar con planos, como si se tratara del plano de
una casa?

Es muy cierto que los planos de una casa son necesarios para que los cimientos no se
vengan abajo, por ejemplo, por un terremoto. En una casa hay planos para la forma de
esta, el alcantarillado y las conexiones eléctricas, lo que permite que la casa pueda ser
usada correctamente e incluso modificada más adelante.

Un software también necesita planos para ser construido, ya que es la única forma de
poner de acuerdo a los ingenieros que lo fabricarán, garantizar que cumplirá con los
requerimientos del cliente y que funcione correctamente cumpliendo con la calidad
prevista y que pueda ser mantenido en el tiempo. Como los modelos pueden cambiar de
acuerdo a los requerimientos del sistema, necesitaremos basarnos en estilos de
fabricación del software, estilos a los que llamaremos patrones de arquitectura.

Para el desarrollo de software existen variadas arquitecturas, las cuales se escogen en la

medida que se ajusten a lo que el cliente necesita y en conformidad con el entorno
operativo del sistema. Algunos ejemplos de patrones de arquitectura son:

• Cliente/servidor
• Modelo vista controlador
• Arquitectura dirigida por eventos
• Programación por N capas
• Pipeline
• Peer-to-peer (de igual a igual)
• Arquitectura orientada a servicios (SOA - Service Oriented Architecture)
• Microservicios
 Página 4 de 20

2. El Modelo 4+1 Vistas de la Arquitectura de Software

El modelo 4+1 vistas de Kruchten, que llamaremos simplemente 4+1, describe una
arquitectura de software usando 5 vistas que se complementan. El 4+1 es bastante
general y permite a los distintos stakeholders encontrar lo que quieren acerca de la
arquitectura del software. Un stakeholder es una persona interesada en el proyecto, que
puede ser por ejemplo un cliente, programador, gerente, jefe de proyecto, etc.

El objetivo de las vistas es que de acuerdo con el perfil del stakeholder se pueda mostrar
aquellos diagramas UML que este pueda comprender, de forma tal que se logre generar
un diálogo entre técnicos y personas que no necesariamente tienen conocimientos
profundos en informática.

2.1 Explicación del modelo 4+1 vistas

El 4+1 está basado en los diagramas UML, que se verán en detalle en esta asignatura.
Según Kruchten, una buena división basada en vistas se puede visualizar en la siguiente
figura:

Figura 1. Modelo 4+1 de Philippe Kruchten.

Usuario final y programador

Administrador de software y programador
Funcionalidad
Gestión del software
VISTA LÓGICA
VISTA DE DESARROLLO
2. Diagrama de clases
5. Diagrama de componentes
3. Diagrama de comunicación
6. Diagrama de paquetes
4. Diagrama de secuencia

Usuario final
Requerimientos
+1
VISTA DE ESCENARIOS
1. Diagrama de casos de uso

Integrador de sistemas y diseñador Ingenieros de sistemas y diseñador

Rendimiento y escalabilidad Topología del sistema
VISTA DE PROCESOS VISTA FÍSICA
7. Diagrama de actividad 8. Diagrama de despliegue

Fuente: Phillippe Kruchten. (1995). Planos Arquitectónicos: El Modelo de “4+1” Vistas de la Arquitectura del
Software. Artículo publicado en IEEE Software 12(6), noviembre 1995.
 Página 5 de 20

Más adelante, veremos como estas vistas encajan en las perspectivas de los stakeholders
y por qué son útiles los diagramas UML.

2.2 Diagramas UML

El UML, que en inglés significa Unified Modeling Language, es un lenguaje gráfico de
modelado de sistemas de software que es ampliamente usado en la actualidad y que
encaja muy bien con la programación orientada a objetos. UML es mantenido por el
Object Management Group (OMG), quienes le dan el soporte y lo actualizan cuando lo
consideran necesario. El UML está dividido en diagramas estructurales y de
comportamiento, donde este último tiene una subdivisión en diagramas de interacción. El
UML está compuesto por 14 diagramas; sin embargo, el 4+1 considera solo 8 de ellos.

3. Vista +1 de escenarios
La vista de escenarios presenta los actores y una descripción de sus casos de uso
asociados, de modo que contiene los requisitos desarrollados en las restantes vistas. De
igual forma, explica los escenarios de calidad más relevantes para la arquitectura. Los
escenarios describen secuencias de interacciones entre objetos y entre procesos. Se
utilizan para identificar y validar el diseño de arquitectura. Esta vista es especialmente
usada por usuarios finales, ejecutivos, gerentes o jefes de proyecto para explicar
simplificadamente cómo funciona el sistema.

3.1 Diagrama de Casos de Uso

Los casos de uso corresponden a uno de los diagramas UML que permite visualizar los
requerimientos solicitados por el cliente en base a actores y sus relaciones con el sistema.
Los actores, representan a las personas, máquinas o entidades que participan en el
negocio para el cual está siendo diseñado el software.

Un caso de uso (CU) describe una acción o actividad relacionada con un actor y se
dibujan como elipses. Por ejemplo, la acción “Solicitar libro” es realizada por el actor
“Cliente” tal como muestra el diagrama más abajo. Los casos de uso se conectan
mediante líneas que pueden ser de asociación, extensión, inclusión y generalización.
Los conectores pueden tener estereotipos, que mejoran la lectura de la conexión y se
escriben dentro de signos << y >>.
 Página 6 de 20

Las relaciones son: Figura 2. Ejemplo de diagrama de

casos de uso para un sistema de
Incluye (<<include>>): compra/venta de libros.

Es la dependencia de dos CU que denota

que el primer CU, por ejemplo “Solicitar
libro”. Opcionalmente, puede ejecutar el
CU incluido, en este caso los CU: “Solicitar
en tienda” y “Solicitar por Internet”.

Generalización (sin estereotipo):

Indica que un CU puede ser especializado a

partir de una CU base. Por ejemplo
“Procesar cliente normal” es una forma
más detallada de realizar “Procesar
cliente”.

Extiende (<<extend>>):

Declara puntos de extensión donde el CU,

por ejemplo “Procesar cliente” solo se
puede realizar si se ha realizado el CU
“Seleccionar tipo de cliente”.
Fuente. Elaboración propia.

3.2 Documentando la especificación de casos de uso

PREGUNTA

¿Cómo se documenta un caso de uso (CU)?

Los CU se documentan a través de fichas, donde se muestran actores, tipo de casos de

uso (primario, secundario, opcional), referencias, precondiciones y postcondiciones,
descripción y resumen.
 Página 7 de 20

4. Vista de procesos
La vista de procesos muestra los aspectos dinámicos del sistema, que explican sus
procesos y cómo se comunican. Se enfoca en el comportamiento del sistema en tiempo de
ejecución, considerando aspectos de concurrencia, distribución, rendimiento o
desempeño, escalabilidad, flujo de trabajo paso a paso de negocio y operación de los
componentes del sistema. Describe los aspectos de concurrencia y sincronización del
diseño. La vista de procesos tiene una perspectiva del diseñador o integrador de sistemas.
PREGUNTA

¿Has escuchado alguna vez a alguien del mundo laboral

hablar de los procesos?

Un proceso puede ser entendido como un grupo de tareas que forman una unidad
ejecutable. Los procesos pueden ser controlados por acciones como comenzar,
recuperar, reconfigurar, detener, etc.

4.1 Diagrama de actividad

El Diagrama de actividad (DA) de UML está dentro del grupo de diagramas de
comportamiento y muestra el flujo de control o el flujo de objetos visibilizando la
secuencia y las condiciones del flujo. Una acción dentro del sistema se puede iniciar
porque otras terminan de ejecutarse o bien los objetos y datos no están disponibles,
igualmente si suceden eventos externos al flujo.
PREGUNTA

¿Te imaginas la cantidad de símbolos que se necesitan para

describir los procesos y sus relaciones?

La simbología para hacer un DA es tan variada que solo te mostraremos un ejemplo. Por
fortuna los DA son muy intuitivos y esta es la principal característica que permite que
sean usados por cualquier persona, para describir casi cualquier cosa. Mira este ejemplo
de una biblioteca.
 Página 8 de 20

Figura 3. Ejemplo de diagrama de actividad para un sistema de compra/venta de libros.

Fuente: Elaboración propia.

5. Vista Lógica
La vista lógica (VL) representa la funcionalidad que el sistema proporcionará a los usuarios
finales, es decir, lo que el sistema debe hacer, sus funciones y servicios que ofrece.
Muestra la estructura estática del sistema. Es la descomposición del Modelo Orientado a
Objetos (en caso de que este paradigma sea escogido para la implementación del
sistema). Es recomendable complementar esta vista con un Modelo de Datos o Modelo
Entidad-Relación. La VL es útil para usuarios finales y programadores. La VL utiliza los
diagramas de clases, comunicación y secuencia. Los anteriores diagramas están
especialmente pensados para modelar en Orientación a Objetos y para la POO.
 Página 9 de 20

5.1 Diagrama de Clases

El Diagrama de Clases (DC) permite representar las clases y objetos de un sistema, junto
con su estructura interna. El DC describe las clases y las relaciones entre ellas siendo un
diagrama estático que representa los elementos del sistema sin considerar la
temporalidad de sus acciones. Una clase es una estructura funcional que ofrece acciones a
realizar a través de sus métodos (por ejemplo, “BuscarLibro” en una “Biblioteca”) y que
contiene atributos que son características propias de la clase (por ejemplo, los “Libros” de
la Biblioteca). La clase queda implementada en POO al crear una instancia de la clase u
Objeto.

Figura 4. Ejemplo de diagrama de clases para un sistema de compra/venta de libros.

Fuente: Elaboración propia.

 Página 10 de 20

PREGUNTA
¿Cómo te imaginas que las clases pueden relacionarse unas
con otras?

Existen varios tipos de relaciones entre clases. En el DC de Biblioteca podemos encontrar:

Agregación (pues una Biblioteca tiene Libros), Composición (pues la Biblioteca está
compuesta por 1 o más Estantes) y Generalización (donde ClienteNormal y
ClienteSuscrito son clases derivadas de Cliente).

5.2 Diagrama de Secuencia

Un Diagrama de Secuencia (DS) muestra la interacción de objetos en un software a lo
largo del tiempo y se modela para cada CU. El DS es útil para explicar cómo operan los
métodos de las clases, mostrando la secuencia de pasos para cada operación.

Tabla 1. Tipos de Mensajes en el Diagrama de Secuencia

Síncronos Asíncronos
• Corresponden a llamadas de métodos • Terminan inmediatamente.
del objeto que recibe el mensaje. • Crean un nuevo flujo de ejecución
• El objeto que envía el mensaje queda dentro de la secuencia.
bloqueado hasta que termina la • Se representan con flechas con la
llamada. punta hueca.
• Este tipo de mensajes se representan
con flechas con la punta rellena.
Fuente: Elaboración propia.

El siguiente DS explica cómo funciona el método “VenderLibro”, comunicando los objetos

mediante el uso de mensajes, que no son otra cosa que los métodos definidos en sus
clases.
 Página 11 de 20

Figura 5. Ejemplo de diagrama de secuencia para un sistema de compra/venta de libros.

Fuente: Elaboración propia.

5.3 Diagrama de comunicación

El Diagrama de Comunicación (DCO) es un diagrama que muestra las interacciones entre

objetos y/o partes como líneas de vida, mostrando los mensajes secuenciados en una
disposición bastante libre. El DCO es parecido a un DS simplificado que no muestra todos
los procesos al interior de una línea de vida (objeto) como lo hace el DS, por lo que no
necesita mostrar bloques de condiciones o ciclos que si se pueden representar en el DS.

Otro aspecto relevante es que el DCO no pone énfasis en el orden de envío y recepción de
los mensajes (ejecuciones de métodos) por lo que solo interesa modelar el paso de
mensajes entre objetos o los roles que entregan las funcionalidades de casos de uso y
operaciones dentro de un escenario de colaboración.
 Página 12 de 20

PREGUNTA
¿Cómo mostrar simplificadamente las interacciones entre los
objetos?

El DCO puede modelar escenarios alternativos dentro de casos de uso u operaciones que
involucren la colaboración de diferentes objetos e interacciones.
En el siguiente diagrama se muestran las interacciones simplificadas por medio del DCO
del proceso de venta de un libro
Figura 5. Ejemplo de diagrama de comunicación
para un sistema de compra/venta de libros

Fuente: Elaboración propia.

6. Vista de desarrollo
La vista de desarrollo (VD) se ocupa de la gestión del software, enfocándose en la
administración de los artefactos de software, y muestra cómo está dividido el sistema, en
sus componentes y las dependencias que hay entre ellos. En la VD se presentará la
organización de los módulos del software puestos en el entorno de desarrollo. El enfoque
de la VD es de la perspectiva del administrador del software y del programador.

6.1 Diagrama de componentes

 Página 13 de 20

Respetando los principios básicos de modularidad, el Diagrama de componentes

(DCOMP) permite mostrar cómo el software es empaquetado en conjuntos de
funcionalidades, que normalmente corresponden a clases dentro de un mismo espacio de
nombres.

Por ejemplo, es lógico pensar que las clases de un sistema de Biblioteca se empaqueten
en una componente que podría llamarse “ComponentesDelDominioBiblioteca”, o que las
clases relacionadas con los accesos a una base de datos estén empaquetados en una
componente llamada “ComponentesDeDatos”. Luego que se han definido las
componentes, estas se pueden incluir en un paquete como se mostrará más adelante en
el Diagrama de paquetes.
PREGUNTA

¿Cómo crees que se vería un Diagrama de Componentes?

Para nuestro ejemplo de Biblioteca, podríamos desarrollar 4 componentes: las que son
de tipo gráficas como las ventanas del sistema (suponiendo que es de escritorio),
componentes de negocio (para implementar las reglas del negocio), componentes de
datos (para implementar las clases que accedan a la Base de Datos) y componentes del
dominio de Biblioteca (por ejemplo: Libro, Cliente, Estante, etc.). El DCOMP se vería como
en la siguiente figura:
 Página 14 de 20

Figura 6. Ejemplo de diagrama de componentes

para un sistema de compra/venta de libros.

Fuente: Elaboración propia.

6.2 Diagrama de paquetes

El Diagrama de Paquetes (DP) se usa para mostrar las dependencias entre los paquetes
que componen un modelo, por lo que presenta la forma en que el sistema está dividido en
agrupaciones lógicas y las dependencias entre esas agrupaciones.

Un paquete es un contenedor, por lo que puede ser entendido, por ejemplo, como una
carpeta, un proyecto compilado en una .dll de Windows, una .jar de Java, etc. Los DP
suministran una descomposición de la jerarquía lógica de un sistema.
 Página 15 de 20

PREGUNTA
¿Por qué crees que es importante la organización de un
software en paquetes?

Para la organización arquitectónica del software, resulta relevante la organización en

paquetes, puesto que ayudan a separar las responsabilidades del software, aumentando
la coherencia y disminuyendo el acoplamiento. Además, la división en paquetes sirve para
la asignación de recursos humanos en la gestión del proyecto, ya que pueden ser
asignados a una persona o a un equipo de desarrollo, dependiendo del tamaño del
sistema. Por otro lado, la dependencia entre los paquetes puede ayudar a marcar el orden
en que se implementa el software.

Los paquetes normalmente se usan para contener dentro de ellos las componentes del
sistema. Veamos cómo quedaría nuestro DP para el sistema de Biblioteca:
 Página 16 de 20

Figura 7. Ejemplo de diagrama de paquetes para un sistema de compra/venta de libros.

Fuente: Elaboración propia.

En el diagrama se muestran las dependencias con flechas de líneas punteadas. Por

ejemplo, la Capa de Presentación necesita usar los Componentes de Negocio de la Capa
de Negocio, los cuales, a su vez, requieren de aquellos que están en la Capa de Datos. Del
mismo modo, las 3 capas anteriores dependen de la Capa de Modelo OO, puesto que
deben usar las clases: Cliente, Libro, Estante, etc.

7. Vista física
La vista física (VF) muestra la topología de los componentes físicos del sistema, su
comunicación, y las conexiones que conforman la solución y sus servicios. Muestra el
despliegue de la aplicación en la red de computadoras, describe el mapeo del software en
el hardware y refleja los aspectos de distribución. Esta vista representa la perspectiva de
los diseñadores e ingenieros de sistemas y técnicos de soporte.
 Página 17 de 20

7.1 Diagrama de despliegue

El diagrama de despliegue (DD) se utiliza para modelar la disposición física de los
artefactos de software en nodos. Los nodos son contenedores como, por ejemplo, un
computador, un sistema operativo, un sistema empresarial o un servidor de base de
datos.
PREGUNTA

¿Cómo visualizar un sistema a gran escala?

El DD muestra la arquitectura del sistema como un despliegue o distribución de los

artefactos de software, supeditado a los objetivos de despliegue. Muy usualmente los DD
se usan para mostrar la topología de red del sistema completo a gran escala.

En nuestro ejemplo de Biblioteca podemos visualizar el siguiente DD:

Figura 8. Ejemplo de diagrama de despliegue para un sistema de compra/venta de

libros.

Fuente: Elaboración propia.

 Página 18 de 20

En el DD podemos ver cómo se encuentra un computador de usuario ejecutando nuestro

software de Biblioteca. Para que el software funcione, debe ser instalado en un sistema
operativo, en este caso, Windows.

Nuestro software representado como el nodo “Sistema de Biblioteca”, contiene dentro la

arquitectura del programa desarrollado en capas, que interactúan entre sí.

La capa de datos tiene las componentes de datos que permiten conectarse a la base de
datos Oracle y ejecutar procedimientos almacenados para trabajar con las tablas.
 Página 19 de 20

Conclusiones
Como hemos revisado, el modelo 4+1 describe de manera muy completa la arquitectura
de software usando las cinco vistas compatibles, de modo que siempre los integrantes de
los proyectos o stakeholders puedan mantener conversaciones fluidas sobre el propio
sistema.

Cada vista tiene un enfoque con perspectiva en el tipo de persona que lo puede utilizar y
permite establecer un lenguaje común en el proyecto.

Como se ha podido apreciar, el hecho de que el modelo 4+1 de Kruchten se base

fundamentalmente en diagramas UML, hace que el modelamiento de un software pueda
ser representado con los diferentes artefactos que lo componen.

Los artefactos son de distintos tipos y pueden ser representados por los símbolos que
tienen cada uno de los diagramas. De esta forma, podemos explicar por medio de planos
la arquitectura de software de un sistema a gran escala.

Dada la complejidad que tienen los sistemas de software, el modelo 4+1 y los diagramas
UML constituyen hoy en día una pieza clave para poder construir grandes sistemas,
repartir tareas y poder poner de acuerdo a todos los integrantes del proyecto.
 Página 20 de 20

Referencias bibliográficas
Bass, L., Clements, P. y Kazman, R. (2003). Software Architecture in Practice. Boston:
Addison-Wesley.

Booch, G., Rumbaugh, J. y Jacobson, I. (1999). El lenguaje unificado de modelado. Madrid:

Addison Wesley.

Booch, G. (2007). Object-oriented Analysis and Design with Applications. New Jersey:
Addison-Wesley.

Eclipse (s.f.) SOA Platform Project. Recuperado de: https://www.eclipse.org/soa/

Jacobson, I., Booch, G. y Rumbaugh, J. (2000). El proceso unificado de desarrollo. Madrid:

Addison Wesley.

Kruchten, P. & Thompson, C. (1994). An object-oriented, distributed architecture for large

scale Ada systems. Proceedings of the TRI-Ada’94 Conference: 262-271.

Kruchten, P. (1995). The “4+1” View Model of Architecture. IEEE Software, 12(6): 42-50.

Pressman, R. (2010). Ingeniería de software: un enfoque práctico. México, D.F.: McGraw-

Hill.

• Rozanski, N. y Woods, E. (2005). Software Systems Architecture: Working with

Stakeholders Using Viewpoints and Perspectives. New Jersey: Addison-Wesley.
Este material fue desarrollado por la docente Carolina Toro para la Universidad
Mayor y ha sido diseñado para su lectura en formato digital.
Última actualización mayo, 2023.