viernes, 28 de agosto de 2015

El Modelo de “4+1” Vistas de la Arquitectura del Software

Un tema interesante que encontré, es el modelo denominado "4+1" del profesor Philippe Kruchten, tambien denominado vistas recurrentes. Este uso de múltiples vistas permite abordar los intereses de los distintos “stakeholders” de la arquitectura por separado: usuarios finales, desarrolladores, ingenieros de sistemas, administradores de proyecto, etc., y manejar los requisitos funcionales y no funcionales separadamente. Se describe cada una de las cinco vistas descritas, conjuntamente con la notación para captarla. Las vistas se diseñan mediante un proceso centrado en la arquitectura, motivado por escenarios y desarrollado iterativamente. 



El modelo de 4+1 vistas fue desarrollado para remediar este problema. El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes. Cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema. 

La arquitectura del software se trata de abstracciones, de descomposición y composición, de estilos y estética. También tiene relación con el diseño y la implementación de la estructura de alto nivel del software. Los diseñadores construyen la arquitectura usando varios elementos arquitectónicos elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del sistema, así como también otros requisitos no funcionales tales como confiabilidad, escalabilidad, portabilidad y disponibilidad del sistema. Bueno pues, en el modelo de Kruchten, propone un sistema de software en 4 vistas bien diferenciadas, cada una de estas vistas ha de mostrar toda la arquitectura del sistema de  software que se este documentando, pero cada una de ellas ha de documentarse de forma diferente y ha de mostrar aspectos diferentes del software.

Para entender mejor este concepto, podemos tomar de ejemplo, si un arquitecto nos enseña el plano de una casa, nos esta enseñando una vista de la casa, pero en el momento en el que nos explica que significado tienen cada símbolo, por ejemplo que determinado símbolo representa una puerta, nos esta dando su punto de vista para entender mejor el plano. si luego nos muestra otro plano en donde se muestren diferentes símbolos con otras representaciones de la casa, nos dara otro punto de vista.

Esto para comprender mejor los puntos de vista, ahora podemos ver mejor cada una de las vistas que propone el modelo:


  • La vista lógica describe el modelo de objetos del diseño cuando se usa un método de diseño orientado a objetos. Para diseñar una aplicación muy orientada a los datos, se puede usar un enfoque alternativo para desarrollar algún otro tipo de vista lógica, tal como diagramas de entidad-relación.
  • La vista de procesos describe los aspectos de concurrencia y sincronización del diseño. 
  • La vista física describe el mapeo del software en el hardware y refleja los aspectos de distribución. 
  • La vista de desarrollo describe la organización estática del software en su ambiente de desarrollo.

Como parte final, están los escenarios los cuales constituyen la quinta vista. y es que los diseñadores de software pueden organizar la descripción de sus decisiones de arquitectura en estas cuatro vistas, pero estas son ilustrarlas en un conjunto reducido de casos de uso o escenarios,  La arquitectura evoluciona parcialmente a partir de estos escenarios. 

Los escenarios son de alguna manera una abstracción de los requisitos mas importantes. Su diseño se expresa mediante el uso de diagramas de escenarios y diagramas de interacción de objetos. Esta vista es redundante con las otras (y por lo tanto “+1”), pero sirve a dos propósitos principales:



  • Como una guía para descubrir elementos arquitectónicos durante el diseño de arquitectura tal como lo describiremos mas adelante 
  • Como un rol de validación e ilustración después de completar el diseño de arquitectura, en el papel y como punto de partido de las pruebas de un prototipo de la arquitectura. 

http://jarroba.com/modelo-41-vistas-de-kruchten-para-dummies/
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:modelo4_1.pdf


LENGUAJES DE PATRONES DE ARQUITECTURA DE SOFTWARE

Como siempre en cada entrada de este blog, lo que trato es de compartir temas relacionados con la clase y en esta ocasión encontré un articulo de la universidad de Pereira algo interesante, el cual hablan un poco de la arquitectura de software visto como una herramienta de ayuda y su vez resaltando el arte que esta contiene, profundizando hasta el tema de lenguajes de patrones de arquitectura de software. Lo que intentare en esta entrada sera de resaltar las características mas importantes que considero encontrados en este articulo.



Como primera medida me parece importante dar una referencia de la definición de arquitectura de software, que de manera general, se define como un nuevo paradigma o nueva forma de ver un sistema de información desde un punto de vista holístico, donde cada componente afecta los requerimientos fundamentales, ya sean funcionales o no funcionales. Esta disciplina aborda estos requerimientos rigurosamente y garantiza un buen diseño de la aplicación final, lo que redunda en mejor calidad, un mayor retorno de inversión de los proyectos y garantiza una mejor mantenibilidad de los sistemas de información construidos. Otra definición es la de George Fairbanks quien define la Arquitectura de Software como: La ciencia que trata el diseño de un sistema de información y del impacto de sus cualidades como: desempeño, seguridad, modificabilidad entre otras.

De forma histórica y evolutiva, el articulo muestra el cambio que se tuvo de la ingeniería de software a la arquitectura de software.

La Ingeniería de Software tuvo sus inicios en la década de los sesenta y a partir de allí a evolucionado de forma constante a través de las últimas seis décadas. En los años cincuenta se inició con el intentó imitar la ingeniería de hardware y se pensó en ese entonces que la utilización del método científico brindaría un soporte investigativo suficiente para obtener un proceso técnico coherente. Finalizando el siglo XX la ingeniería evolucionó como un área de estudio más estructurada y con fundamentos teóricos fuertes. Desde entonces la voluntad de los ingenieros fue de mejorar la calidad del software construido y de dar herramientas que facilitaran el trabajo a diseñadores e implementadores de sistemas de información en general.



Dominios específicos de aplicación


Los lenguajes de patrones han ocupado un lugar muy importante en los diseños de Arquitectura de Software. Se aplican tanto en proyectos de investigación y como en proyectos comerciales de desarrollo de software.

Una ejemplo de cómo los lenguajes de patrones pueden ser usados en dominios específicos se puede observar en el proyecto realizado por IBM donde se define un lenguaje de patrones para aplicaciones eBusiness. Este lenguaje divide los patrones de arquitectura en cuatro categorías: Patrones de negocios, patrones de integración, patrones de aplicación y patrones de ejecución, los cuales parten la arquitectura completa en tres capas principales como se sigue: Capa de negocios, capa de integración y Middleware o Capa de infraestructura. A continuación se define cada uno de las categorías que conformaron el lenguaje propuesto.

Patrones de negocio: mapea las interacciones entre los actores del negocio y las funcionalidades del sistema en particular. Patrones de Integración: Estos se definen como ortogonales a la capa de negocios, creando soluciones particulares que al integrarse soportan las funcionalidades de un sistema en particular.
Patrones de Aplicación: Estos patrones refinan los patrones de negocio e integración subdividiendo los subsistemas en componentes que proveen interfaces claras de implementación de funcionalidades del sistema a diseñar.
Patrones de Ejecución: Refinan los componentes del patrón de aplicación descomponiéndolos en componentes más pequeños sobre la infraestructura o middleware. Ya en este lenguaje los patrones intervienen directamente en la capa física de la aplicación con infraestructura y tecnología.

Esta subdivisión de patrones permite una variedad de soluciones de diseño reusables por diversas aplicaciones en este dominio en particular.

Los Lenguajes de Patrones citados anteriormente han sido utilizados por la industria, y estos se originaron de proyectos de investigación. Otras universidades e investigadores han desarrollado diversos Lenguajes los cuales hoy en día se han convertido en estándares de facto. A continuación se mencionan algunos estos.



http://200.21.217.140/index.php/revistaciencia/article/view/8595