1.1 Arquitectura de 4+1 vistas

LA ARQUITECTURA SOFTWARE. EL MODELO 4+1 Algunas notas breves sobre la arquitectura software y su modelización en 4+1... La arquitectura software trata el diseño e implementación de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto número de elementos arquitectónicos para satisfacer la funcionalidad y ejecución 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 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). Este modelo define 4 vistas principlaes:  Vista Lógica (Logical View), modelo de objetos, clases, entidad – relación, etc. Vista de Proceso (Process View),  modelo de concurrencia y sincronización. Vista de Desarrollo (Development View), organización estática del software en su entorno de desarrollo (librerías, componentes, .ear, .jar, etc.). Vista Física (Physical View), modelo de correspondencia software - hardware (aspectos de distribución en máquinas, por ejemplo) Y una vista más, 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 según este modelo, la arquitectura es en realidad evolucionada desde escenarios El modleo 4+1 aplica la ecuación 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 más adecuada notación (por ejemplo, existen diagramas UML que se adapatan más a una vista que otra). Para cada vista los arquitectos pueden escoger cierto esquilo arquitectónico (patrón arquitectónico), permitiendo la coexistencia de múltiples estilos en un sistema. Y por último, también comentar que el modelo de vistas “4+1” es  “genérico”: otras notaciones y herramientas a parte de UML pueden usarse, y cualquier método de diseño, especialmente para las descomposiciones lógicas y de proceso. Entonces, para hacer un diseño completo de la Arquitectura de Software debemos documentar nuestro sistema en diferentes Vistas o Ángulos, aquí es donde viene el uso del modelo 4 + 1 de Pilippe Kruchten. En la Vista Lógica hablamos principalmente de los requerimientos funcionales del sistema y de lo que el sistema debe de hacer, las funciones y servicios que se han definido. Nos vamos a enfocar a lo que hemos definido como dominio de la aplicación, lo que son las clases y objetos principales que formaran el corazón o "core" de nuestra aplicación. Esta vista la vamos a complementar con los diagramas UML: ·         Diagrama de Clases ·         Diagrama de Paquetes En la Vista de Despliegue o Vista de Desarrollo se va a mostrar principalmente como está dividido nuestro sistema de software en componentes, y muestra las dependencias entre estos componentes.  Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. También va a mostrar  la organización y las dependencias entre el conjunto de componentes, y como se comunican entre ellos. Esta vista la vamos a complementar con los diagramas UML: ·         Diagrama de Componentes ·         Diagrama de Paquetes En la Vista de Procesos representamos los flujos de trabajo paso a paso de negocio y operacionales de los componentes que conforman el sistema. También va a mostrar algunos de los requisitos no funciónales, como son ejecución, disponibilidad, tolerancia a fallas, integridad, seguridad, confiabilidad entre otros. Esta vista la vamos a complementar con los diagramas UML: ·         Diagrama de Actividad En la Vista Física representamos como están distribuidos los componentes entre los distintos equipos que conforman la solución incluyendo los servicios. Los elementos definidos en la vista lógica se mapean a componentes de software o de hardware. Esta vista la vamos a complementar con los diagramas UML: ·         Diagrama de Deployment Por ultimo tenemos la Vista +1 o Vista de Escenarios, esta vista va a ser representada por los casos de uso, que nos van a ayudar a unir las otras cuatro vistas, así desde un caso de uso podemos ver cómo se van ligando las otras cuatro vistas, con esto tenemos una trazabilidad de componentes, clases, equipo, paquetes, etc., para realización cada caso de uso. Esta vista la vamos a complementar con los diagramas UML: ·         Diagrama de Casos de Uso Relación entre las vistas Como sucede en otras muchas ocasiones, si bien el modelo no es una metodología si que "sugiere" un método de trabajo. Parece lógico que la vista de escenarios o casos de uso sea la de arranque, y que de ahí se pase a la vista lógica. Desde la vista lógica afrontaremos la de desarrollo y procesos, una vez que tenemos por ejemplo las clases definiremos maneras de agruparlas y modos de ejecución. Para con todo concluir en la vista física. Todo ello, obviamente, con sus correspondientes y típicas iteraciones.  Arquitectura y UML Se ha ido exponiendo a lo largo de la explicación de cada una de las vistas su translación a un lenguaje de modelado concreto como UML. Hya que tener en cuenta que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no existía una clara relación entre ambos, lo que amenudo produce confusión al diseñador que en la actualidad quiere modelar una arquitectura con ambas herramientas. A modo de resumen la translación se presenta en la siguiente tabla: Vista UML Escenarios Casos de Uso Lógica Clases, de Estados y Colaboración Desarrollo Componentes Física Despliegue Procesos Actividad, Estados, Secuencia Bibliografía. D. Garlan and M. Shaw, "An Introduction to Software Architecture," Advances in Software Engineering and Knowledge Engineering, Vol. 1, World Scientific Publishing Co., Singapore, 1993. Kruchten P. Architectural Blueprints—The “4+1” View Model of Software Architecture. IEEE Software, November 1995, 12 (6), pp.42-50. Perry D. E.,  Wolf A. L., “Foundations for the Study of Software Architecture,” ACM Software Engineering Notes, 17, 4, October 1992, 40-52. K.P. Birman and R. Van Renesse, Reliable Distributed Computing with the Isis Toolkit, IEEE CS Press, Los Alamitos, Calif. 1994. © Copyright Javier Garzás, all rights reserved. All material on this site is copyrighted. For articles attributed to named authors, they are the copyright of the corresponding authors. Any unattributed articles are copyright Javier Garzás. Please link freely to this site, but if you want to copy any of the materials you should contact the authors first.