Академический Документы
Профессиональный Документы
Культура Документы
La arquitectura software trata el 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 principales:
1. Vista Lgica (Logical View), modelo de objetos, clases, entidad relacin, etc. 2. Vista de Proceso (Process View), modelo de concurrencia y sincronizacin. 3. Vista de Desarrollo (Development View), organizacin esttica del software en su entorno de desarrollo (libreras, componentes, .ear, .jar, etc.). 4. Vista Fsica (Physical View), modelo de correspondencia software - hardware (aspectos de distribucin en mquinas, por ejemplo)
Figura 1. Modelo de vistas 4+1 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 adaptan 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.
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.
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) .
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.
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 sistema 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.
7. Arquitectura y UML
Se ha ido exponiendo a lo largo de la explicacin de cada una de las vistas su translacin a un lenguaje de modelado concreto como UML. Hay que tener en cuenta que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no exista una clara relacin entre ambos, lo que a menudo produce confusin al diseador que en la actualidad quiere modelar una arquitectura con ambas herramientas. A modo de resumen la translacin se presenta en la siguiente tabla:
Vista Escenarios Lgica Desarrollo Fsica Procesos UML Casos de Uso Clases, de Estados y Colaboracin Componentes Despliegue Actividad, Estados, Secuencia
Un estilo es un concepto descriptivo que define una forma de articulacin u organizacin arquitectnica Conjunto de restricciones que definen un conjunto o familia de arquitecturas que los satisfagan. Un estilo arquitectural puede ser visto como un meta-modelo que provee una organizacin de alto nivel a un sistema de software. Un estilo de arquitectura es una especializacin de un tipo de vista, que establece o elementos y relaciones, o una serie de restricciones de cmo pueden usarse. Cada estilo propicia atributos de calidad, y la decisin de implementar alguno de los existentes depende de los requerimientos de calidad del sistema
Un estilo arquitectnico define un vocabulario de componentes y tipos de conectores. Slo describe el esqueleto estructural y general para aplicaciones. Son independientes del contexto al que puedan ser aplicados. Cada estilo es independiente de los otros.
y y y
Describen una clase de arquitecturas, o piezas significantes de una arquitectura. Son muy usados en la prctica. Es un paquete coherente de decisiones de diseo Tienen propiedades identificadas que permiten el re-uso. Permiten evaluar arquitecturas alternativas con ventajas y desventajas conocidas ante diferentes conjuntos de requerimientos no funcionales.
Clasificacin de los Estilos Arquitectnicos: Estilos de Flujo de Datos: Esta familia de estilos enfatiza la reutilizacin y la modificabilidad. Es apropiada para sistemas que implementan transformaciones de datos en pasos sucesivos. Tubera y filtros
Estilos Centrados en Datos: Esta familia de estilos enfatiza la integrabilidad de los datos. Se estima apropiada para sistemas que se fundan en acceso y actualizacin de datos en estructuras de almacenamiento Arquitecturas de Pizarra o Repositorio
Estilos de Llamada y Retorno: Esta familia de estilos enfatiza la modificabilidad y la escalabilidad. Son los estilos ms generalizados en sistemas en gran escala Modelo Vista Controlador (MVC) Arquitecturas en Capas Arquitecturas Orientadas a Objetos Arquitecturas Basadas en Componentes
Estilos de Cdigo Mvil: Esta familia de estilos enfatiza la portabilidad. Ejemplos de la misma son los intrpretes, los sistemas basados en reglas y los procesadores de lenguaje de comando. Arquitectura de Mquinas Virtuales
Estilos Peer-to-Peer: Esta familia, tambin llamada de componentes independientes, enfatiza la modificabilidad por medio de la separacin de las diversas partes que intervienen en la computacin. Consiste por lo general en procesos independientes o entidades que se comunican a travs de mensajes. Arquitecturas Basadas en Eventos Arquitecturas Orientadas a Servicios Arquitecturas Basadas en Recursos