Estilos y Patrones Arquitectónicos

Transcripción

1 Lic. Ariel Trellini Estilos y Patrones Arquitectónicos Llamando a las cosas por su nombre Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Arquitectura y Diseño de Sistemas 2 Bibliografía Software Architecture - Foundations, Theory and Practice Taylor, Medvidovic, Dashofy Wiley Software Architecture in Practice 3rd Edition Bass, Clements, Kazman Addison-Wesley Introducción Arquitectura de Software Cómo un sistema se puede descomponer de la mejor forma posible Cuáles son sus componentes Cómo se comunican dichos componentes Cómo fluye la información Cómo los elementos de un sistema pueden evolucionar independientemente Cómo se puede describir todo esto a través de notaciones formales e informales A medida que los ingenieros de software fueron construyendo diferentes sistemas a lo largo de muchos dominios de aplicación, observaron que, bajo determinadas circunstancias, ciertas decisiones de diseño regularmente resultan en soluciones con propiedades superiores: más elegantes, efectivas, eficientes, confiables, evolucionables y escalables. Esta experiencia y conocimiento común se generalizó y fue adoptando distintas formas dependiendo del contexto de aplicación con el fin de ser reutilizado: arquitecturas de software específicas de un dominio, estilos arquitectónicos y patrones arquitectónicos Arquitectura y Diseño de Sistemas 3 Arquitectura y Diseño de Sistemas 4 Definiciones Límites difusos Guía de alto nivel El eje de scope no es tan lineal como parece Definiciones Patrones de Diseño La comunidad OO ha estado explorando el uso de patrones de diseño para describir abstracciones recurrentes en el desarrollo de software basado en objetos Generalmente en el marco de la Orientación a Objetos Se concentran en soluciones de diseño comunes aplicables a nivel de clases, procedimientos y estructuras de datos. Expresan esquemas para definir estructuras de diseño y sus relaciones con las que construir un componente de software. Catálogos más conocidos GoF: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, Vlissides) GRASP: General Responsibility Assignment Software Patterns (Craig Larman) Arquitectura y Diseño de Sistemas 5 Arquitectura y Diseño de Sistemas 6 1

2 Definiciones Definiciones Arquitectura de Software Específica de un Dominio (DSSA) Nuclea conocimiento sustancial, adquirido a partir de una extensa experiencia, sobre cómo estructurar aplicaciones completas dentro de un dominio particular. Desde el punto de vista operacional, podría definirse como la combinación de: La arquitectura de referencia para un dominio de aplicación Una librería de componentes de software para dicha arquitectura, conteniendo componentes reusables basados en la experiencia en el dominio Un método para elegir y configurar los componentes para que trabajen dentro de una instancia de la arquitectura de referencia. Están íntimamente relacionadas con las arquitecturas para una familia de productos ( recuerdan el caso de estudio de Phillips?) Están especializadas para un dominio particular y sólo son valiosas para aplicaciones dentro de dicho dominio Estilos Arquitectónicos Un estilo arquitectónico es una colección de decisiones de diseño arquitectónicas que tiene un nombre específico y que: 1. Es aplicables a un contexto de desarrollo dado 2. Restringe decisiones de diseño arquitectónicas que son específicas a un sistema particular dentro de aquel contexto 3. Elicita cualidades beneficiosas en cada sistema resultante Taylor, Medvidovic and Dashofy Son la forma de caracterizar lecciones aprendidas en el diseño de sistemas de software Proveen decisiones de diseño generales que restringen y pueden necesitar ser refinadas en decisiones de diseño y más específicas para que sean aplicadas en un sistema. Arquitectura y Diseño de Sistemas 7 Arquitectura y Diseño de Sistemas 8 Definiciones Definiciones Estilos Arquitectónicos (cont.) Propiedades Un vocabulario para los elementos de diseño Tipos de componentes y conectores Por ejemplo: clases, invocaciones, pipes, clientes, etc. Reglas de composición Un estilo tiene restricciones topológicas que determinan cómo se puede hacer la composición de los elementos Por ejemplo: los elementos de un layer se pueden comunicarse sólo con los del layer inferior Semántica para esos elementos Beneficios Reúso de diseños Soluciones maduras aplicadas a problemas nuevos Una parte importante del código que implementa la arquitectura puede pasarse de un sistema a otro Comunicación más efectiva Portabilidad de soluciones Estilos Arquitectónicos (cont.) Ejemplo: El siguiente conjunto de decisiones de diseño asegura la provisión efectiva de servicio a múltiples usuarios del sistema en un ambiente distribuido Separar físicamente los componentes de sw usados para requerir servicios de aquellos usados para proveer servicios, con el objetivo de proveer una distribución y escalamiento apropiados (tanto en la cantidad de proveedores de servicio como de solicitantes de servicios) Aislar a los solicitantes unos de otros para permitir que sean agregados o eliminados independientemente. Hacer que los solicitantes sólo dependan de los proveedores de servicio Qué estilo arquitectónico se está describiendo? Hacer que los proveedores no tengan conocimiento sobre la identidad de os solicitantes para permitir que los sirvan transparentemente a muchos (posiblemente cambiantes) solicitantes Permitir que múltiples proveedores de servicios se creen de forma dinámica para sacar carga a los proveedores existentes si la demanda de servicios aumenta por encima de un determinado umbral Cliente - Servidor Arquitectura y Diseño de Sistemas 9 Arquitectura y Diseño de Sistemas 10 Definiciones Definiciones Patrones Arquitectónicos Un patrón arquitectónico es una colección de decisiones de diseño arquitectónicas que tiene un nombre específico y que son aplicables a problemas de diseño recurrentes, y son parametrizadas para tener en cuenta diferentes contextos de desarrollo de software en los cuales el problema aparece. Taylor, Medvidovic and Dashofy Provee un conjunto de decisiones específicas de diseño que han sido identificadas como efectivas para organizar ciertas clases de sistemas de sw o, más típicamente, subsistemas específicos. Estas decisiones de diseño pueden pensarse como configurables, ya que necesitan ser instanciadas con los componentes y conectores particulares a una aplicación. Cuáles son las diferencias entre estilos arquitectónicos y patrones arquitectónicos? Los dos conceptos son similares y no siempre es posible identificar un límite nítido entre ellos. Alcance Abstracción Relación Estilos Arquitectónico Aplican a un contexto de desarrollo: sistemas altamente distribuidos, sistemas intensivos en GUI Son muy abstractos para producir un diseño concreto del sistema. Un sistema diseñado de acuerdo a las reglas de un único estilo puede involucrar el uso de múltiples patrones Patrones Arquitectónico Aplican a problemas de diseño específicos: El estado del sistema debe presentarse de múltiples formas La lógica de negocio debe estar separada del acceso a datos Son fragmentos arquitectónicos parametrizados que pueden ser pensados como una pieza concreta de diseño. Un único patrón puede ser aplicado a sistemas diseñados de acuerdo a los lineamientos de múltiples estilos Arquitectura y Diseño de Sistemas 11 Arquitectura y Diseño de Sistemas 12 2

3 Estilos Arquitectónicos Repasaremos la propuesta en Software Architecture, Foundations Theory and Practice Estilos Simples Traditional Language-Influenced Styles Main Program and Subroutines Object-Oriented Shared Memory Blackboard Rule-Based Interpreter Intepreter Mobile Code Layered Virtual Machines Client-Server Implicit Invocation Publish-Subscriber Event Based Dataflow Styles Batch-Sequential Pipe and Filters Peer to Peer Juego popular en los años 70 Reglas El piloto controla el descenso de un lunar lander estilo Apollo Controla la aceleración del descenso Combustible limitado Altitud inicial y preseteadas Si aterriza con una de descenso < 5, gana aunque no tenga combustible Estilos Complejos C2 Distributed Objects Arquitectura y Diseño de Sistemas 13 Arquitectura y Diseño de Sistemas 14 Estilos Influenciados por el Lenguaje Main Program and Subroutines Influenciado por la Programación Estructurada Envío de mensaje / respuesta Se cede el control y se espera la respuesta Main Sub1 Sub1 Sub1 Main Program and Subroutine Descomposición basada en la separación de pasos de procesamiento funcionales Programa principal y subrutinas Llamadas a procedimientos / funciones Valores de entrada/salida de las subrutinas La organización estática de los componentes es jerárquica. La estructura es un grafo dirigido Ninguna Modularidad: Las subrutinas pueden ser reemplazadas con diferentes implementación mientras su interfaz no sea afectada Pequeños programas. Uso pedagógico. Generalmente falla al escalar a grandes aplicaciones Inadecuada atención a estructuras de datos Requiere bastante esfuerzo para introducir nuevos requerimientos Reuso limitado de funciones y procedimientos Arquitectura y Diseño de Sistemas 15 Arquitectura y Diseño de Sistemas 16 Main Program and Subroutine Object Oriented Diseño basado en descomposición funcional Programa principal Muestra saludos e instrucciones Cicla llamando a los componentes Promueve el uso de las principales características de la OO Information hiding Encapsulamiento Herencia / Polimorfismo In: - Out: aceleración In: altitud, aceleración, combustible, tiempo, Out: altitud, combustible, In: altitud, combustible, tiempo, Out: - Information Hiding: Las decisiones de diseño que es probable que cambien, son ocultadas en un módulo o conjunto de pequeños módulos Parnas, 1972 Arquitectura y Diseño de Sistemas 17 Arquitectura y Diseño de Sistemas 18 3

4 Object Oriented Object Oriented Estado y funciones (sobre dicho estado) encapsulados en objetos. Los objetos deben ser instanciados antes que sus métodos sean invocados. Objetos (instancias de las clases) Invocación a métodos (llamadas a procedimientos para manipular el estado) Parámetros de los métodos Puede variar. Los componentes pueden compartir datos y funciones a través de jerararquías de herencia Generalmente, memoria compartida (para soportar el uso de punteros). Único thread (por defecto) Conocer la identidad de los objetos Integridad de las operaciones sobre los datos (están co-localizadas) Abstracción: Ocultamiento de los detalles de implementación Reuso a gran escala Correspondencia con objetos del dominio CALCULAR In: Velocidad de combustión, Spacecraft Out: Spacecraft Correlación entre las entidades en el mundo real y las entidades en la app. Apps que tienen estructuras de datos complejas y dinámicas. El uso en aplicaciones distribuidas requiere acceso remoto a los objetos. Relativa ineficiencia para apps de alta performance Carencia de principios de diseño resulta en apps altamente complejas. No todo es un objeto GET altitud, combustible, tiempo y SET altitud, combustible, tiempo y Arquitectura y Diseño de Sistemas 19 Arquitectura y Diseño de Sistemas 20 Layered Styles Virtual Machine Una capa ofrece un conjunto de servicios Dichos servicios pueden ser accedidos por programas que residen en la capa superior Encapsula la implementación de los servicios de la capa Dos modos Estricto No estricto Virtual Machine Secuencia ordenada de capas. Cada capa (virtual machine) ofrece servicios a subcomponentes de la capa encima de ella. Capas, generlamente conteniendo subcomponentes Llamadas a procedimientos Parámetros pasados entre las capas Lineal Ninguna Dependencias claras y acotadas Encapsulamiento Basado en niveles de abstracción Reusabilidad, Portabilidad Sistemas Operativos Stacksde protocolos de red Aplicaciones empresariales Performance No siempre se puede encontrar la abstracción correcta Arquitectura y Diseño de Sistemas 21 Arquitectura y Diseño de Sistemas 22 Virtual Machine Client-Server Múltiples clientes independientes accediendo al mismo server Especialización de Virtual Machine de 2 capas: Capa 1: Client Capa 2: Server Conexión por red Clients conocen al Server Server no conoce a los Clients Arquitectura y Diseño de Sistemas 23 Arquitectura y Diseño de Sistemas 24 4

5 Client Server Clientes le envían requerimientos al servidor, el cual los ejecuta y envía la respuesta (de ser necesario). La comunicación es iniciada por el cliente. Clientes y Servidor Llamadas a procedimientos remotos (o equivalente) Parámetros y valores de retorno Dos niveles. Múltiples clientes haciendo requerimientos al server Prohibida la comunicación entre clientes Sencilla y muy utilizada Centralización de cómputos y datos en el server. Mantenible Apps con datos y/ o procesamiento centralizados y clientes GUI Stacksde protocolos de red Aplicaciones empresariales Condiciones de la red vs crecimiento de clientes. Client - Server Multiplayer Arquitectura y Diseño de Sistemas 25 Arquitectura y Diseño de Sistemas 26 Dataflow Styles Características La estructura del sistema está basada en transformaciones sucesivas a datos de input. Los datos entran al sistema y fluyen a través de los componentes hasta su destino final. Los componentes son de runtime Normalmente un programa controla la ejecución de los componentes (lenguaje de control) Batch-Sequential Programas separados y ejecutados en orden. Los datos son pasados como un lote de un programa al siguiente. Programas independientes Distintos tipos de interfaces: desde humana hasta web services Lotes de datos pasados de un programa al siguiente. Lineal Se ejecuta un programa a la vez, hasta que termina. Sencillez Ejecuciones independientes Procesamiento de transacciones en sistemas financieros Cuando se requiere interacción entre componentes. Cuando se requiere concurrencia entre componentes. Arquitectura y Diseño de Sistemas 27 Arquitectura y Diseño de Sistemas 28 Batch-Sequential Ejemplo: Viejo procesamiento de transacciones financieras Arquitectura y Diseño de Sistemas 29 5