Tip:
Highlight text to annotate it
X
¿Qué es el modelo 4+1? El modelo "4+1" de Kruchten, es un modelo
de vistas diseñado por el profesor Philippe Kruchten y que encaja con el estándar "I
triple E 1471-2000" que se utiliza para describir la arquitectura de un sistema software intensivo
basado en el uso de múltiples puntos de vista.
Ejemplo. 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 (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.
Vistos los conceptos de lo que son las vistas y los puntos de vista, y habiendo explicado
que es un sistema de software, ya se puede hacer a la idea de que va el modelo "4+1"
vistas de Kruchten para la descripción de arquitecturas de sistemas de software.
Lo que propone Kruchten es que un sistema de 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". Estas 4 vista las denominó Kruchten
como: vista lógica, vista de procesos, vista de despliegue y vista física, ademas 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 de 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 proporcionará 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 cómo está dividido el sistema de 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" o 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 el diagramas
de casos de uso de UML.
Conclusión 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
una cosa que se llama UML (Lenguaje de Modelado Unificado), que 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é hora las cosas empiezan a cuadrar? Pues eso, que con UML nos ahorramos el tener
que documentar los puntos de vista al estar ya documentadas.