Diego Seco Material adaptado de: Miguel R. Luaces y Óscar Pedreira {luaces, Laboratorio de Bases de Datos Universidade da Coruña

Transcripción

1 Diego Seco Material adaptado de: Miguel R. Luaces y Óscar Pedreira {luaces, opedreira}@udc.es Laboratorio de Bases de Datos Universidade da Coruña

2 Definición de patrón: Christopher Alexander y otros, A PatternLanguage, 1977 cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a ese problema, de tal modo que se pueda aplicar esta solución un millón de veces sin hacer lo mismo dos veces Diseño con patrones

3 Diseño con patrones Patrones Cada patrón presenta un diseño importante y recurrente Los patrones son experiencias de diseño de sistemas que pueden ser reutilizadas por otras personas Facilitan reutilizar buenos diseños y arquitecturas

4 Tipos de patrones Patrones de diseño Patrones de arquitectura Patrones de análisis de requisitos Etc. Diseño con patrones

5 Patrones de Arquitectura Introducción

6 Principios arquitectónicos clave Separación de la funcionalidad Introducción Dividir la aplicación en bloques funcionales independientes Minimizar los puntos de interacción con un acoplamiento pequeño Responsabilidad única Cada módulo debe ser responsable de una funcionalidad específica y concreta No repetición Una funcionalidad no debe estar implementada de forma repetida en varios módulos

7 Principios arquitectónicos clave Conocimiento mínimo Principle of Least Knowledge / Law of Demeter Introducción Un módulo no debe conocer los detalles internos de otros módulos Minimizar el esfuerzo de diseño Si el riesgo y las consecuencias de un fallo son elevadas, gran esfuerzo en diseño Si los requisitos no son claros o los cambios previsibles, mínimo esfuerzo en diseño

8 Principios arquitectónicos clave Consistencia interna El diseño de los módulos debe ser consistente Los patrones deben aplicarse de forma similar Utilizar composición antes que herencia Introducción La reutilización de funcionalidad mediante composición crea una dependencia menos fuerte que la herencia Comunicación simple y explícita entre capas No permitir que todas las capas se comuniquen con todas Decidir de forma explícita la estructura de las capas

9 Principios arquitectónicos clave Introducción Utilizar la abstracción para minimizar el acoplamiento El patrón fachada oculta la complejidad de subsistemas Los patrones factoría ocultan la complejidad de clases y objetos El patrón mediador oculta las interacciones entre objetos Separar la funcionalidad transversal de la de negocio Seguridad, comunicación, autenticación, registro de errores, etc. son funcionalidades transversales Mezclar estas funcionalidades con las de negocio complican la arquitectura Los marcos de desarrollo actuales proporcionan módulos para ocuparse de esta funcionalidad

10 Introducción Componentes de un patrón arquitectónico Determina un vocabulario de componentes y conectores que pueden ser usados juntos y un conjunto de restricciones (topológicas, semánticas, etc.) a cómo se pueden combinar Proporciona un lenguaje común independiente de la tecnología

11 Resumen de los patrones arquitectónicos Introducción Patrón Cliente / servidor Descripción Divideel sistema en dos aplicaciones. El cliente envía peticiones al servidor Arquitectura en capas 3-capas/ n-capas Dividela funcionalidad en capas separadas y apiladas Similar a la arquitectura en capas, pero asignando cada capa a un servidor independiente

12 Resumen de los patrones arquitectónicos Introducción Patrón Descripción Arquitectura basada en componentes Descompone el sistema en componentes reusables con interfaces definidos Diseño dirigidopor el dominio Orientada a objetos Modela el dominio de negocio mediante entidades y objetos que las manipulan División de las responsabilidades del sistema en objetos reusables e independientes compuestos por datos y funcionalidad

13 Resumen de los patrones arquitectónicos Introducción Patrón Bus de mensajes Arquitectura orientada a servicios Descripción Centrada en un componentesoftware para intercambiar mensajes sin necesidad de conocer los detalles de los componentes La funcionalidad de la aplicación se expone y consume a través de serviciosque usan contratos y mensajes

14 Resumen de los patrones arquitectónicos Introducción Ámbito Comunicación Despliegue Estructura Dominio Patrones Orientada a servicios Bus de mensajes Cliente / servidor 3-capas / n-capas Cliente / servidor 3-capas / n-capas Arquitectura en capas Basada en componentes Orientada a objetos Dirigida por el dominio

15 Combinación de patrones arquitectónicos Introducción La arquitectura de un sistema no suele seguir un único patrón, si no la combinación de varios Por ejemplo, Una arquitectura orientada a capas puede combinarse con una arquitectura orientada a servicios Los patrones de estructura no indican cómo modelar los objetos del dominio Una aplicación puede seguir el patrón cliente / servidor o una arquitectura en capas en función de la infraestructura de la organización

16 Arquitectura cliente / servidor

17 Arquitectura cliente / servidor Cliente 1 Petición Cliente 2 Respuesta Petición Respuesta Servidor Petición Cliente 3 Respuesta Datos

18 Arquitectura cliente / servidor También denominada arquitectura de 2 capas Ejemplos de esta arquitectura: Aplicación de escritorio / servidor de bases de datos Navegador web / servidor web Cliente de correo / servidor de correo Ventajas: Acceso centralizado a los datos Mayor facilidad a la hora de administrarlos Incremento de seguridad Sólo es necesario proteger el servidor y la transmisión Facilidad de mantenimiento y escalado La replicación del servidor es transparente a los clientes

19 Desventajas Arquitectura cliente / servidor Los datos y la lógica del negocio se mezclan en el servidor, lo que afecta a la escalabilidad y la extensibilidad El servidor es un punto único de fallo Raramente usada en la actualidad La mezcla de datos y lógica de negocio se resuelve con una arquitectura basada en capas El punto único de fallo del servidor se resuelve con arquitecturas de basadas en capas o arquitecturas orientadas a servicios

20 Arquitectura basada en capas

21 Arquitectura basada en capas Capa 1 Petición Petición Petición Petición Capa 2 Capa Capa n-1 Capa n Respuesta Respuesta Respuesta Respuesta Datos

22 Arquitectura basada en capas Funcionamiento: Cada capa agrupa funcionalidad relacionada Las capas se apilan verticalmente entre los usuarios y los datos La comunicación entre capas es explícita mediante interfaces bien definidos y débilmente acoplada Los componentes de una capa sólo pueden interactuar entre sí o con los de la capa inferior

23 Arquitectura basada en capas Principios de diseño Abstracción y encapsulación Cada capa abstrae toda la funcionalidad que incluye y sólo es necesario entender su interfaz No es necesario preocuparse de los detalles de implementación de la capa ni de sus componentes Comunicación sencilla La comunicación es sencilla. Las ordenes viajan hacia abajo por la pila de capas, y las respuestas retornan hacia arriba Alta cohesión, acoplamiento bajo y claridad funcional Cada capa tiene una funcionalidad clara y acotada El envío de peticiones a capas inferiores se realiza mediante un interfaz claro Las respuestas se reciben directamente o mediante eventos (patrón Observador)

24 Ventajas Abstracción Arquitectura basada en capas Cada capa se define de forma abstracta antes de empezar la implementación La pila jerárquica permite aumentar el nivel de abstracción en cada paso Aislamiento Las capas son independientes. La tecnología de su implementación puede variar sin afectar a las demás Manejabilidad Las dependencias son claras y explícitas, con lo que los cambios son fácilmente localizables Rendimiento Las capas se pueden distribuir en varios sistemas para mejorar la escalabilidad, tolerancia a fallos y rendimiento Reutilización Las capas inferiores no tienen dependencias con las superiores, permitiendo su uso potencial en otros escenarios Capacidad de prueba Los interfaces claros y definidos permiten construir simuladores de las capas

25 Desventajas Arquitectura basada en capas El patrón no describe el despliegue de las capas (otros como laarquitectura en 3 capas, sí) Problemas de rendimiento debido a la sobrecarga de llamadas entre las capas Aumento en el coste de desarrollo debido a la necesidad de implementar nueva funcionalidad en todas las capas Cambiosen los niveles inferiores pueden provocar cambios en los niveles superiores

26 Arquitectura en 3 capas / n capas

27 Arquitectura en 3 capas / n capas Funcionamiento Patrón similar a la arquitectura basada en capas Cada capa debe ubicarse en un servidor independiente La jerarquía de capas es rígida. Sólo se conoce la capa inmediatamente inferior La comunicación entre capas suele ser asíncrona para mejorar la escalabilidad Es común considerar 3 capas: Acceso a datos / modelo Lógica de negocio / controlador Presentación al usuario / vista

28 Arquitectura en 3 capas / n capas Ventajas Mantenibilidad. La independencia de las capas hace que los cambios internos no afecten a las otras capas Escalabilidad y flexibilidad. Debido a la asignación de capas a servidores Inconvenientes Aumenta el tráfico de red, la necesidad de balanceado de carga, y la tolerancia a fallos

29 Arquitectura orientada a objetos

30 Funcionamiento Arq. orientada a objetos La funcionalidad del sistema se divide en objetos reusables y autocontenidos Los objetos son independientes y se comunican invocando métodos de otros objetos Menos abstracción y más rigidez formal que arq. basada en componentes Usada como lenguaje para la arq.dirigida por el dominio

31 Principios básicos Arq. orientada a objetos Abstracción.Clases y métodos pueden ser genéricos con múltiples implementaciones Composición. Los objetos pueden construirse con otros objetos Herencia.Los objetos pueden especializar otros objetos ampliando y modificando su comportamiento Polimorfismo. Una especialización de un objeto o una implementación de una abstracción pueden ser utilizado en lugar del original Encapsulación.Los objetos solo pueden ser utilizados a través de aquellos métodos y propiedades públicas Ventajas Reutilización y extensibilidad (debido a los principios básicos) Cercanía al lenguaje del dominio

32 Arquitectura basada en componentes

33 Arq. basada en componentes Componente Respuesta Petición Componente Petición Respuesta Componente Petición Respuesta Componente Petición Petición Respuesta Componente Respuesta Petición Respuesta Componente

34 Funcionamiento Arq. basada en componentes Descomposición del sistema en componentes funcionales Interfaces de comunicación definidos Compuestos por métodos, eventos y propiedades Principios básicos Reusabilidad. Componentes diseñados para una tarea Reemplazabilidad.Sustituibles por componentes similares Independientes del contexto.el estado del entorno debe ser pasado al componente, no almacenado

35 Arq. basada en componentes Principios básicos Extensibilidad. Un componente puede extender la funcionalidad de uno existente Encapsulamiento. Los componentes no revelan los detalles internos del funcionamiento Independencia.Las dependencias con otros componentes deben ser mínimas. Ventajas Facilidad de despliegue (por la reemplazabilidad, el encapsulamiento, la independencia) Coste y esfuerzo reducido (usando componentes de terceros) y reusabilidad (definiendo componentes)

36 Ventajas Arq. basada en componentes Reducción de complejidad técnica (utilizando entornos de ejecución de componentes) Ejemplos Distributed Component Object Model (Windows) En la actualidad,.net Framework Remoting, Assemblies, Metadata Common Language Runtime, Common Type System, Global Assembly Cache, Microsoft Intermediate Language, Windows Forms ADO.NET, ASP.NET Windows Communication Foundation(WCF) Windows Presentation Foundation(WPF) Windows Workflow Foundation(WF) Windows CardSpace(WCS) Windows PowerShell

37 Ejemplos Arq. basada en componentes Enterprise JavaBeans (EJB) Comunicación remota utilizando CORBA Transacciones Control de la concurrencia Eventos utilizando JMS (Java messaging service) Servicios de nombres y de directorio Seguridad Ubicación de componentes en un servidor de aplicaciones Patrones relacionados Dependency Injection Service Locator

38 Arquitectura orientada a servicios

39 Arq.orientada a servicios Aplicación Petición Respuesta Petición Respuesta Servicio Respuesta Petición Servicio Petición Respuesta Servicio Petición Respuesta Servicio Servicio

40 Funcionamiento Arq. orientada a servicios La funcionalidad de la aplicación se implementa mediante servicios con estas características Autónomos. Se desarrolla y despliega independientemente Distribuíbles.Un servicio se ubica en cualquier lugar de la red Débilmente acoplados. La dependencia entre servicios es sólo a nivel de interfaz Políticas definidas. Existe un contrato de lo que hace el servicio, un esquema de los datos utilizados, y un acuerdo en el protocolo Protocolos para servicios Simple Object Access Protocol(SOAP) XML Remote Procedure Call (XML-RPC) Representationtal State Transfer (REST)

41 Ventajas Arq.orientada a servicios Modularidad, reusabilidad y abstracción Interoperabilidad. Los protocolos de comunicación son independientes de la tecnología Flexibilidad. El despliegue es variable y los servicios pueden ser encontrados por su contrato

42 Arquitectura dirigida por el dominio

43 Arq. dirigida por el dominio SGBD Visor HTML Servicio REST Capa de aplicación Dominio Ca apa de datos Enterprise Service Bus Otros sistemas Otros sistemas

44 Funcionamiento Arq. dirigida por el dominio Definir un modelo del dominio que describa con el máximo detalle posible el problema Usando conceptos del modelo, definir un lenguaje que permita comunicar a los expertos con los desarrolladores Convertir el modelo en el centro de la arquitectura, y hacer fronterizos al resto de elementos Ventajas Incluye a los expertos y los usuarios El alineamiento con el problema es muy alto

45 Problemas Arq. dirigida por el dominio Para que los cambios del modelo no impliquen grandes cambios en el resto del sistema, es necesario mucha abstracción Es muy difícil que los conceptos del modelo no pasen al resto de capas Patrones y técnicas relacionadas Model-driven architecture and engineering Aspect-oriented programming Patrón Naked objects

46 Arquitectura con bus de mensajes

47 Arq. con bus de mensajes Aplicación Aplicación Petición Respuesta Petición Respuesta Bus de mensajes Petición Respuesta Petición Respuesta Servicio Petición Respuesta Servicio Servicio

48 Funcionamiento Arq. con bus de mensajes Existe una pieza de software denominada bus de mensajes (Enterprise Service Bus, ESB) Permite el descubrimiento de servicios Los servicios se registran en el bus y publican su contrato Las aplicaciones conectan con el bus y buscan un servicio que cumpla un contrato El bus indica a las aplicaciones los servicios existentes Comunicación basada en el patrón Publish/ Subscribe Las aplicaciones publican en el ESB un mensaje de una clase específica Los servicios están suscritos a mensajes de una clase específica

49 Principios básicos Arq. con busde mensajes Admite servicios basadosen muchos protocolos distintos Permite la orquestación de servicios mediante composición Ventajas Reduce la complejidad de las aplicaciones No conocen más protocolos que la comunicación con el ESB No conocen detalles de despliegue

50 Diego Seco Material adaptado de: Miguel R. Luaces y Óscar Pedreira {luaces, opedreira}@udc.es Laboratorio de Bases de Datos Universidade da Coruña