Modelo de 4+1 Vistas / RUP Rational Unified Process (1995)

En muchos libros y artculos se intenta capturar todos los detalles de la arquitectura de un sistema usando un nico diagrama. Sin embargo, de esta manera la arquitectura no es entendida por todos los stakeholders. El modelo de 4+1 vistas fue desarrollado para remediar este problema. Este modelo describe la arquitectura del software usando cinco vistas concurrentes, refirindose cada vista a un conjunto de intereses de diferentes stakeholders, quedando as cubiertos los intereses de todos sus clientes. Las cinco vistas son: La vista lgica: soporta los requisitos funcionales, los servicios que el sistema debe proporcionar a sus usuarios finales. Generalmente, muestra las abstracciones clave (las clases y las interacciones entre ellas). La vista de procesos: Aborda aspectos concurrentes durante la ejecucin (tareas, temas, procesos y sus interacciones).Se tienen en cuenta algunos requisitos no funcionales, tales como el rendimiento, la disponibilidad del sistema, la concurrencia y la distribucin, la integridad del sistema, y tolerancia a fallos. La vista fsica: el punto de vista de aplicacin se centra en la organizacin de los mdulos de software actuales en el entorno de desarrollo de software. La vista de desarrollo: describe la organizacin esttica del software en su ambiente de desarrollo. Tiene en cuenta los requisitos del sistema no funcionales, tales como la disponibilidad del sistema, la fiabilidad (tolerancia a fallos), el rendimiento (throughput), y la escalabilidad La vista de escenario: El punto de vista de escenario consiste en un pequeo subconjunto de los escenarios importantes (por ejemplo, casos de uso) para demostrar que los elementos de los cuatro puntos de vista trabajan a la perfeccin. Este punto de vista es redundante con los otros (de ah el "1"), pero tiene dos funciones fundamentales: - Acta como un conductor para ayudar a los diseadores a descubrir elementos arquitectnicos durante el diseo de la arquitectura. - Valida y muestra el diseo de arquitectura, en ambos como punto de partida para las pruebas de un prototipo de la arquitectura.

Stakeholders en RUP Manager Este papel est principalmente involucrado en la gestin y configuracin del proceso de ingeniera de software Analista Un analista est principalmente involucrado en la obtencin y el estudio de requisitos Desarrollador Personas que disean e implementan el software Tester Se ocupan principalmente de probar el software Produccin y Roles necesarios para el apoyo del proceso de desarrollo soporte de software, o para producir materiales adicionales requeridos por el producto final General Las funciones que no encajan en uno de los papeles de otros conjuntos. Un ejemplo es el revisor, que proporciona informacin oportuna a los miembros del equipo del proyecto en los productos de trabajo Vista Lgica Stakeholder: Usuario final Describe la funcionalidad del sistema Descomposicin del sistema (abstraccin, encapsulado y herencia).

Vista de Procesos Stakeholder: Integradores del sistema Define los aspectos de concurrencia y sincronizacin. Vista de Desarrollo Stakeholder: Programadores del sistema Describe la organizacin esttica del software (mdulos, interfaces, portabilidad, seguridad, reutilizacin,). Vista Fsica Stakeholder: Ingenieros de sistema Describe el mapeo del software en el hardware y los aspectos de distribucin. Escenarios o Casos de Uso Integra las cuatro anteriores representando las relaciones cruzadas. Capturan la funcionalidad crtica del sistema.

Cada vista define: Los componentes y conectores que usa La notacin grfica especfica

Vista Lgica Diagramas de clases Patrones para la descripcin esttica

Vista de Proceso: Tareas, sincronizacin, comunicacin

Vista Fsica:

Resumen: