4 + 1 modelo de vista arquitectnico 4 1 es un modelo de vista diseada por Philippe Kruchten para "que describe la arquitectura de los sistemas

de uso intensivo de software, basado en el uso de mltiples puntos de vista, concurrentes". Las vistas se utilizan para describir el sistema desde el punto de vista de las diferentes partes interesadas, como de los usuarios finales, desarrolladores y administradores de proyectos. Las cuatro vistas del modelo son lgicos, el desarrollo, el proceso y vista fsico. Adems seleccionados los casos de uso se utilizan o escenarios para ilustrar la arquitectura sirve como el "ms uno" punto de vista. Por lo tanto el modelo contiene 4 + 1 vistas:

Vista lgica: La vista lgica se refiere a la funcionalidad que el sistema ofrece a los usuarios finales. Diagramas UML se utilizan para representar el punto de vista lgico como diagrama de clases , diagrama de comunicacin , diagrama de secuencia . Vista de desarrollo: La vista del desarrollo ilustra un sistema desde la perspectiva de un programador y se ocupa de la gestin de software. Este punto de vista tambin se conoce como la vista de la implementacin. Se utiliza el UML diagrama de componentes para describir los componentes del sistema. Diagramas de UML utilizados para representar la vista del desarrollo incluyen el diagrama de paquete. Vista del proceso: Las ofertas visin de proceso con los aspectos dinmicos del sistema, explica los procesos del sistema y la forma en que se comunican, y se centra en el comportamiento de tiempo de ejecucin del sistema. La vista del proceso se dirige concurrencia, distribucin, integradores, el rendimiento y la escalabilidad, etc Diagramas UML para representar vista del proceso incluyen el diagrama de actividad. Vista fsico: El punto de vista fsico representa el sistema desde el punto de vista de un ingeniero de sistemas. Se ocupa de la topologa de componentes de software en la capa fsica, as como las conexiones fsicas entre estos componentes. Este punto de vista tambin se conoce como el punto de vista de implementacin. Diagramas UML utilizados para representar vista fsico incluyen el diagrama de implementacin.

Escenarios: La descripcin de una arquitectura se ilustra el uso de un pequeo conjunto de casos de uso o escenarios que se convierten en una quinta vista. Los escenarios describen secuencias de interacciones entre los objetos y entre los procesos. Ellos se utilizan para identificar elementos arquitectnicos y para ilustrar y validar el diseo de la arquitectura. Tambin sirven como punto de partida para las pruebas de un prototipo de la arquitectura. Este punto de vista tambin se conoce como uso ver caso.

El Framework 4+1 de Kruchten define cuatro vistas principales para la arquitectura (como se puede ver en la imagen superior) y una vista ms, la +1, que est formada por las necesidades funcionales que cubre el sistema, y que se identifica como vista de casos de uso. Una vista es una representacin de un modelo, la cual es una descripcin completa de un sistema desde una particular perspectiva. El mapeo de las vistas propuestas por el Framework vs. Arquitectura y Componentes UML es el siguiente: Framework 4+1 Use-Case View Logical View Process View Implementation View Deployment View Arquitectura Casos de Uso y QoS Lgica Procesos Implementacin y Datos. Deployment UML Casos de Uso Clases, de Estados y Colaboracin Actividad, Estados y Secuencia Componentes Despliegue

LA ARQUITECTURA SOFTWARE. EL MODELO 4+1 Algunas notas breves sobre la arquitectura software y su modelizacin en 4+1...

La arquitectura de software trata del diseo e implementacin de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos para satisfacer la funcionalidad y ejecucin de los requisitos del sistema; as como los requisitos no funcionales del mismo: fiabilidad, escalabilidad, portabilidad, disponibilidad, etc. Perry y Wolf (1992) describen una arquitectura software como: Arquitectura Software = {Elementos, Formas, Fundamento/Restricciones} Es muy complejo capturar la arquitectura software en un slo modelo (o diagrama). Para manejar esta complejidad se representan diferentes aspectos y caractersticas de la arquitectura en mltiples vistas. Una vista es una presentacin de un modelo, la cual es una descripcin completa de un sistema desde una particular perspectiva (Kruchten, 1995). El modelo ms aceptado a la hora de establecer las vistas necesarias para describir una arquitectura software es el modelo 4+1 (Kruchten, 1995). Este modelo define 4 vistas principlaes:

Vista Lgica (Logical View), modelo de objetos, clases, entidad relacin, etc. Vista de Proceso (Process View), modelo de concurrencia y sincronizacin. Vista de Desarrollo (Development View), organizacin esttica del software en su entorno de desarrollo (libreras, componentes, .ear, .jar, etc.). Vista Fsica (Physical View), modelo de correspondencia software - hardware (aspectos de distribucin en mquinas, por ejemplo)

Y una vista ms, la "+1", que se muestra y traza en cada una de las anteriores y que est formada por las necesidades funcionales que cubre el sistema, y que en ocasiones identificamos como vista de "casos de uso". De donde deducimos que segn este modelo, la arquitectura es en realidad evolucionada desde escenarios El modelo 4+1 aplica la ecuacin de Perry y Wolf (1992) de forma independiente para cada vista, por ejemplo, cada vista puede definir un conjunto de elementos para su uso (componentes, contenedores y conectores). Cada vista es descrita usando su particular y ms adecuada notacin (por ejemplo, existen diagramas UML que se adapatan ms a una vista que otra). Para cada vista los arquitectos pueden escoger cierto esquilo arquitectnico (patrn arquitectnico), permitiendo la coexistencia de mltiples estilos en un sistema. Y por ltimo, tambin comentar que el modelo de vistas 4+1 es genrico: otras notaciones y herramientas a parte de UML pueden usarse, y cualquier mtodo de diseo, especialmente para las descomposiciones lgicas y de proceso. 1. Arquitectura Lgica (Logical Architecture)

Soporta el anlisis y la especificacin de los requisitos funcionales: lo que el sistema debera proporcionar en trminos de servicios a sus usuarios. El sistema se descompone en un conjunto de abstracciones clave tomadas mayormente del dominio del problema, en forma de objetos o clases. En esta vista se usan comnmente los diagramas de clases, los de interaccin y objetos.

Notacin: La notacin ms usada es UML, y dentro de esta diagramas de clases y paquetes. Estilo: El estilo ms usado para la vista lgica es el Orientado a Objetos.

2. Arquitectura de Procesos (Process Architecture) Se tratan algunos requisitos no funcionales. Ejecucin, disponibilidad, tolerancia a fallos, integridad, etc. Esta vista tambin especifica que hilo de control ejecuta cada operacin identificada en cada clase identificada en la vista lgica. La vista se centra por tanto en la concurrencia y distribucin de procesos.

Notacin: La notacin ms usada es UML, y dentro de esta diagramas estados, actividad y similares. Estilo: pueden encajar varios estilos. Por ejemplo, tomando la taxonoma de Garlan y Shaw (1993), pueden usarse tuberas y filtros (pipes and filtres) o Cliente Servidor (con variantes de mltiples clientes simple servidor y mltiples clientes mltiples servidores). Para sistemas ms complejos puede usarse un estilo similar a la ISIS system's process groups, como describe Kenneth Birman (1994).

3. Arquitectura de Desarrollo (Development Architecture) La vista de desarrollo o despliegue se enfoca en la organizacin de los mdulos software en el entorno de desarrollo. El software es empaquetado en pequeos trozos (libreras de programa, subsistemas, componentes, etc.), los subsistemas se organizan en capas jerrquicas, y cada capa proporciona una interfaz bien definida a sus capas superiores La vista de desarrollo toma por tanto requisitos internos relacionados con facilidad de desarrollo, gestin del software (reparto de requisitos, trabajo del equipo), evaluacin de costes, planificacin, monitorizacin del progreso del proyecto, reutilizacin, portabilidad, seguridad y restricciones impuestas por las herramientas o por el lenguaje de programacin Esta organizacin del software se suele apoyar en diagramas de mdulos o de subsistemas que muestran las relaciones de exportacin (export) e importacin (import). Y destacar que podr describirse la vista de desarrollo por completo solamente despus de haber identificado todos los elementos software.

Notacin: La notacin ms usada es UML, y dentro de esta diagramas de componentes y paquetes.

Estilo: se recomienda definir de cuatro a seis capas de subsistemas en la vista de desarrollo. Una regla de diseo es que un subsistema puede solamente depender de subsistemas en la misma capa o en las menores. Esto minimiza las dependencias entre mdulos a favor de una ms simple estrategia capa capa.

4. Arquitectura Fsica (Physical Architecture) La vista fsica se centra en los requisitos no funcionales, tales como la disponibilidad del sistema, la fiabilidad (tolerancia a fallos), ejecucin y escalabilidad. Y tambin presenta cmo los procesos, objetos, etc., corresponden a nodos de proceso:

Componentes: nodos de proceso. Conectores: LAN, WAN, bus, etc. Contenedores: subsistemas fsico

Varias configuraciones fsicas pueden usarse. La correspondencia del software a los nodos debe ser altamente flexible y tener el mnimo impacto en el cdigo fuente. 5. Escenarios (Scenarios) 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 sis tema software, viendo, por ejemplo, que mquinas, o clases, o componentes, o .jar, o procesos, son los responsables de que el sistema cubra una cierta funcionalidad. 6. Relacin entre las vistas Como sucede en otras muchas ocasiones, si bien el modelo no es una metodologa si que "sugiere" un mtodo de trabajo. Parece lgico que la vista de escenarios o casos de uso sea la de arranque, y que de ah se pase a la vista lgica. Desde la vista lgica afrontaremos la de desarrollo y procesos, una vez que tenemos por ejemplo las clases definiremos maneras de agruparlas y modos de ejecucin. Para con todo concluir en la vista fsica. Todo ello, obviamente, con sus correspondientes y tpicas iteraciones.