Programación
Orientada a Aspectos
La verdad desnuda
Lic. Fernando Asteasuain
16 Septiembre 2005
Charla de borrachos
¿Porqué se me dio por la POA?
Rankings
 101 de E!

Ranking MIT Top Ten


En su edición especial del nuevo milenio,
(en febrero 2001), la revista MIT
Technology Review, lanza su top ten.
“10 emerging areas of technology that
will soon have a profound impact on the
economy and how we live and work in
the new millennium”
10..6
Brain-Machine Interfaces: entender
como trabaja el cerebro.
Manejo de los derechos digitales.
10

9

8

Biometrics: identificación a través de
huellas digitales, retina, facciones.
7

Data Mining: Extraer información de un
texto.
6

Transistores Flexibles: desarrollo de
nuevos materiales híbridos.
5...4
5

Procesamiento del lenguaje natural:
reconocimiento de voz, extracción de
información.
4

Microfluidos: técnicas especializadas
para un análisis mas veloces y precisos.
3

Microphotonics: cristales que reflejan
ondas de luz.
2

Robots: aprendizaje, desenvolvimiento
con el ambiente.
Número 1

Programación Orientada a Aspectos!

Empecemos a ver qué es la POA
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.
Evolución del perfil

Antes, el programador => un ermitaño,
programaba en el sótano.

Hoy, ya es un ingeniero de SW:



Trabajo en grupo
Buen manejo de relaciones interpersonales.
Comunicación
Gráficamente

Antes

En la actualidad
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
Ejemplo 1
Clase Libro {
…..
<todas las cosas de libro>
<manejo de errores>
…
}
Clase Socio {
…..
<todas las cosas de socio>
<manejo de errores>
<controles de acceso>
}

 Conceptos entrecruzados
* Errores
* Seguridad
Clase Alquiler {…..
<todas las cosas de alquiler>
<manejo de errores>
<controles de acceso>
}
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
Problemas





Baja correspondencia.
Menor Productividad.
Menor Reuso.
Baja calidad del código.
Evolución dificultosa.
Tiranía de la descomposición
dominante
Supongamos el siguiente modelo:



Descomponer por forma, por color, por tamaño.
Nos vemos obligados a elegir un modelo como principal.
Distintos Modelos

Ordenado por Forma

Ordenado por Color
Jerarquía Color-Forma

Nos vemos obligados a elegir un modelo como principal. En este caso:
color, y luego forma
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.
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.
Estructura

Estructura Tradicional
PROGRAMA
Lenguaje
Compilador o
Intérprete
EJECUTABLE
Estructura POA
PROGRAMA DE
COMPONENTES
Lenguaje
base
PROGRAMA DE
ASPECTOS 1
Lenguaje de
aspectos 1
...
...
TEJEDOR (WEAVER)
EJECUTABLE
PROGRAMA DE
ASPECTOS N
Lenguaje de
aspectos N
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();
}
}
Control de acceso
Funcionalidad básica
public void ingresarSocio(socio S){
if controlDeAccesoValido() then{
// código del método
}
else{
generarExcepcion();
}
}
// demás métodos…
}
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();
}
}
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%.
Relación POA y POO
POO: conceptos comunes
Clase A
Clase A1
Attb1
POA: conceptos entrecruzados
Clase A2
Attb 3
Attb2
Método 1
Método 1
Método 2
¿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.
Historia en Imágenes
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.
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.

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
Antes y después de Aspectos
Bibliografía & Más Info

www.aosd.net

dependex.dc.uba.ar
dependex.dc.uba.ar/~ferto/
 www.angelfire.com/ri2/aspectos


Comunidad de Aspectos
Diseño OA





No se banca bien los aspectos.
Se extiende UML para tal fin.
Extensiones al metamodelo.
Extensiones con mecanismos propios.
OCL para restricciones: joinpoints.
Extensiones al metamodelo
Extensiones Específicas

Se maneja con los mecanismos propios de extensión de UML:
estereotipos, restricciones, y valores etiquetados.

Ejemplo para aspecto de distribución
Conclusiones




Contribuciones principales de:
AORE
Arquitectura OA
Diseño OA
AORE



= Trato para los req. funcionales y no.
Reconocer que los req. se entrecruzan e
influyen entre sí.
Fundamental contar con sólidos
mecanismos de composición
Arquitectura OA




Pequeñísimas aproximaciones y
Herramientas.
El área más tímida de desarrollo hoy día.
Mostró útil y viable un lenguaje de
arquitectura OA.
Creciente consenso en la comunidad
para separar las vistas.
Diseño OA




Medios para modelar explícitamente los
aspectos.
Razonar sobre los concerns por
separado.
Manejo de combinación & composición.
Resolver conflictos y especificar
cooperación.
Descargar

Programación Orientada a Aspectos (la verdad detrás…)