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 10 • Brain-Machine Interfaces: entender como trabaja el cerebro. 9 • Manejo de los derechos digitales. 8 • Biometrics: identificación a través de huellas digitales, retina, facciones. • 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 3 • Microphotonics: cristales que reflejan ondas de luz. 2 • Robots: aprendizaje, desenvolvimiento con el ambiente.

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 => 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 • En la actualidad • Antes

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

11. 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> } 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%.

25. Clase A Clase A1 Clase A2 Attb1 Attb2 Attb 3 Método 1 Método 2 Método 1 Relación POA y POO POO: conceptos comunes POA: conceptos entrecruzados

26. 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. ¿De donde venimos?

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.