Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de...

47
Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005

Transcript of Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de...

Page 1: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Programación Orientada a Aspectos

Lic. Fernando AsteasuainUniversidad de Buenos Aires10 de noviembre 2005

Page 2: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Evolución del SW

Al principio, Codigo Spaghetti.

Tipos, bloques, procedimientos. Tipos de datos abstractos… Objetos: datos + comportamiento.

Conceptos aplicados siempre: Abstracción, encapsulamiento & Modularidad.

Page 3: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

De todas maneras….

Se encapsula correctamente la funcionalidad del sistema.

¿Pero qué ocurre con los conceptos no funcionales ….?

Sincronización, logging, manejo de errores, profiling, etc => no se encapsulan correctamente y quedan esparcidos por todo el sistema.

Se denominan conceptos entrecruzados

Page 4: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo 1

Conceptos entrecruzados

Clase Libro {…..<todas las cosas de libro><manejo de errores>…}

Clase Socio {…..<todas las cosas de socio><manejo de errores><controles de acceso>}

Clase Alquiler {…..

<todas las cosas de alquiler><manejo de errores><controles de acceso>

}

* Errores

* Seguridad

Page 5: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Análisis Ejemplo

Funcionalida básica: OK. Libros, Socios, Alquileres.

¿Qué pasa con el manejo de errores y de seguridad?

Se esparcen por todo el sistema, creando dos problemas:

Code Tangling & Code Scaterring

Page 6: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Problemas

Baja correspondencia. Menor Productividad. Menor Reuso. Baja calidad del código. Evolución dificultosa.

Page 7: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Tiranía de la descomposición dominante (Fuente: Herramienta CAESAR)

Supongamos el siguiente modelo:

Descomponer por forma, por color, por tamaño. Nos vemos obligados a elegir un modelo como principal.

Page 8: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Distintos Modelos

Ordenado por Forma

Ordenado por Color

Page 9: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Jerarquía Color-Forma Nos vemos obligados a elegir un modelo como principal. En este caso: color, y luego

forma

Page 10: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

POA

La POA promueve la separación de conceptos a través de mecanismos, que permiten abstraer y

componer estos conceptos a lo largo del sistema.

Un aspecto es un concepto que no es posible encapsularlo claramente, y que resulta diseminado por todo el código.

Un aspecto será la unidad que encapsulará un concepto entrecruzado.

Page 11: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Conceptos POA Aplicando POA se puede escribir una funcionalidad básica “pura”,

y especificar cada aspecto por separado. Luego, existe un proceso de combinación que compondrá el sistema final.

Los puntos de enlace brindan la interfaz entre aspectos y componentes. Son lugares dentro del código donde es posible agregar comportamiento adicional.

El comportamiento adicional puede agregarse en tres momentos particulares: antes, después, en lugar de .

El encargado de la composición es llamado Weaver. Guiado por los puntos de enlace teje el código base con el código de los aspectos.

Page 12: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Estructura

Estructura Tradicional

Lenguaje

Compilador o Intérprete

EJECUTABLE

PROGRAMA

Page 13: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Estructura POA

... Lenguaje base

Lenguaje de aspectos 1

Lenguaje de aspectos N

... TEJEDOR (WEAVER)

EJECUTABLE

PROGRAMA DE ASPECTOS N

PROGRAMA DE ASPECTOS 1

PROGRAMA DE COMPONENTES

Page 14: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo 2: biblioteca

Class Biblioteca { private libro [] libros ; private socio [] socios;  public Biblioteca() { … public void prestamo( socio S, libro L) { if controlDeAccesoValido() then{ // código del método } else{ generarExcepcion(); } }

public void ingresarSocio(socio S){ if controlDeAccesoValido() then{ // código del método } else{ generarExcepcion(); } }// demás métodos…}

Control de accesoControl de acceso

Funcionalidad básicaFuncionalidad básica

Page 15: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Definición de un aspecto

Aspecto Control {

Punto de enlace operacionesSeguras = llamadas a Biblioteca.prestamo & llamadas a Biblioteca.ingresarSocio& ...

antes de operacionesSeguras: {if !=(controlDeAccesoValido()) then{ generarExcepcion(); }

}

Page 16: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo TFTP

Se implementó con AspectJ el protocolo de comunicación TFTP.

Protocolo muy simple para transferir archivos entre procesos

Reingeniería y Aspecto de Logging. Código de logging: 31%.

Page 17: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.
Page 18: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Puntos de enlace en detalle

Llamada a un constructor: Cuando un objeto es creado y un constructor es invocado.

Ejemplo: NumComplejo nc1 = new NumComplejo(3.0,5.3);El objeto es creado por new y luego el constructorNumComplejo es invocado.

Llamadas a métodos: Cuando un método es invocado.Ejemplo: obj.met1(5.5);Cuando el método met1 es invocado sobre el objeto obj.

Ejecución de un método: Cuando el cuerpo de un método se ejecuta.Ejemplo: Cuando el cuerpo del método met1 es ejecutado.

Page 19: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Más puntos de enlace

Asignación a un atributo: Cuando se realiza laasignación a un atributo.Ejemplo: numerocomplejo.parte_imaginaria=5.5;

Cuando al atributo parte_imaginaria del objetonumerocomplejo se le asigna el valor real 5.5.

Ejecución de un manejador: Cuando el manejador de una excepción se ejecuta.

Page 20: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Modelo de puntos de enlace

Elemento crítico en cualquier lenguaje OA.

Interfaz entre aspectos y código base. Modelo Posible a través de grafos. Veamos un ejemplo de modelo.

Page 21: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Clase para manejar Números Complejos

Page 22: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Clase para manejar Coordenadas Complejas

NumComplejo nc1 = new NumComplejo(3.0,5.3);NumComplejo nc2 = new NumComplejo(6.2,1.3);CoordenadaCompleja cc = new CoordenadaCompleja(nc1,nc2);cc.aumentar_parte_real_primera(5.5);

Page 23: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo Modelo Puntos Enlace

cc.aumentar_parte_real_primera(5.5);

1. Un punto de enlace de llamada a un método, correspondiente al método aumentar_parte_real_primera invocado sobre el objeto cc.

2. Un punto de enlace de recepción de llamada a un método, en el cual cc recibe la llamada aumentar_parte_real_primera.

3. Un punto de enlace de ejecución de un método, en el cual el método aumentar_parte_real_primera definido en la clase CoordenadaCompleja empieza su ejecución.

4. Un punto de enlace de acceso a un atributo, en el cual el atributo distancia de cc es referenciado.

Mét1 = aumentar_parte_real_primera, de la clase CoordenadaCompleja.Mét2 = ingresar_parte_real, de la clase NumComplejo.Mét3 = devolver_parte_real, de la clase NumComplejo.Mét4 = aumentar_parte_real, de la clase NumComplejo.

Page 24: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo Modelo Puntos Enlace

cc.aumentar_parte_real_primera(5.5);5. Un punto de enlace de llamada a un método, en el cual el método aumentar_parte_real es invocado sobre el objeto nc1.

6. Un punto de enlace de recepción de llamada a un método, en el cual nc1 recibe la llamada aumentar_parte_real.

7. Un punto de enlace de ejecución de un método, en el cual el método aumentar_parte_real definido en la clase NumComplejo empieza su ejecución.

8. Un punto de enlace de llamada a un método, en el cual el método devolver_parte_real es invocado sobre el objeto nc1.

Page 25: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo Modelo Puntos Enlace

cc.aumentar_parte_real_primera(5.5);

9. Un punto de enlace de recepción de llamada a un método, en el cual nc1 recibe la llamada devolver_parte_real.

10. Un punto de enlace de ejecución de un método, en el cual el método devolver_parte_real definido en la clase NumComplejo empieza su ejecución.

El control retorna por los puntos de enlace 10 y 9.

11. Un punto de enlace de llamada a un método, en el cual el método ingresar_parte_real es invocado sobre el objeto nc1.

Page 26: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Pointcuts en detalle

Se pueden capturar puntos de enlaces de diferentes clases, esto es, entrecruzan las clases.

Ejemplo 1:Call (void NumComplejo.ingresar_parte_real(real))

captura todas las llamadas al método ingresar_parte_real de la claseNumComplejo con un argumento de clase real.

Ejemplo 2:

pointcut acceso():

get (NumComplejo.parte_real) || get (CoordenadaCompleja.distancia);

Agrupan puntos de enlace.

Page 27: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplos de pointcuts

Call: llamadas a métodos Exec: ejecución de un método. Get y set: referencia y acceso a atributos.

Within: within (C) Captura todos los puntos de enlace donde el código que se está ejecutando está definido en la clase C. Ejemplo: within(NumComplejo).

Withincode: withincode (m) Captura todos los puntos de enlace donde el código que se está ejecutando está definido en la método m. Ejemplo: withincode(real devolver_parte_real())).

Page 28: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo Composición de Pointcuts Supongamos una clase Pila, con métodos Apilar, y un Apilar múltiple.

Se quiere dibujar la pila cada vez que un elemento es agregado.

Page 29: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo Composición de Pointcuts Decidimos implementar los dibujos con aspectos.

Defino un pointcut para capturar las llamadas.

Una primera opción sería: pointcut al_apilar() : call(void Pila.Apilar(Object));

• No interactúa bien con el método Apilar múltiple.

Problemas?

Page 30: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo composición Posible solución:

pointcut al_apilar_multiple():

call(void Pila.Apilar_Multiple(..));

pointcut al_apilar_eficiente(): al_apilar_deauno() && al_apilar_multiple();

pointcut al_apilar_deauno():

al_apilar() && !withincode(void Pila.Apilar_Multiple(..));

Page 31: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Advices Código que implementa el comportamiento de los aspectos.

Antes, después, y en lugar de.

Ejemplos:

pointcut al_apilar(Pila p) : call(void Pila.Apilar(..)) && target (p); before(Pila p):al_apilar(p){ if(p.Pila_Llena()){ throw new ExcepcionPilaLlena(); } }

after (Pila p):al_apilar_eficiente(p){ dibujaEstructura dibujante =new dibujaEstructura(); dibujante.dibujarPila(p); }

Page 32: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Relación POA y POO

Clase A

Clase A1

Attb1

Attb2

Método 1

Clase A2

Attb 3

Método 1

Método 2

POO: conceptos comunes

POA: conceptos entrecruzados

Page 33: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplos POA y POO

Page 34: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Ejemplo 2

Page 35: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Interacción Aspectos – Código Base

¿Cuál es el marco adecuado de interacción entre los aspectos y los objetos?

¿Qué tanto poder deben tener los aspectos sobre los objetos? (En aspectJ pueden modificar la estructura estática.)

¿Está “bien” que los aspectos accedan a la parte privada de un objeto?

Obliviousness

Page 36: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Acerca de obliviousness

OB propone:1. Identificar aspectos y código base2. Implementar la parte base sin considerar los aspectos3. Implementar los aspectos

“Just program like always, and we’ll be able to add the aspects later”

Independizar aspectos del código base Favorece la reutilización. Pero…,¿a qué costo? ¿Qué tan fiel a obliviousness debemos serle?

Page 37: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Acerca de obliviousness

Sin embargo … Aspectos complejos . 0 Desarrollo paralelo. Para aplicar aspectos se debe conocer

mucho el código base.

Page 38: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Aproximaciones Intermedias

Varios buscan algo intermedio: definir interfaces.

Se crean especificaciones para concentrar en ellas el obliviousness.

Forma primitiva de alejarnos de la sintaxis. Separar la implementación de los aspectos

del binding de los aspectos.

Page 39: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Semántica en AOP

Un problema de la AOP es que está fuertemente basada en la sintaxis del código.

Yo puedo tener un aspecto que capture todos los métodos que comiencen con Set.

No solo ese método deja de ser capturado, sino que quizás ahora lo capture otro aspecto.

Es un grave problema.

¿Qué pasa si cambio el nombre de un método?

Page 40: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

SetPoint

Agregarle semántica al código. Anotaciones & Ontologías. @método:cuentasbancarias. Ontologías: modelo del dominio. Para bancos: se que tengo una cuenta, las

cuentas tienen saldo, puedo operar sobre la cuenta para depositar o extraer dinero, etc.

Entonces “predico” sobre la semántica del sistema.

Implementado en .NET.

Page 41: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

¿De donde venimos?

El grupo de PA en Boston, quería hacer código según la ley de demeter.

Cristina Videira Lopes miembro Ph.D introduce “Separations of Concerns”.

En 1995 Cristina se une en Xerox Park, con Gregor Kiczales. En noviembre nace la sigla AOP.

En 1998 sale la 1º versión de AspectJ, implementado dos lenguajes de Cristina.

Page 42: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

POA y los demás paradigmas

Mayormente, se utiliza en relación a la POO.

Sin embargo, existen aplicaciones de POA a otros paradigmas también. Imperativo: Desarrollos y extensiones a

C para implementación de SO.

Lógicos: aspectos al estilo ?envio (X,Y). Estilo declarativo, consultas.

Page 43: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Herramientas OA Lenguajes para programar Aspectos: AspectJ: Extensión a Java para aplicar

aspectos. La más popular. AspectC++,AspectS, CAESAR. En .NET: Weave.NET, Source Weave. SetPoint: Framework en .NET. Basado en

la semántica y no en la sintaxis.

Page 44: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

AOP y la industria Lo más exitoso tiene que ver con AspectJ. Aplicaciones y Frameworks Middleware: Spring, JBoss. Websphere. Servidores de

aplicación. AspectJ & MySql: a través de JDBC. Reingeniería de JHotDraw. IntelliPrints aplicación para enterprise logging,

que usa AspectJ adentro. Oracle - TopLink: Ambiente genérico para bases

de datos. Desarrollado con tecnología AOP.

Page 45: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Todo el ciclo de desarrollo Si bien al principio todo era programar, los conceptos

AOP se trasladaron a todo el proceso de Software. por lo tanto:

AORE: Aspect Oriented Requirement Engineering.

Arquitectura OA

AOD: Aspect Oriented Design. Extensiones a UML para soportar el manejo de aspectos en la etapa de diseño. Extensiones Generales y Específicas.

Verificación, Formalización &Model Checking OA

Page 46: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

POA: ¿Paradigma?

¿Es una mera extensión a objetos? ¿Dónde está su verdadero aporte? Un paradigma no nace arbitrariamente, sino

que surge de necesidades concretas.

Separación de conceptos. La composición que permite formar el

sistema final.

Page 47: Programación Orientada a Aspectos Lic. Fernando Asteasuain Universidad de Buenos Aires 10 de noviembre 2005.

Separación de conceptos

Introducido a mediados de los 70s por E. Dijkstra.

“Habilidad para identificar, encapsular y manipular sólo las partes del software que son relevantes a un concepto, meta o propósito en particular”.