Estilos Arquitectónicos en la Ingeniería DE Software PDF

Preview

Summary

Resumen con las generalidades de los estilos arquitectónicos, elementos, clasificación, ventajas y desventajas...

Description

ESTILOS ARQUITECTÓNICOS EN LA INGENIERÍA DE SOFTWARE 1.

GENERALIDADES DE LOS ESTILOS ARQUITECTÓNICOS

1.1. Definición “La arquitectura de software de un programa o de un sistema computacional está definida por la estructura, comprendida por los elementos de software, las propiedades visibles de esos elementos y las relaciones entre ellos.”[1]. Especifica los roles, estructura, organización, reglas, comportamientos, componentes y capas de acuerdo a las características del sistema y las necesidades del cliente, tales restricciones y/o condiciones deben ya estar claramente identificadas en la etapa de levantamiento de requisitos. 1.2. Beneficios del uso de EA • Permite seleccionar una solución entendible y probada a ciertos problemas, definiendo los principios organizativos del sistema • Al basar la arquitectura en estilos que son conocidos las personas entienden más fácilmente las características importantes de la misma [2]. • Permiten evaluar arquitecturas alternativas con ventajas y desventajas conocidas ante diferentes conjuntos de requerimientos no funcionales [3]. Una arquitectura puede implementar varios estilos arquitectónicos y están abiertos a nuevos estilos que surjan en la medida que se puedan acoplar al software existente. [4]. 1.3. Elementos de un EA 1.3.1. Componentes y conectores Colección de módulos de software (Componentes) interactuando a través de un paradigma de comunicación bien definida (conectores) [4] En lo que respecta a los componentes, para la creación de modelos que puedan representarlos de manera óptima en la ejecución del software, deben sugerir su funcionalidad. Los componentes poseen interfaces puertos o puertos por los cuales interactúan con el ambiente [5]. Se clasifican en computacionales

(realizan algún procedimiento), de memoria (almacenan datos), manejadores (estado + operaciones asociadas) y controladores (administran el tiempo de ejecución de eventos). Los conectores representan los enlaces que permiten la comunicación entre componentes, pueden considerarse mensajes asincrónicos, alertas, multicast de eventos (publicación o por suscripción), etc. De acuerdo a su tipo manejan un protocolo específico de comunicación. Los conectores igualmente poseen interfaces denominadas roles que “definen las formas en que las componentes pueden usar los conectores para interactuar” [5].

1.3.2.

Relaciones Indica qué conectores son asociados a qué componentes, definiendo al sistema como un grafo de componentes y conectores. Un attachment válido se da cuando el protocolo del puerto del componente es consistente con el comportamiento esperado por el rol del conector [6].

2. CLASIFICACIÓN DE ESTILOS ARQUITECTÓNICOS La clasificación de estilos arquitectónicos es muy diversa, por lo que suele agruparse en grandes grupos teniendo en cuenta características del sistema. 2.1.

Sistemas centrados en flujos de datos 2.1.1. Tuberías y filtros (Pipes and filters) En esta arquitectura, las tuberías corresponden a los conectores y los filtros a los componentes. Tiene como objetivo el aseguramiento de cualidades de reutilización y modificabilidad. Este estilo es caracterizado por ver el sistema como una serie de transformaciones sobre elementos sucesivos de datos de entrada Los datos entran al sistema y luego navegan a través de componentes al mismo tiempo, antes de ser asignados a su destino final. 2.1.1.1. Filtros Estos componentes son responsables de tareas de enriquecimiento, refinamiento y transformación de datos. Existen flitros activos (que conducen los datos hacia una tubería) y filtros pasivos (que son impulsados por el I/O de la tubería) [7]. 2.1.1.2. Tuberías

Son conectores que mueven datos desde un filtro de salida hasta un filtro de entrada. Existen tuberías que se restringen a un modelo secuencial lineal de filtros (pipeline), otras que restringen la cantidad de datos que fluyen por ellas (bounded pipes), y aquellas que están restringidas a un tipo de dato específico (typed pipes)

Fig 1. Reglas de composición Arquitectura P&F. Fuente: [7] 2.1.1.3. Ejemplos de modelos de P&F con filtros activos. En la industria, este tipo de arquitecturas se puede dar en diferentes escenarios, en especial en sistemas de producción como se muestra en Fig. 2 y Fig. 3. En Fig. 2 aprecia que los filtros manejan total independencia las actividades que realizan, sin embargo, su comunicación mediante el pipe debe realizarse de manera sincrónica.

Fig 2. Modelos de P&F, caso del productor/consumidor

Fig 3. Modelos de P&F. Proceso de producción.

2.1.1.4. Ventajas de la Arquitectura P&F      

Permite entender el sistema global en términos de la combinación de componentes. Soporta de buena manera la reutilización. Los filtros son independientes de sus vecinos. Facilidad de Mantenimiento y mejora. Facilidad de diagnóstico (rendimiento). Soportan la ejecución concurrente. [1]

2.1.1.5. Desventajas de la Arquitectura P&F  

No aconsejado para cuando se necesita interactividad. Problemas de performance ya que los datos se transmiten en forma completa entre filtros [1].

2.1.2. Procesamiento de Lotes (Batch Sequential) Es un modelo secuencial de procesamiento de datos que se caracteriza porque sus subsistemas solo pueden iniciar su ejecución una vez que la ejecución del subsistema que le precede ha completado su ejecución como se puede ver en Fig. 4 [8]. El flujo de datos es completo y/o incremental filtro a filtro. Este tipo de arquitectura es comúnmente usada en el ámbito empresarial, incluye facturación y transacciones bancarias.

Fig. 4. Modelo de procesamiento por lotes. Fuente: [4].

Ventajas Normalmente, la Arquitectura BS proporciona divisiones más simples en los subsistemas. Cada subsistema puede ser un programa independiente que trabaja sobre datos de entrada y produce datos de salida.

Desventajas No proporciona concurrencia e interfaz interactiva, sino que proporciona alta latencia y bajo rendimiento. Además, se requiere control externo para la implementación. [8] 2.2.

Sistemas basados en llamada/retorno (Call/Return) Descomposición jerárquica en subrutinas (componentes) que solucionan una tarea o función definida. Los datos son pasados como parámetros y el manejador principal proporciona un ciclo de control sobre las subrutinas. Reflejan la estructura del lenguaje de programación. Permite al diseñador del software construir una estructura de programa relativamente fácil de modificar y ajustar a escala. Se basan en la bien conocida abstracción de procedimientos/funciones/métodos. [3]

2.2.1. Descomposición Orientada a Objetos (Object-Oriented Decomposing)

Es un tipo de arquitectura de software donde los componentes denominados objetos encapsulan los lados y las operaciones que realizan para la manipulación de dichos datos.[3]. Los objetos interactúan a través de invocación de funciones y procedimientos los cuales actúan como conectores como se puede observar en fig.5.

Fig.5. Diagrama Arquitectura OO. Fuente: [1] 2.2.1.1. Ventajas de la Arquitectura OO Como ventajas de esta arquitectura se encuentran:   

la independencia entre objetos, lo que permite que se modifique uno sin que se alteren los demás Es fácil reutilizar componentes (En la medida que sean genéricos). Hay integridad en los datos ya que solo los pueden manipular ciertos métodos.

2.2.1.2. Desventajas de la Arquitectura OO Como desventajas de esta arquitectura se encuentran:   

2.2.2.

Para usar servicios se debe conocer el nombre de la interface de otro objeto. Los cambios en las interfaces afectan a todos los objetos que la usan. No es suficientemente eficiente para computación de alto rendimiento.

Arquitectura de invocación implícita basada en eventos En lugar de invocaciones de procedimientos explicitas directas, un componente anuncia uno o más eventos y otros componentes registran el interés en un evento asociando un procedimiento a dicho evento [1]. El componente que anuncia dicho evento no sabe a qué componentes va a afectar,

además tales componentes pueden pertenecer a otro módulo. Esta arquitectura está presente dos tipos de modelos: 2.2.2.1. Modelos de emisión (Broadcast): En este tipo de modelos se emiten eventos a todos los subsistemas. Estos subsistemas se “suscriben” al suprasistema que luego les delega el control de dichos eventos. [10]. Este modelo es fácilmente escalable puesto que se pueden integrar nuevos subsistemas con anonimato de los mismos. Sin embargo, estos últimos no saben con certeza cuándo se producirán estos eventos.

Fig. 6. Modelo de control por emisión. Fuente: [10] 2.2.2.2. Modelos dirigidos por interrupciones: Son modelos de control en los cuales la respuesta inmediata a los eventos producidos provenientes del exterior es esencial. Estos eventos son denominados interrupciones los cuales tienen un tiempo de respuesta de acuerdo a la prioridad que se le asigne. Como se observa en Fig 7. Las diferentes interrupciones son manejadas por un controlador que ejecuta determinado proceso.

Fig. 7. Modelo de control por interrupciones Aunque su gran ventaja es la respuesta rápida a interrupciones, la validación de las ocurrencias posee alta dificultad, eso sumado al hecho de que el hardware puede ser una limitante en lo que respecta a número de interrupciones, lo que reduce el rendimiento.

2.2.3.

Arquitectura por capas Es un modelo organizado jerárquicamente donde cada capa provee servicios a la capa superior y es servida por la capa interior (modelo estricto) [2]. Los componentes son las capas y los conectores son los protocolos de interacción entre las mismas (Véase Fig. 8).

Fig. 8. Diagrama de Arquitectura por capas. Fuente: [1] Este modelo permite descomponer el sistema en varios niveles abstrayéndolo. Si lo anterior se hace de manera adecuada, cuyo proceso en ocasiones no es muy claro y definido, los futuros cambios que pueda presentar la estructura en cada una de sus capas. [1]

2.3. 2.3.1.

Sistemas centrados en datos Modelo de Repositorio (Shared-Data) Es un modelo en el que existe un almacenamiento central de datos (Base de Datos) y un conjunto de componentes que operan sobre este [4]. La entrada de los datos es realizada por los componentes a lo cual la BD responde de cierta manera (Véase Fig. 9)

Fig. 8. Diagrama de Arquitectura por capas. Fuente: [1]

Este modelo permite compartir grandes cantidades de datos con un vasto número de componentes, los cuales desconocen el uso que hagan otros componentes. Sin embargo, a medida que haya más componentes, el acceso, recuperación y uso pueden entrar en conflicto ya que todos deben manejar las mismas políticas para realizar dichas actividades [2], de igual manera, al tener un repositorio global, los cambios en la estructura de los datos pueden afectar a los componentes [8] 2.3.2.

Modelo de pizarrón (Blackboard) En este modelo, a diferencia del modelo de repositorio, el almacén de datos es activo y los componentes son pasivos. Ante cualquier cambio en los datos, el almacén notifica a los componentes. Implementando componentes computacionales que hacen uso de AI (Knowledge Sources), el almacén de datos se autorregula sin necesidad de eventos externos.[8]

2.4.

Sistemas orientados a la interacción Estos sistemas tienen por objetivo la separación de los módulos que engloban la estructura de funcionamiento general del software

2.4.1. Modelo-Vista-Controlador   

Modelo: En este se maneja la persistencia de datos y la lógica del negocio. Controlador: Es el que supervisa todas las acciones del sistema y realiza la conexión entre el modelo y la vista Vista: Es el responsable de la presentación audiovisual de los datos de salida, así como de representar una interface para la entrada de datos.

Fig. 10. Diagrama Arquitectura MVC. Fuente: [8]

Este tipo de arquitectura se destaca por ser efectiva para aplicaciones que utilizan muchas ventanas sincronizadas con un mismo modelo de datos, de igual manera, estas se pueden separar/incorporar fácilmente al sistema. Por otro lado, la fuerte dependencia de dichas ventanas/controladores con el modelo limita la posibilidad de modificar estos últimos por los costos que conllevaría.

2.4.2.

Presentation - Abstraction – Control Presenta similitudes con MVC en lo que respecta a funciones, sin embargo, la comunicación es diferente. En PAC no hay comunicación directa de la presentación con la abstracción, sino que ambos convergen al control. En sistemas de múltiples agentes, se sigue una jerarquía específica. Como muestra Fig.11, Los agentes de alto nivel se encargan de la administración de los datos y la lógica del negocio, los de medio nivel coordinan los agentes de bajo nivel, estos últimos se encargan de definir detalladamente la presentación de los datos. [8]

Fig. 11. Diagrama de Arquitectura PAC con múltiples agentes. Este tipo de arquitectura es útil para sistemas distribuidos, cuyos componentes están distantes y poseen una función específica dentro del sistema.

2.5.

Arquitectura orientada a Sistemas distribuida

En esta arquitectura, el sistema distribuye sus componentes que están sobre una plataforma determinada. Estos tienen la capacidad de comunicarse y trabajar con otros componentes en aras de lograr un objetivo específico. De esta arquitectura son destacables características como: aprovechamiento de recursos (hardware/software), concurrencia, escalabilidad y tolerancia a fallos. Sin embargo, este tipo de arquitectura, a una gran escala suele tornarse compleja. La cantidad de componentes y conexiones es tal que se requiere una fuerte inversión en control y seguridad. 2.5.1.

Arquitectura Cliente-Servidor Este tipo de arquitectura es la más común en sistemas distribuidos. Descompone el sistema en dos grandes procesos: cliente, primer proceso que hace una petición al segundo proceso, y servidor: segundo proceso que recibe la petición y devuelve una respuesta al cliente.

Fig. 12. Diagrama de clientes comunicándose con un servidor a través de Internet La aplicación es vista como una serie de servicios que ofrece un servidor que son consumidos por una serie de clientes. Los servidores no necesitan saber mucho acerca de los clientes, pero estos últimos deben conocer la identidad del servidor para establecer una conexión. [8] En esta arquitectura pueden darse dos casos particulares basados en la funcionalidad del cliente: 

Cliente fino (Thin Client): Este tipo de cliente solo cumple con funciones de ejecución del software de presentación, mientras que el servidor se encarga de la gestión y procesamiento de la información [2]. Se destaca por ser útil en aplicaciones de red pequeñas donde el

tráfico de información es relativamente pequeño por lo que la misma aplicación puede actuar como servidor [12]. 

2.5.2.

Cliente Grueso (Thick/Fat Client): Este tipo de cliente tiene más responsabilidades que el cliente fino. Mientras que el servidor solo es responsable de la administración de los datos, el software del cliente implementa toda la lógica y la presentación de información al usuario. [12]. Si bien este tipo de arquitectura distribuye mejor el procesamiento, el estructurar la red con demasiados clientes pesados

Arquitectura multicapa (Multi-tier Architecture) Esta arquitectura es similar a la de cliente-servidor en lo que respecta a los roles que existen en la misma, sin embargo, se diferencia en que cada una de las funciones (presentación, control y administración de datos están separados. Esto permite que el acoplamiento de nuevas capas o subcapas se realice de forma sencilla, así como la oportunidad de crear plantillas útiles para otras aplicaciones.

Fig. 13. Diagrama Arquitectura Multicapa. Fuente: [8]

Esta arquitectura se caracteriza por tener mejor rendimiento y mayor simplicidad que la del thin-client, es fácilmente escalable en la medida que se agreguen más servidores y la capa de procesamiento de la aplicación, dada su centralidad, es fácilmente modificable.

Fig. 14. Cuadro comparativo Arquitecturas orientadas a sistemas distribuidos 2.5.3.

Peer-to-peer (P2P) Es un tipo de arquitectura que permite la comunicación directa de clientes/peers sin necesidad de un servidor (véase Fig 15) . Es la arquitectura usada por Skype para ofrecer servicios de VoIP, por el navegador Tor para dar anonimato a sus clientes [13], sistemas de mensajería instantánea, sistemas para compartir archivos [2]. Su gran ventaja es que permite sacar provecho de los recursos de cada nodo (cliente) para ofrecer servicios a otros nodos, por lo que los servidores no sobresaturan, cosa que suele pasar en sistemas centralizados.

Fig. 15. Comparación entre arquitectura basada en servidor y P2P. Fuente: [14] Esta arquitectura tiene dos variantes: 

Arquitectura Descentralizada: El enlace de los nodos es arbitrario y no hay una jerarquización en la red que estos componen. Las peticiones



en este tipo de arquitecturas suelen tardar mucho ya que tiene que recorrer nodo a nodo toda la red para encontrar aquel/aquellos que puedan ofrecer los servicios requeridos. Arquitectura Semicentralizada: La red global se divide en localidades, se hace uso de un DHT (Distributed Hash Table) que asigna determinadas responsabilidades a determinados nodos, luego cuando un usuario realiza una petición, esta se puede redirigir para hacerla más rápida y efectiva.

Esta arquitectura es fuertemente criticada por ser la utilizada en la transferencia ilegal de archivos, lo que viola los derechos de propiedad de usuarios. Adicionalmente, es muy susceptible a la entrada de malware y robo de información. 2.5.4.

Arquitectura orientada a servicios (SOA) Esta arquitectura tiene como base un diseño de tipo cliente/servidor con enfoque empresarial que busca ofrecer servicios de software a consumidores de servicios de software por medio de una aplicación. [8] Estos servicios son independientes y accesibles a través de una interfaz de servicio web por medio de un protocolo específico. La SOA, como se muestra en Fig. 16. Tiene los siguientes componentes:  

Proveedor de servicios: Quienes desarrollan y ofertan servicios a los clientes. Solicitante de servicios: Quien consume el servicio y lo enlaza con su aplicación

Fig. 16. Diagrama Arquitectura SOA. Fuente: [12]

“Los servicios Web se basan en un conjunto de estándares de comunicación, como son XML para la representación de datos, SOAP (Simple Object Access Protocol) para el intercambio de datos, y el lenguaje WSDL (Web Services Description Language) para describir las funcionalidades de un servicio Web.”[16]

Bibliografía [1].

C. Acuña, "Arquitecturas de Software", Pontificia Universidad Javeriana, 2017. [Online]. Available: http://pegasus.javeriana.edu.co/~mad/Arquitecturas%20de%20SW.pdf. [Accessed: 17- Aug- 2017].

[2].

"Arquitectura de Software", Facultad de Ingeniería, Universidad de la República, 2017. [Online]. Available: https://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is05ArquitecturaDeSoftware.pdf. [Accessed: 14- Aug- 2017].

[3].

“Estilos arquitectónicos - EcuRed", Ecured.cu, 2017. [Online]. Available: https://www.ecured.cu/Estilos_arquitect%C3%B3nicos. [Accessed: 15- Aug2017].

[4].

C. Bustacara, "Estilos Arquitectónicos", Diseño y evaluación de Arquitecturas de Software, 2017. [Online]. Available: https://sophia.javeriana.edu.co/~cbustaca/docencia/DEAS-201503/presentaciones/Estilos_arquitecturales.pdf. [Accessed: 16- Aug- 2017].

[5].

C. Bastarrica, "Material Docente :: CC61H-1 Seminario Arquitectura de Software", U-Cursos, 2008. [Online]. Available: https://www.ucursos.cl...