El modelo 4+1 describe una arquitectura de software que utiliza cinco vistas concurrentes: la vista lógica, la vista de procesos, la vista física, la vista de desarrollo y una quinta vista de escenarios. Cada vista se enfoca en un conjunto diferente de intereses de los interesados del sistema. Las vistas permiten organizar la descripción de las decisiones arquitectónicas y se ilustran con casos de uso o escenarios.

1. LA ARQUITECTURA DE SOFTWARE MODELO 4+1
El modelo 4+1 describe la arquitectura del software, la cual utiliza cinco vistas
concurrentes, cada vista se refiere a un conjunto de intereses de diferentes stakeholders
del sistema.
• La vista lógica describe el modelo de objetos del diseño cuando se usa un método de
diseño orientado a objetos. Para diseñar una aplicación muy orientada a los datos, se
puede usar un enfoque alternativo para desarrollar algún otro tipo de vista lógica, tal como
diagramas de entidad-relación
• La vista de procesos describe los aspectos de concurrencia y sincronización del diseño.
• La vista física describe el mapeo del software en el hardware y refleja los aspectos de
distribución.
• La vista de desarrollo describe la organización estática del software en su ambiente de
desarrollo.
Los diseñadores de software pueden organizar la descripción de sus decisiones de
arquitectura en estas cuatro vistas, y luego ilustrarlas con un conjunto reducido de casos
de uso o escenarios, los cuales constituyen la quinta vista. La arquitectura evoluciona
parcialmente a partir de estos escenarios.
Para cada vista definimos un conjunto de elementos (componentes, contenedores y
conectores), captamos la forma y los patrones con que trabajan, y captamos la
justificación y las restricciones, relacionando la arquitectura con algunos de sus
requisitos. Cada vista se describe en lo que llamamos “diagrama” (blueprint) que usa su
notación particular.

2. Escenarios: El escenario es representado por diagramas de casos de uso, la vista de
escenarios corresponde con instancias de casos de uso que unifican todas las vistas. Así,
desde casos de uso se debiera poder hacer una trazabilidad a todos los componentes del
sistema software, viendo, por ejemplo, que máquinas, o clases, o componentes, o .jar, o
procesos, son los responsables de que el sistema cubra una cierta funcionalidad.
Vista Lógica: Debe soporta el análisis y la especificación de los requisitos funcionales,
es decir lo que el sistema debería proporcionar en términos de servicios a sus usuarios.
los diagramas uml que satisfacen esta vista son diagrama de clases, de estado y
colaboración. El estilo arquitectónico más usado es el orientado a objeto.
Vista de Procesos: Esta vista debe soportar los requisitos no funcionales. Especificar el
ciclo de control de cada operación así como diseñar la concurrencia y sincronización de
los procesos de cada una de las clases de la vista lógica. Por lo tanto la vista de procesos
debe ser trazable con la vista lógica. Los diagramas que dan soporte a esta vista son de
actividad, de estados, de secuencia. El estilo arquitectónico más usado es pipes & filter o
cliente/servidor.
Vista de Desarrollo: La vista de desarrollo muestra de forma estática la organización de
los módulos del software en entorno de desarrollo. El software es empaquetado en
pequeños trozos (librerías de programa, subsistemas, componentes, etc.), los subsistemas
se organizan en capas jerárquicas, y cada capa proporciona una interfaz bien definida a
sus capas superiores. Esta vista se apoya en los diagramas uml de componentes y
paquetes. Esta vista es trazable con la vista lógica y el estilo arquitectónico más usado es
el de n-tier.
Vista Física: La vista física contiene los nodos que forman la topología hardware sobre
la que se ejecuta el sistema. Se preocupa principalmente de la distribución, entrega e
instalación de las partes que constituyen el sistema. Los aspectos estáticos de esta vista
se representan mediante los diagramas de despliegue y los aspectos dinámicos con
diagramas de interacción, estados y actividades.