UNIVERSIDAD DE LAS FUERZAS ARMADAS ESPE-L

Nombre: Daír Sánchez Carrera: Ingeniería en Software

Curso: 4to nivel Asignatura: Metodología de desarrollo de sistemas
II
Fecha: 19/06/2018
Modelos 4+1 de Krutchen
El modelo “4+1” de Kruchten, es un modelo que se utiliza para describir la arquitectura
de un sistema software intensivo basado en el uso de múltiples puntos de vista. Lo que
propone Kruchten es que un sistema software se ha de documentar y mostrar 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”.
Este modelo define 4 vistas principales:
Vista Lógica (Logical View)
Soporta el análisis y la especificación de los
requisitos funcionales, modelo de objetos, clases,
entidad – relación, etc.
La notación para la vista lógica se deriva de la
notación de Booch. Esta se simplifica
considerablemente de tal modo de tener en cuenta
solamente los ítems relevantes para la arquitectura.
Usamos Rational Rose para apoyar el diseño lógico
de la arquitectura.

Vista de Proceso (Process View)

Se trata de algunos requisitos no funcionales como
ejecución, disponibilidad, tolerancia a fallos,
integridad, entre otros. Se centra en el modelo de
concurrencia y sincronización de procesos.
La notación que usamos para la vista de procesos
se expande de la notación originalmente propuesta
por Booch para las tareas de Ada y se centra
solamente en los elementos arquitectónicamente relevantes.
El software se particiona en un conjunto de tareas independientes podemos entonces
distinguir: tareas mayores son elementos arquitectónicos que pueden ser manejados en
forma unívoca y tareas menores son tareas adicionales introducidas localmente por
motivos de implementación
Vista de Desarrollo (Development View
Organización estática del software en su entorno de desarrollo como: librerías,
componentes, subsistemas, entre otros. La arquitectura de desarrollo completa sólo puede
 describirse completamente cuando todos
los elementos del software han sido
identificados. Sin embargo, es posible
listar las reglas que rigen la arquitectura de
desarrollo – partición, agrupamiento,
visibilidad– antes de conocer todos los
elementos. usamos una variante de la
notación de Booch limitándonos a
aquellos ítems relevantes para la
arquitectura.

Vista Física (Physical View)

Modelo de correspondencia
software - hardware es decir
aspectos de distribución en
máquinas, nodos de procesos,
LAN, WAN, subsistemas físicos.
La correspondencia del software a
los nodos debe ser altamente
flexible y tener el mínimo impacto
en el código fuente.
El software ejecuta sobre una red
de computadores o nodos de
procesamiento (o tan solo nodos). Los variados elementos identificados –redes, procesos,
tareas y objetos– requieren ser mapeados sobre los variados nodos.
Los diagramas físicos pueden tornarse muy confusos en grandes sistemas, y por lo tanto
toman diversas formas, con o sin el mapeo de la vista de procesos.
vista "+1" o escenario
que se muestra y traza en cada una de las anteriores y que está formada por las necesidades
funcionales que cubre el sistema
Los escenarios son de alguna manera una abstracción de los requisitos más importantes.
Su diseño se expresa mediante el uso de diagramas de escenarios y diagramas de
interacción de objetos.
La notación es muy similar a la vista lógica para los componentes, pero usa los conectores
de la vista de procesos para la interacción entre objetos (ver Figura 4). Nótese que las
instancias de objetos se denotan con líneas sólidas. Para el diagrama lógico, capturamos
y administramos los diagramas de escenarios de objetos usando Rational Rose.
Conclusión
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” pueden entender el sistema
software que se esté desarrollando desde diferentes perspectivas.
Sin embargo, me parece que la forma de representar cada vista se podría facilitar si
usamos los diagramas UML, para representar cada una de las 5 vistas en este modelo,
como por ejemplo la vista de escenario se puede representar según sus características con
el diagrama de casos de uso, que es mucho más fácil de entender.
Referencias
[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