Programaciуn Orientada a Aspectos La verdad desnuda

1
Programación Orientada a AspectosLa verdad
desnuda
Lic. Fernando Asteasuain 16 Septiembre
2005 Charla de borrachos
2
Porqué se me dio por la POA?

• Rankings

• 101 de E!

3
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

4
10..6

• Brain-Machine Interfaces entender como trabaja
  el cerebro.

10
9

• Manejo de los derechos digitales.

• Biometrics identificación a través de huellas
  digitales, retina, facciones.

8

• Data Mining Extraer información de un texto.

7

• Transistores Flexibles desarrollo de nuevos
  materiales híbridos.

6
5
5...4
5

• Procesamiento del lenguaje natural
  reconocimiento de voz, extracción de información.
  

• Microfluidos técnicas especializadas para un
  análisis mas veloces y precisos.

4

• Microphotonics cristales que reflejan ondas de
  luz.

3

• Robots aprendizaje, desenvolvimiento con el
  ambiente.

2
6
Número 1

• Programación Orientada a Aspectos!

• Empecemos a ver qué es la POA

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

8
Evolución del perfil

• Antes, el programador gt 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

9
Gráficamente

• Antes

• En la actualidad

10
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 gt no se encapsulan correctamente
  y quedan esparcidos por todo el sistema.
• Se denominan conceptos entrecruzados

11
Ejemplo 1

• ? Conceptos entrecruzados

• Errores

• Seguridad

12
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

13
Problemas

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

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

15
Distintos Modelos

• Ordenado por Forma

• Ordenado por Color

16
Jerarquía Color-Forma

• Nos vemos obligados a elegir un modelo como
  principal. En este caso color, y luego forma

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

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

19
Estructura

• Estructura Tradicional

20
Estructura POA
21
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
22
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()

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

24
(No Transcript)
25
Relación POA y POO
POO conceptos comunes
POA conceptos entrecruzados
26
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.

27
Historia en Imágenes
28
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.

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

30
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

31
Antes y después de Aspectos
32
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

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

34
Extensiones al metamodelo
35
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

36
Conclusiones

• Contribuciones principales de
• AORE
• Arquitectura OA
• Diseño OA

37
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

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

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