1 / 45

Arquitecturas flexibles y adaptables: ¿hacia dónde vamos?

Jorge A. Villalobos jvillalo@uniandes.edu.co. Arquitecturas flexibles y adaptables: ¿hacia dónde vamos?. “No hay nada permanente, excepto el cambio” - Heráclito -. Motivación. La manera como se espera que evolucione el software ha evolucionado. Motivación.

evania
Download Presentation

Arquitecturas flexibles y adaptables: ¿hacia dónde vamos?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Jorge A. Villalobos jvillalo@uniandes.edu.co Arquitecturas flexibles y adaptables: ¿hacia dónde vamos?

  2. “No hay nada permanente, excepto el cambio” • - Heráclito -

  3. Motivación • La manera como se espera que evolucione el software ha evolucionado

  4. Motivación • Algunos retos para un arquitecto: • Aplicaciones de alta disponibilidad • Arquitecturas reactivas • Aplicaciones con un alto volumen de usuarios • Fábricas de software y líneas de producción • Arquitecturas de integración • …

  5. Motivación • Es un problema de hoy, con muchos frentes abiertos de trabajo …

  6. Motivación • Una inquietud vieja: • R.S. Fabry : “How to design a system in which modules can be changed on the fly”, Proc. 2nd lnt. Conf. on Soft. Eng., (1976).

  7. Agenda • Evolución = mantenimiento • Arquitecturas flexibles • Adaptación • Aplicaciones dinámicas • Auto-adaptación • Integración y evolución • Conclusiones

  8. Evolución = mantenimiento evolución: el iceberg desarrollo mantenimiento  80% Una lección aprendida

  9. Evolución • Visión clásica del mantenimiento: • algo cambia en el problema • se modifica el programa (algo monolítico) • se remplaza el programa anterior por el nuevo • si hay necesidad se reestructuran los datos • Requerimientos sobre la arquitectura: • localización • aislamiento

  10. Propiedades deseables • Localización: dado un elemento del problema, se puede localizar su representación en el programa mundo M programa Requerimientos funcionales

  11. Propiedades deseables • Aislamiento: un cambio en un elemento del programa tiene una frontera de impacto conocida (predecible) programa

  12. El reto de la época • Buscar una buena manera de estructurar una aplicación: • funciones (descomposición funcional) • objetos • En la búsqueda de buenas metodologías, lenguajes y herramientas • Se producen arquitecturas rígidas, pero mantenibles

  13. Arquitecturas rígidas diseño construcción arranque mundo M programa Requerimientos funcionales implementación instalación ejecución análisis Las decisiones arquitecturales se toman en la etapa de diseño, y hacen referencia a elementos computacionales concretos

  14. Arquitecturas rígidas • Y qué pasó? • En algunos casos es suficiente con una arquitectura rígida, pero fácil de mantener • En otros casos es insuficiente: • El problema cambió • Aparecieron los requerimientos no funcionales • Insuficientes las funciones y los objetos • Las expectativas de los clientes cambiaron • La evolución sucede cada vez más rápido

  15. Agenda • Evolución = mantenimiento • Arquitecturas flexibles • Adaptación • Aplicaciones dinámicas • Auto-adaptación • Integración y evolución • Conclusiones

  16. Motivación • Se puede hacer evolucionar un programa, sin cambiar su código • “Distintas maneras de hacer lo mismo” • Se debe poder utilizar información de etapas posteriores al diseño para definir la arquitectura • “Una familia de arquitecturas posibles”

  17. “Distintas maneras de hacer lo mismo” • Ejemplos: • Balanceo de carga • Aplicaciones basadas en web services • Plug and play • Jini • Servidores de nombres • Archivos de configuración • … • El caso Dassault Systèmes

  18. Arquitecturas flexibles programa diseño construcción arranque implementación instalación ejecución Cómo? Aplazando decisiones para utilizar información de las etapas posteriores del ciclo de vida

  19. En la búsqueda de flexibilidad • Qué implica? • Arquitectura abstracta • Mecanismos de concretización • Distintas arquitecturas concretas, dependiendo del contexto • Usando qué? • Programas no monolíticos • Componentes • Servicios • Contenedores • … • Cuál es el reto para el arquitecto?

  20. La gran limitación? • Las posibles evoluciones deben estar previstas desde la arquitectura abstracta

  21. Agenda • Evolución = mantenimiento • Arquitecturas flexibles • Adaptación • Aplicaciones dinámicas • Auto-adaptación • Integración y evolución • Conclusiones

  22. Motivación • “Maneras parecidas de hacer cosas parecidas” adaptación cliente-1 cliente-2 cliente-3

  23. “Maneras parecidas de hacer cosas parecidas” • Cómo crear aplicaciones de una familia, como una “evolución” de un núcleo básico? • Cuál es la estructura de dicho núcleo básico? Cómo se diseña? Con qué mecanismos se adapta? • Fábricas de software y líneas de producción • Ejemplo: • El caso APEL

  24. Adaptación • Dos aproximaciones distintas al problema proceso y herramientas arquitectura frameworks plug-ins nuevos elementos nuevos mecanismos nuevas tecnologías generación, aprovechando la flexibilidad

  25. Dos aproximaciones distintas proceso y herramientas arquitectura más simple y directo menos riesgo más limitado más compleja la arquitectura más difícil de diseñar más general Arquitecturas adaptables

  26. El reto del arquitecto • Diseño de la arquitectura del framework de base • Diseño de los mecanismos de adaptación • Diseño de los mecanismos y herramientas de generación • Incorporación de nuevos elementos, estructuras y tecnologías

  27. Agenda • Evolución = mantenimiento • Arquitecturas flexibles • Adaptación • Aplicaciones dinámicas • Auto-adaptación • Integración y evolución • Conclusiones

  28. Motivación adaptación dinámica cliente aplicaciones que no pueden detenerse para cambiar “Evolución y adaptación en ejecución”

  29. Aplicaciones dinámicas: motivación • Algunos ejemplos: • sistemas 24/24 • sistemas críticos • sistemas altamente dinámicos • sistemas embebidos • sistemas altamente distribuidos • recuperación ante fallas • gran volumen de usuarios • sistemas que se adaptan al contexto

  30. Adaptación y evolución dinámica arquitectura plug-ins (Eclipse > 3.0 sobre OSGI) JBoss / JMX coordinación en lugar de composición componentes & servicios especializados nuevas tecnologías y estilos de arquitectura nuevos problemas en el diseño

  31. El reto del arquitecto • Cómo diseñar una arquitectura de una aplicación cuya evolución se debe hacer mientras se está ejecutando? • Una mezcla de nuevas tecnologías, elementos de diseño, metodologías, herramientas. • La limitación: implica la intervención de una persona para hacer la evolución

  32. Agenda • Evolución = mantenimiento • Arquitecturas flexibles • Adaptación • Aplicaciones dinámicas • Auto-adaptación • Integración y evolución • Conclusiones

  33. Auto-adaptación dinámica auto-adaptación dinámica cliente Arquitecturas reactivas: muchas formas disponibles. El sistema es capaz de seleccionar la forma adecuada, dependiendo del contexto

  34. Auto-adaptación dinámica • Aparecen nuevos elementos en la arquitectura: • sensores • actuadores • modelos y lenguajes para expresar la adaptación • políticas • reglas • sincronización • recuperación • … • tecnologías de soporte • … • Nuevos problemas en el diseño

  35. El reto del arquitecto • Diseñar una arquitectura abstracta adaptable y dinámica • Diseñar un modelo abstracto de su evolución • Diseñar la manera de integrar esos dos modelos • Incorporar nuevas tecnologías y elementos

  36. Agenda • Evolución = mantenimiento • Arquitecturas flexibles • Adaptación • Aplicaciones dinámicas • Auto-adaptación • Integración y evolución • Conclusiones

  37. Integración y evolución Empresas virtuales en tiempo real Sistemas altamente volátiles EAI Arquitecturas flexibles y adaptables de integración

  38. El reto del arquitecto • Cómo diseñar una arquitectura para integrar aplicaciones, sabiendo que: • Los requerimientos sobre la integración pueden ser volátiles • Las aplicaciones van a evolucionar • Nuevas aplicaciones van a llegar • Las aplicaciones son heterogéneas

  39. A A A A Integración y evolución • Objetivo: • Poner a trabajar juntas aplicaciones que no fueron hechas para trabajar juntas • Crear una arquitectura que le permita evolucionar • EAI – clásico: dificultad de evolución de los adaptadores

  40. A A A A A A A A Integración y evolución • Coordinación más que composición • Arquitecturas guiadas por los procesos empresariales (BPM) • Elementos: • Orquestación • Servicios y web-services • Workflows • Buses de eventos • Sistemas de reglas • … coordinación

  41. Integración y evolución • El gran problema: • Falta de correspondencia semántica: conceptos similares, pero diferentes Problema abierto

  42. Agenda • Evolución = mantenimiento • Arquitecturas flexibles • Adaptación • Aplicaciones dinámicas • Auto-adaptación • Integración y evolución • Conclusiones

  43. Conclusiones • Evolución • Flexibilidad • Adaptación • Adaptación dinámica • Auto-adaptación • Integración nuevos retos y problemas para el arquitecto nuevas tecnologías nuevas arquitecturas nuevas metodologías nuevas herramientas crecimiento exponencial de la complejidad

  44. Conclusiones • Los nuevos requerimientos en las aplicaciones se traducen en arquitecturas basadas en elementos distintos, con propiedades distintas • Un tema abierto de trabajo • Más información en: • http://agamenon.uniandes.edu.co/~jvillalo

  45. Preguntas?

More Related