Programación Orientada a Aspectos

Bocchio, Sebastian

Correa, Nicolas

Digiacomo, Juan Pablo

Tiercin, Jorge

Sarubi, Jose

Teoría de los lenguajes de programación

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.

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) ”

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.

Estructura de un Programa OA

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.

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.

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.

Comportamientopropio

Comportamientopropio

Persistencia

Traza

……..

Comportamientopropio

Comportamientopropio

Persistencia Traza

Clase A Clase B

Clase A Clase B

Clases

Aspectos

Figura 1. Evolución de un sistema OO a uno OA

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.

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.

Programa Tradicional Vs. OA

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.

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.

Para tener un programa orientado a aspectos necesitamos definir los siguienteselementos:

•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.

Fundamentos de la POA

Fundamentos de la POA

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

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.

Estructura de una implementación en los lenguajes tradicionales.

Implementación en Lenguajes

Implementación en lenguajes

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

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

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.

Fundamentos de la POA

Fundamentos de la POA

• VentajasLa 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.

• DesventajasEs 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.

Entrelazado dinámicoUna 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.

Fundamentos de la POA

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.

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ónConsiste 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.

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.

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.

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.

DCOM

Sistemas de Operación III

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.

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.

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.

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).

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.

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.

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.

DCOM Independiente de Localidad

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.

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).

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.

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.

DCOM Escalabilidad

• Multiprocesamiento simétricoUn número muy grande de hilos puede resultar en demasiados cambios de contexto. Mientras muy pocos puede causar el uso ineficiente de algunos procesadores.

DCOM Escalabilidad

• Desarrollo flexible

DCOM permite distribuir facilmente el conjuntode los componentes de la aplicación sobre losdiversos computadores disponibles, una manera sencilla y bastante económica de favorecer laescalabilidad.

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 paraclientes y componentes.

DCOM Escalabilidad

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”

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.

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:

• 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.

DCOM Ancho de banda y retardo

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.

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.

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.

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.)

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.

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.

DCOM Continua integración con otros protocolos de Internet

Las aplicaciones basadas en DCOM pueden

conectar transparentemente cualquier red privada virtual.

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.

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.

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,

DCOM

PREGUNTAS