Programación Orientada a Aspectos

Presentación del tema: "Programación Orientada a Aspectos"— Transcripción de la presentación:

1 Programación Orientada a Aspectos
Bocchio, Sebastian Correa, Nicolas Digiacomo, Juan Pablo Tiercin, Jorge Sarubi, Jose Programación Orientada a Aspectos Teoría de los lenguajes de programación

2 Definición de POA Fue presentada en público por Gregor Kickzales y su equipo de investigación de Palo Alto Research Center en 1996. Paradigma de programación relativamente reciente. De esta forma se consigue: Razonar mejor sobre los conceptos. Eliminar la dispersión del código. Implementaciones resultan más comprensibles, adaptables y reusables.

3 Definición de Aspecto “ Un aspecto es una unidad modular que se disemina por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseño como en la de implementación. Un aspecto de diseño es unaunidad modular del diseño que se entremezcla en la estructura de otras partes del diseño. Un aspecto de programa o de código es una unidad modular del programa que aparece en otras unidades modulares del programa (G. Kiczales) ”

4 Definición de Aspecto Los aspectos son la unidad básica de la POA, y pueden definirse como las partes de una aplicación que describen las cuestiones claves relacionadas con la semántica esencial o el rendimiento. También pueden verse como los elementos que se diseminan por todo el código y que son difíciles de describir localmente con respecto a otros componentes. Ej.: patrones de acceso a memoria, sincronización de procesos concurrentes, manejo de errores, etc.

5 Estructura de un Programa OA

6 Estructura de un Programa OA
Se muestra un programa como un todo formado por un conjunto de aspectos más un modelo de objetos. Con el modelo de objetos se objetos se recoge la funcionalidad básica. Los aspectos recogen características de rendimiento y otras no relacionadas con la funcionalidad esencial del mismo.

7 Objetivos Fundamentales de la POA
Extraer y centralizar en un solo punto los "crosscutting concepts“  cada decisión se toma en un lugar concreto y no diseminada por la aplicación. Minimizar las dependencias entre ellos  desacoplar los distintos elementos que intervienen en un programa.

8 Objetivos Fundamentales de la POA
Idea principal es centralizar en un solo punto todos los aspectos comunes a las clases que forman el sistema software. Figura 1. Evolución de un sistema OO a uno OA

9 Ventajas de la POA Un código menos enmarañado, más natural y más reducido. Mayor facilidad para razonar sobre los conceptos, ya que están separados y las dependencias entre ellos son mínimas. Un código más fácil de depurar y más fácil de mantener.

10 Ventajas de la POA Se consigue que un conjunto grande de modificaciones en la definición de una materia tenga un impacto mínimo en las otras. Se tiene un código más reusable y que se puede acoplar y desacoplar cuando sea necesario.

11 Programa Tradicional Vs. OA

12 Conceptos Básicos de POA
Punto de unión (Join Point) Una posición bien definida dentro del código orientado a objetos, por ejemplo, la declaración de un método. Punto de corte (Pointcut) Un conjunto de condiciones aplicadas a un punto de unión que, al cumplirse, activarán el punto de corte y se ejecutará el punto de ejecución asignado a dicho punto de corte. Punto de ejecución (Advice) Fragmento de código que se ejecuta cuando se activa un punto de corte. Aspecto (Aspect) La combinación de puntos de corte, puntos de unión y puntos de ejecución.

13 Consideraciones Importantes
La POA no rompe con las técnicas de programación orientadas a objetos sino que las complementa y extiende. El nuevo paradigma de la programación orientada a aspectos es soportado por los llamados lenguajes de aspectos, que proporcionan constructores para capturar los elementos que se diseminan por todo el sistema.

14 Fundamentos de la POA Para tener un programa orientado a aspectos necesitamos definir los siguientes elementos: Un lenguaje para definir la funcionalidad básica. Este lenguaje se conoce como lenguaje base. Suele ser un lenguaje de propósito general, tal como C++ o Java. En general, se podrían utilizar también lenguajes no imperativos. Uno o varios lenguajes de aspectos. El lenguaje de aspectos define la forma de los aspectos, por ejemplo, los aspectos de AspectJ se programan de forma muy parecida a las clases. Un tejedor de aspectos.

15 Fundamentos de la POA Los puntos de enlace son una clase especial de interfaz entre los aspectos y los módulos del lenguaje de componentes. Son los lugares del código en los que éste se puede aumentar con comportamientos adicionales. Estos comportamientos se especifican en los aspectos.

16 Fundamentos de la POA El encargado de realizar este proceso de mezcla se conoce como tejedor (del término inglés weaver). El tejedor se encarga de mezclar los diferentes mecanismos de abstracción y composición que aparecen en los lenguajes de aspectos y componentes ayudándose de los puntos de enlace. El proceso de mezcla se puede retrasar para hacerse en tiempo de ejecución, o hacerse en tiempo de compilación.

17 Implementación en Lenguajes
Estructura de una implementación en los lenguajes tradicionales.

18 Implementación en lenguajes
Estructura de una implementación en los lenguajes de aspectos.

19 Fundamentos de la POA Los aspectos describen apéndices al comportamiento de los objetos. Hacen referencia a las clases de los objetos y definen en qué punto se han de colocar estos apéndices. Puntos de enlace que pueden ser tanto métodos como asignaciones de variables. Las clases y los aspectos se pueden entrelazar de dos formas distintas: Entrelazado estático Entrelazado dinámico

20 Fundamentos de la POA Entrelazado estático
El entrelazado estático implica modificar el código fuente de una clase insertando sentencias en estos puntos de enlace. Es decir, que el código del aspecto se introduce en el de la clase.

21 Fundamentos de la POA Ventajas Desventajas
La principal ventaja de esta forma de entrelazado es que se evita que el nivel de abstracción que se introduce con la programación orientada a aspectos se derive en un impacto negativo en el rendimiento de la aplicación. Desventajas Es bastante difícil identificar los aspectos en el código una vez que éste ya se ha tejido, lo cual implica que si se desea adaptar o reemplazar los aspectos de forma dinámica en tiempo de ejecución nos encontremos con un problema de eficiencia, e incluso imposible de resolver a veces.

22 Fundamentos de la POA Entrelazado dinámico
Una precondición o requisito para que se pueda realizar un entrelazado dinámico es que los aspectos existan de forma explícita tanto en tiempo de compilación como en tiempo de ejecución. Para conseguir esto, tanto los aspectos como las estructuras entrelazadas se deben modelar como objetos y deben mantenerse en el ejecutable. Dado un interfaz de reflexión, el tejedor es capaz de añadir, adaptar y borrar aspectos de forma dinámica, si así se desea, durante la ejecución.

23 Fundamentos de la POA Desventaja
El principal inconveniente subyacente bajo este enfoque es el rendimiento y que se utiliza más memoria con la generación de todas estas subclases.

24 Fundamentos de la POA Una de las primeras clasificaciones de las formas de combinar el comportamiento de los componentes y los aspectos fue dada por John Lamping. Yuxtaposición Consiste en la intercalación del código de los aspectos en el de los componentes. La estructura del código mezclado quedaría como el código base con el código de los aspectos añadidos en los puntos de enlace. En este caso, el tejedor sería bastante simple.

25 Fundamentos de la POA Mezcla
Es lo opuesto a la yuxtaposición, todo el código queda mezclado con una combinación de descripciones de componentes y aspectos. Fusión En este caso, los puntos de enlace no se tratan de manera independiente, se fusionan varios niveles de componentes y de descripciones de aspectos en una acción simple.

26 Mecanismos de construcción de ptos. de corte
Prescindencia (obliviousness) La prescindencia se refiere a que el programador encargado de implementar una funcionalidad específica no debería estar al tanto de las otras dimensiones que pueden afectar su código. Cuantificación (quantification) La cuantificación es la posibilidad de indicar en qué puntos de unión se aplicará un aspecto, sin necesidad de enumerarlos uno por uno.

27 Conclusiones La separación de los aspectos a todos los niveles (diseño, codificación y ejecutable) es un paso importante que se ha comenzado a dar, pero que aún hay que refinar, sobre todo en cuestiones de eficiencia. El campo de la orientación a aspectos es un campo de investigación muy joven, en el que se abre un horizonte bastante amplio. El estado actual de la investigación en POA es análogo al que había hace veinte años en la programación orientada a objetos.

28 Sistemas de Operación III
DCOM Sistemas de Operación III

29 DCOM The Distributed Component Object Model
DCOM es un protocolo que le permite a los componentes de un software comunicarse directamente sobre la red de manera, segura, confiable y eficiente DCOM permite la movilidad de los componentes logrando que cada uno este cerca de la localidad que le corresponda según su área de negocio. DCOM se encarga de todos los protocolos de bajo nivel (capa de red), para dejar al programador el negocio real.

30 DCOM Arquitectura DCOM es una extension del modelo Component Object Model (COM). COM define cómo los componentes y clientes interactuan entre sí. Cliente y componente pueden conectarse sin ningun intermediario.

31 DCOM Arquitectura En un sistema operativo la comunicación entre dos o mas procesos diferentes debe implementar librerias o funciones de IPC. COM provee esta comunicación de manera transparente: intercepta llamadas desde el cliente y las redirecciona al compomente.

32 DCOM Arquitectura Cuando el cliente y el componente se encunetran en maquinas diferentes DCOM reemplaza el IPC local por una comunicación via red. Ni el cliente ni el componente saben que la comunicación entre ambos se hace sea via red o local (IPC).

33 DCOM Componentes y Reusabilidad
La mayoria de las aplicacoines distribuidas no son desarrolladas desde cero. La gran variedad de herramientas, software y hardware debe ser utilizado para reducir tiempo y costo. DCOM aprovecha la gama de productos desarrollados con COM. Diseñar con COM o DCOM asegura reusabilidad y portabilidad ademas de alargar la vida del software.

34 DCOM Independiente de Localidad
Problemas del desarrollo de sistemas distribuidos: La distancia entre los componentes debería acortarse. Algunos sólo pueden ser ejecutados en arquitecturas o lugares específicos. Componentes más pequeños y simples facilitan desarrollo y aumentan felixibilidad pero degradan la eficiencia de la red. Componentes grandes y complejos aprovechan la red pero reducen la felixibilidad.

35 DCOM Independiente de Localidad
Resolver estos detalles es relativamente fácil con DCOM. DCOM oculta la localidad de los componentes, bien sea local o una máquina muy lejana. La independencia de localidad provista por DCOM simplifica y mejora el performance al tener la libertad de colocar los componentes en el mejor sitio posible para así optimizar la comunicación.

36 DCOM Independiente de Localidad

37 DCOM Neutralidad del Lenguaje
COM y DCOM son totalmente independientes del lenguaje. Permite al programador escoger el lenguaje que más conoce. Esta libertad permite la realización de prototipos de manera rápida. Se utiliza un IDL para crear las intefaces.

38 DCOM Manejo de conexión
Conexiones a través de la red son mucho mas frágiles que una local. Los componentes deben ser notificados en caso que un cliente se caiga o que existan problemas con la red. DCOM maneja las conexiones de la misma manera para componentes locales mono-usuario como componentes distribuidos multi-usuario contando las referencias de acceso al mismo. DCOM implementa un protocolo de ping para determinar si un cliente está vivo. (después de 3 fallas se libera la conexión).

39 DCOM Manejo de conexión
Las conexiones en DCOM son bidireccionales. Por lo que es fácil implementar aplicaciones peer-2-peer o cliente-servidor. DCOM provee de un poderoso mecanismo de recolección de basura distribuido totalmente transparente para la aplicación.

40 DCOM Escalabilidad Un factor crítico en toda aplicación distribuida es su habilidad para crecer en función del número de usuarios, el volumen de datos y las funcionalidades requeridas. La aplicación debe ser compacta y rápida para satisfacer peticiones sencillas, pero al mismo tiempo debe ser capaz de manejar demandas de mayor complejidad sin sacrificar su buen desempeño y confiabilidad usual. Para lograr esto DCOM provee una serie de mecanismos.

41 DCOM Escalabilidad Multiprocesamiento simétrico
Un número muy grande de hilos puede resultar en demasiados cambios de contexto. Mientras muy pocos puede causar el uso ineficiente de algunos procesadores.

42 DCOM Escalabilidad Desarrollo flexible
DCOM permite distribuir facilmente el conjunto de los componentes de la aplicación sobre los diversos computadores disponibles, una manera sencilla y bastante económica de favorecer la escalabilidad.

43 DCOM Escalabilidad Manejo de versiones (evolución)
La escabilidad no está solo ligada al número de usuarios y de transacciones. También tiene mucho que ver con la necesidad de escalar en función de las nuevas características que sean presentadas y requeridas a, y por la aplicación. DCOM provee mecanismos de evolución para clientes y componentes.

44 DCOM Escalabilidad

45 DCOM Desempeño La escalabilidad resulta inútil si el desempeño inicial no es satisfactorio. Surge la pregunta si soportar casi cualquier lenguaje o el hecho de poder correr componentes en el otro lado del mundo no afecta el rendimiento de la aplicación. El asunto es que al usar DCOM el cliente nunca ve el objeto en sí. Esta transparencia es lograda a través de una idea simple: “La única manera en que un cliente puede comunicarse con un componente es mediante llamadas a métodos”

46 DCOM Desempeño El cliente obtiene las direcciones de estos métodos de forma simple, a través de una tabla que contiene las direcciones de los mismos(vtable). Cuando un cliente desea llamar un método de un determinado componente sólo basta obtener la dirección del mismo. De manera que el único overhead producido por el modelo de programación DCOM sobre uno tradicional es el llamado indirecto de métodos sobre el modelo directo.

47 DCOM Ancho de banda y retardo
Las aplicaciones distribuidas toman ventaja de la red para mantener conectados a los diversos componentes. En teoría DCOM esconde completamente el hecho de que los componentes se están ejecutando en diferentes computadores. En la práctica sin embargo las aplicaciones deben tomar en cuenta dos principales restricciones:

48 DCOM Ancho de banda y retardo
Ancho de Banda: el tamaño de los parámetros afecta directamente el tiempo que toma completar la llamada a un método. Retardo (Latency): La distancia existente entre los diferentes componentes demora hasta el paquete más pequeño de datos.

49 DCOM Seguridad El uso de la red en aplicaciones distribuidas no solo impone dificultades físicas referentes al ancho de banda y retardo de la red. También trae consigo nuevas consideraciones de seguridad referentes a la comunicación entre clientes y componentes. Dado que ahora muchas operaciones son accesibles fisicamente a cualquiera con acceso a la red, el acceso a estas operaciones tiene que ser restringido en un nivel mayor. Si la plataforma no brinda un método de seguridad cada aplicación se vería forzada a implementar sus propios mecanismos y DCOM perdería gran parte de su atractivo.

50 DCOM Balance de la carga
Mientras más exitosa la aplicación, mayor será la carga del creciente número de usuarios en todos los componentes de la aplicación. Lo adecuado es distribuir el trabajo entre los servidores disponibles. DCOM no es capaz de facilitar este balance de la carga transparentemente, sin embargo permite implementar de manera sencilla algunos mecánismos a fin de lograr esto. Balance de carga estático Balance de carga dinámico.

51 DCOM Tolerancia a fallas
DCOM provee soporte básico para tolerancia a fallas a nivel de protocolo: Administrador de conexión compartida entre componentes: Detecta fallas a nivel de hardware tanto en la red como del lado del cliente. ¨Hot Backup¨: Dos copias del mismo componente del lado del servidor corriendo en paralelo en diferentes máquinas, procesando la misma información. Componentes de referencia: En presencia de fallas, hay una reconexión al mismo componente de referencia establecido en la primera conexión. Provee una nueva instancia del componente que esté corriendo en otra máquina.

52 DCOM Tolerancia a fallas
Las aplicaciones sin embargo tendrán que lidiar con recuperación de errores a alto nivel (consistencia, pérdida de información, etc.)

53 DCOM Independencia del protocolo
DCOM puede utilizar cualquier protocolo de transporte, como TCP/IP, UDP, IPX/SPX y NetBIOS. DCOM proporciona un marco de seguridad a todos estos protocolos. Los desarrolladores pueden usar las características proporcionadas por DCOM y asegurar que las aplicaciones sean independientes del protocolo.

54 DCOM Independencia de plataforma
Estándar binario por plataforma: Para poder mezclar y acoplar componentes realizados con distintas herramientas de diferentes proveedores y usarlo con distintas implementaciones del propio DCOM. Estándar de operatividad multi-plataforma: Servicios o abstracciones multi-plataforma: localización de componentes, creación y conexión a los mismos, invocación de métodos y un framework de seguridad. También utiliza los servicios disponibles en cada plataforma. Plataformas Disponibles: Se encuentra disponible para la familia Windows en general, la Macintosh de Apple y Solaris de SUN. Se está trabajando en portar DCOM a otras distribuciones UNIX.

55 DCOM Continua integración con otros protocolos de Internet
Las aplicaciones basadas en DCOM pueden conectar transparentemente cualquier red privada virtual.

56 DCOM Continua integración con otros protocolos de Internet
SOBRE INTERNET DCOM trabaja bien con firewalls tanto a nivel de protocolos (basada en puertos) como los filtros a nivel de aplicación. DCOM utiliza un solo puerto para inicializar las conexiones. Asigna un rango configurable de puertos para los componentes corriendo en una máquina. Los administradores de servidores pueden decidir comunicar DCOM a través de HTTP, traspasando efectivamente la mayoría de los firewalls. En cada escenario de conexión a través de la red, DCOM provee una seguridad flexible según sea necesaria.

57 El IDL de CORBA es más simple que el de DCOM.
DCOM vs. CORBA Sobre Semejanzas Diferencias Interfaces Ambos usan sus propios lenguajes de definición de interfaces (DLL) para describir interfaces. El IDL de CORBA es más simple que el de DCOM. DCOM tiene mejor soporte de herramientas para el manejo de IDL que CORBA. Proxies, Stubs y Skeletons Ambos utilizan stubs en el cliente y en el servidor para manejar las llamadas remotas. Los DLL´s del stub del cliente y servidor de DCOM son usados por todos los lenguajes de ambiente. En CORBA se crean separados stubs-skeletons por cada lenguaje.

58 DCOM vs. CORBA Sobre Semejanzas Diferencias Manejo de Objetos
Soportan contadores de referencias para el manejo de las instancias de un objeto. CORBA soporta herencia múltiple en la jerarquía de interfaces. DCOM sólo soporta herencia simple. Destrucción de objetos Ambos como se mencionó confían en los contadores de referencia para conocer cuándo un objeto puede ser destruido. DCOM soporta conteo de referencias distribuido y colección de basura. En CORBA dicho conteo se lleva por separado en el cliente y el servidor,

59 DCOM PREGUNTAS