Está en la página 1de 14

Vistas de Una Arquitectura

Modelo “4+1” vista de


Kruchten
Introducción
¿A quien esta dirigido un Documento de Arquitectura?

• En realidad existen muchos interesados o stakeholders de un documento de


arquitectura, e incluso estos pueden tener distintos intereses y
conocimientos.
• Dentro de un equipo de trabajo podemos encontrar: analistas,
desarrolladores, probadores, lideres de proyectos, arquitectos, clientes, gente
de infraestructura, de despliegue, usuarios, administradores de bases de
datos, etc.
• Entonces: ¿Cómo escribir un único documento o diagrama que pueda explicar
la arquitectura propuesta para resolver cierto problema?
Modelo 4 +1
• Es muy complejo capturar la arquitectura de software en un sólo
modelo (o diagrama).
• Para manejar esta complejidad se representan diferentes aspectos y
características de la arquitectura en múltiples vistas.
• Una vista es “una presentación de un modelo, la cual
• es una descripción completa de un sistema desde una
• particular perspectiva” (Kruchten, 1995).
• El modelo más aceptado a la hora de establecer las vistas necesarias para
describir una arquitectura software es el modelo 4+1 (Kruchten, 1995).
Kruchten 4+1
• El modelo “4+1” de Kruchten, es un modelo de vistas
• 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
• Diseñado por el profesor Philippe Kruchten
• Que encaja con el estándar “IEEE 1471-2000” (Recommended
Practice for Architecture Description of Software-Intensive Systems).
• http://standards.ieee.org/findstds/standard/1471-2000.html
• Que se utiliza para describir la arquitectura de un sistema software
intensivo basado en el uso de múltiples puntos de vista
Sistema Software
Sistema software = Hardware + Software

• Un sistema software es un software (mas o menos complejo) que “corre”


en un determinado hardware (mas o menos complejo).
• Por ejemplo, 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.
• El modelo de Kruchten habla sobre los conceptos de vista y puntos de vista
• una vista es una representación de todo el sistema software desde una
determinada perspectiva
• un punto de vista se define como un conjunto de reglas (o normas) para realizar y
entender las vistas.
Ejemplo de vista en arquitectura
• Si un arquitecto nos muestra un plano de una casa
nos esta mostrando una vista de la casa y como no
tenemos ni idea de arquitectura, cuando nos
explique o nos de 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.
Vistas de Kruchten
• 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 vista 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.
Vista Lógica
• En esta vista se representa la
funcionalidad que el sistema
proporcionara a los usuarios
finales. 
• 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 
• Se ocupa de la gestión del
software; o en otras palabras, se
va a mostrar como esta 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
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
• 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” Vista de Escenarios:
• Esta vista va a ser representada por
los casos de uso  software y va a
tener unir y relacionar las otras 4
vistas,
• Desde un caso de uso podemos ver
como se ligan las otras 4 vistas, con
lo que tendremos una trazabilidad
de componentes, clases, equipos,
paquetes, etc
• Para completar la documentación
de esta vista se pueden incluir el
diagramas de casos de uso de UML.
Aclaraciones Finales
• Kruchten no dice de que manera se ha de documentar cada vista;
• Dice que es lo que hay que documentar en cada vista,
• 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.
• Adía de hoy mucho software se hace bajo el paradigma de la programación orientada a objetos.
• 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
• Entonces: un diagrama es una vista, con un punto de vista que ya está muy bien definido en UML.
• Con UML nos ahorramos el tener que documentar los puntos de vista al estar ya documentadas.
• Cada uno puede representar las vista “como le de la gana” siempre y cuando estén reflejadas
en el punto de vista como ocurrirá en muchos casos en la vista física.

También podría gustarte