Programación Orientada a Aspectos La verdad desnuda Lic. Fernando Asteasuain 16 Septiembre 2005 Charla de borrachos
¿Porqué se me dio por la POA? <ul><li>Rankings </li></ul><ul><li>101 de E!  </li></ul>
Ranking MIT Top Ten <ul><li>En su edición especial del nuevo milenio, (en febrero 2001), la revista MIT Technology Review,...
10..6 <ul><li>Brain-Machine Interfaces: entender como trabaja el cerebro. </li></ul><ul><li>Transistores Flexibles: desarr...
5...4 <ul><li>Procesamiento del lenguaje natural: reconocimiento de voz, extracción de información.  </li></ul><ul><li>Mic...
Número 1 <ul><li>Programación Orientada a Aspectos! </li></ul><ul><li>Empecemos a ver qué es la POA </li></ul>
Evolución del SW <ul><li>Al principio, Codigo Spaghetti.  </li></ul><ul><li>Tipos, bloques, procedimientos. </li></ul><ul>...
Evolución del perfil <ul><li>Antes, el programador => un ermitaño, programaba en el sótano. </li></ul><ul><li>Hoy, ya es u...
Gráficamente <ul><li>Antes </li></ul><ul><li>En la actualidad </li></ul>
De todas maneras…. <ul><li>Se encapsula correctamente la funcionalidad del sistema. </li></ul><ul><li>¿Pero qué ocurre con...
Ejemplo 1 <ul><li>   Conceptos entrecruzados </li></ul>*  Errores *  Seguridad Clase Libro { … .. <todas las cosas de lib...
Análisis Ejemplo <ul><li>Funcionalida básica: OK. Libros, Socios, Alquileres. </li></ul><ul><li>¿Qué pasa con el manejo de...
Problemas <ul><li>Baja correspondencia. </li></ul><ul><li>Menor Productividad. </li></ul><ul><li>Menor Reuso. </li></ul><u...
Tiranía de la descomposición dominante <ul><li>Supongamos el siguiente modelo: </li></ul><ul><li>Descomponer por forma, po...
Distintos Modelos <ul><li>Ordenado por Forma </li></ul><ul><li>Ordenado por Color </li></ul>
Jerarquía Color-Forma <ul><li>Nos vemos obligados a elegir un modelo como principal. En este caso: color, y luego forma </...
POA <ul><li>La POA promueve la separación de conceptos a través de mecanismos, que permiten abstraer y componer estos conc...
Conceptos POA <ul><li>Aplicando POA se puede escribir una funcionalidad básica “pura”, y especificar cada aspecto por sepa...
Estructura  <ul><li>Estructura Tradicional </li></ul>
Estructura POA
Ejemplo 2: biblioteca Class Biblioteca { private libro [] libros ; private socio [] socios;   public Biblioteca() { … publ...
Definición de un aspecto Aspecto Control { Punto de enlace operacionesSeguras = llamadas a  Biblioteca.prestamo & llamadas...
Ejemplo TFTP <ul><li>Se implementó con AspectJ el protocolo de comunicación TFTP. </li></ul><ul><li>Protocolo muy simple p...
 
Relación POA y POO POO: conceptos comunes POA: conceptos entrecruzados Clase A Clase A1 Attb1 Attb2 Método 1 Clase A2 Attb...
¿De donde venimos? <ul><li>El grupo de PA en Boston, quería hacer código según la ley de demeter.  </li></ul><ul><li>Crist...
Historia en Imágenes
POA y los demás paradigmas <ul><li>Mayormente, se utiliza en relación a la POO. </li></ul><ul><li>Sin embargo, existen apl...
Herramientas OA <ul><li>Lenguajes para programar Aspectos: </li></ul><ul><li>AspectJ: Extensión a Java para aplicar aspect...
Todo el ciclo de desarrollo <ul><li>Si bien al principio todo era programar, los conceptos AOP se trasladaron a todo el pr...
Antes y después de Aspectos
Bibliografía & Más Info <ul><li>www.aosd.net </li></ul><ul><li>dependex.dc.uba.ar </li></ul><ul><li>www.angelfire.com/ri2/...
Diseño OA <ul><li>No se banca bien los aspectos. </li></ul><ul><li>Se extiende UML para tal fin. </li></ul><ul><li>Extensi...
Extensiones al metamodelo
Extensiones Específicas <ul><li>Se maneja con los mecanismos propios de extensión de UML: estereotipos, restricciones, y v...
Conclusiones <ul><li>Contribuciones principales de: </li></ul><ul><li>AORE </li></ul><ul><li>Arquitectura OA </li></ul><ul...
AORE <ul><li>= Trato para los req. funcionales y no. </li></ul><ul><li>Reconocer que los req. se entrecruzan e influyen en...
Arquitectura OA <ul><li>Pequeñísimas aproximaciones y Herramientas.  </li></ul><ul><li>El área más tímida de desarrollo ho...
Diseño OA <ul><li>Medios para modelar explícitamente los aspectos. </li></ul><ul><li>Razonar sobre los concerns por separa...
Próxima SlideShare
Cargando en…5
×

Charla 2005 09 16

880 visualizaciones

Publicado el

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
880
En SlideShare
0
De insertados
0
Número de insertados
109
Acciones
Compartido
0
Descargas
13
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Charla 2005 09 16

  1. 1. Programación Orientada a Aspectos La verdad desnuda Lic. Fernando Asteasuain 16 Septiembre 2005 Charla de borrachos
  2. 2. ¿Porqué se me dio por la POA? <ul><li>Rankings </li></ul><ul><li>101 de E! </li></ul>
  3. 3. Ranking MIT Top Ten <ul><li>En su edición especial del nuevo milenio, (en febrero 2001), la revista MIT Technology Review, lanza su top ten. </li></ul><ul><li>“ 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” </li></ul>
  4. 4. 10..6 <ul><li>Brain-Machine Interfaces: entender como trabaja el cerebro. </li></ul><ul><li>Transistores Flexibles: desarrollo de nuevos materiales híbridos. </li></ul><ul><li>Data Mining: Extraer información de un texto. </li></ul><ul><li>Manejo de los derechos digitales. </li></ul><ul><li>Biometrics: identificación a través de huellas digitales, retina, facciones. </li></ul>10 9 8 7 6
  5. 5. 5...4 <ul><li>Procesamiento del lenguaje natural: reconocimiento de voz, extracción de información. </li></ul><ul><li>Microphotonics: cristales que reflejan ondas de luz. </li></ul><ul><li>Robots: aprendizaje, desenvolvimiento con el ambiente. </li></ul><ul><li>Microfluidos: técnicas especializadas para un análisis mas veloces y precisos. </li></ul>5 4 3 2
  6. 6. Número 1 <ul><li>Programación Orientada a Aspectos! </li></ul><ul><li>Empecemos a ver qué es la POA </li></ul>
  7. 7. Evolución del SW <ul><li>Al principio, Codigo Spaghetti. </li></ul><ul><li>Tipos, bloques, procedimientos. </li></ul><ul><li>Tipos de datos abstractos… </li></ul><ul><li>Objetos: datos + comportamiento . </li></ul><ul><li>Conceptos aplicados siempre: Abstracción, encapsulamiento & Modularidad. </li></ul>
  8. 8. Evolución del perfil <ul><li>Antes, el programador => un ermitaño, programaba en el sótano. </li></ul><ul><li>Hoy, ya es un ingeniero de SW: </li></ul><ul><li>Trabajo en grupo </li></ul><ul><li>Buen manejo de relaciones interpersonales. </li></ul><ul><li>Comunicación </li></ul>
  9. 9. Gráficamente <ul><li>Antes </li></ul><ul><li>En la actualidad </li></ul>
  10. 10. De todas maneras…. <ul><li>Se encapsula correctamente la funcionalidad del sistema. </li></ul><ul><li>¿Pero qué ocurre con los conceptos no funcionales ….? </li></ul><ul><li>Sincronización, logging, manejo de errores, profiling, etc => no se encapsulan correctamente y quedan esparcidos por todo el sistema. </li></ul><ul><li>Se denominan conceptos entrecruzados </li></ul>
  11. 11. Ejemplo 1 <ul><li> Conceptos entrecruzados </li></ul>* Errores * Seguridad 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> }
  12. 12. Análisis Ejemplo <ul><li>Funcionalida básica: OK. Libros, Socios, Alquileres. </li></ul><ul><li>¿Qué pasa con el manejo de errores y de seguridad? </li></ul><ul><li>Se esparcen por todo el sistema, creando dos problemas: </li></ul><ul><li>Code Tangling & Code Scaterring </li></ul>
  13. 13. Problemas <ul><li>Baja correspondencia. </li></ul><ul><li>Menor Productividad. </li></ul><ul><li>Menor Reuso. </li></ul><ul><li>Baja calidad del código. </li></ul><ul><li>Evolución dificultosa. </li></ul>
  14. 14. Tiranía de la descomposición dominante <ul><li>Supongamos el siguiente modelo: </li></ul><ul><li>Descomponer por forma, por color, por tamaño. </li></ul><ul><li>Nos vemos obligados a elegir un modelo como principal. </li></ul>
  15. 15. Distintos Modelos <ul><li>Ordenado por Forma </li></ul><ul><li>Ordenado por Color </li></ul>
  16. 16. Jerarquía Color-Forma <ul><li>Nos vemos obligados a elegir un modelo como principal. En este caso: color, y luego forma </li></ul>
  17. 17. POA <ul><li>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 . </li></ul><ul><li>Un aspecto es un concepto que no es posible encapsularlo claramente, y que resulta diseminado por todo el código. </li></ul><ul><li>Un aspecto será la unidad que encapsulará un concepto entrecruzado. </li></ul>
  18. 18. Conceptos POA <ul><li>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. </li></ul><ul><li>Los puntos de enlace brindan la interfaz entre aspectos y componentes. Son lugares dentro del código donde es posible agregar comportamiento adicional. </li></ul><ul><li>El comportamiento adicional puede agregarse en tres momentos particulares: antes, después, en lugar de . </li></ul><ul><li>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. </li></ul>
  19. 19. Estructura <ul><li>Estructura Tradicional </li></ul>
  20. 20. Estructura POA
  21. 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(); } } public void ingresarSocio(socio S){ if controlDeAccesoValido() then{ // código del método } else{ generarExcepcion(); } } // demás métodos… } Control de acceso Funcionalidad básica
  22. 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{ g enerarExcepcion(); } }
  23. 23. Ejemplo TFTP <ul><li>Se implementó con AspectJ el protocolo de comunicación TFTP. </li></ul><ul><li>Protocolo muy simple para transferir archivos entre procesos </li></ul><ul><li>Reingeniería y Aspecto de Logging. </li></ul><ul><li>Código de logging: 31%. </li></ul>
  24. 25. Relación POA y POO POO: conceptos comunes POA: conceptos entrecruzados Clase A Clase A1 Attb1 Attb2 Método 1 Clase A2 Attb 3 Método 1 Método 2
  25. 26. ¿De donde venimos? <ul><li>El grupo de PA en Boston, quería hacer código según la ley de demeter. </li></ul><ul><li>Cristina Videira Lopes miembro Ph.D introduce “Separations of Concerns”. </li></ul><ul><li>En 1995 Cristina se une en Xerox Park, con Gregor Kiczales. En noviembre nace la sigla AOP. </li></ul><ul><li>En 1998 sale la 1º versión de AspectJ, implementado dos lenguajes de Cristina. </li></ul>
  26. 27. Historia en Imágenes
  27. 28. POA y los demás paradigmas <ul><li>Mayormente, se utiliza en relación a la POO. </li></ul><ul><li>Sin embargo, existen aplicaciones de POA a otros paradigmas también. </li></ul><ul><li>Imperativo: Desarrollos y extensiones a C para implementación de SO. </li></ul><ul><li>Lógicos: aspectos al estilo ?envio (X,Y). Estilo declarativo, consultas. </li></ul>
  28. 29. Herramientas OA <ul><li>Lenguajes para programar Aspectos: </li></ul><ul><li>AspectJ: Extensión a Java para aplicar aspectos. La más popular. </li></ul><ul><li>AspectC++,AspectS, CAESAR. </li></ul><ul><li>En .NET: Weave.NET, Source Weave. </li></ul><ul><li>SetPoint: Framework en .NET. Basado en la semántica y no en la sintaxis. </li></ul>
  29. 30. Todo el ciclo de desarrollo <ul><li>Si bien al principio todo era programar, los conceptos AOP se trasladaron a todo el proceso de Software. </li></ul><ul><li> por lo tanto: </li></ul><ul><li>AORE: Aspect Oriented Requirement Engineering. </li></ul><ul><li>Arquitectura OA </li></ul><ul><li>AOD: Aspect Oriented Design. Extensiones a UML para soportar el manejo de aspectos en la etapa de diseño. Extensiones Generales y Específicas. </li></ul><ul><li>Verificación, Formalización &Model Checking OA </li></ul>
  30. 31. Antes y después de Aspectos
  31. 32. Bibliografía & Más Info <ul><li>www.aosd.net </li></ul><ul><li>dependex.dc.uba.ar </li></ul><ul><li>www.angelfire.com/ri2/aspectos </li></ul><ul><li>Comunidad de Aspectos </li></ul><ul><li>dependex.dc.uba.ar/~ferto/ </li></ul>
  32. 33. Diseño OA <ul><li>No se banca bien los aspectos. </li></ul><ul><li>Se extiende UML para tal fin. </li></ul><ul><li>Extensiones al metamodelo. </li></ul><ul><li>Extensiones con mecanismos propios. </li></ul><ul><li>OCL para restricciones: joinpoints. </li></ul>
  33. 34. Extensiones al metamodelo
  34. 35. Extensiones Específicas <ul><li>Se maneja con los mecanismos propios de extensión de UML: estereotipos, restricciones, y valores etiquetados. </li></ul><ul><li>Ejemplo para aspecto de distribución </li></ul>
  35. 36. Conclusiones <ul><li>Contribuciones principales de: </li></ul><ul><li>AORE </li></ul><ul><li>Arquitectura OA </li></ul><ul><li>Diseño OA </li></ul>
  36. 37. AORE <ul><li>= Trato para los req. funcionales y no. </li></ul><ul><li>Reconocer que los req. se entrecruzan e influyen entre sí. </li></ul><ul><li>Fundamental contar con sólidos mecanismos de composición </li></ul>
  37. 38. Arquitectura OA <ul><li>Pequeñísimas aproximaciones y Herramientas. </li></ul><ul><li>El área más tímida de desarrollo hoy día. </li></ul><ul><li>Mostró útil y viable un lenguaje de arquitectura OA. </li></ul><ul><li>Creciente consenso en la comunidad para separar las  vistas. </li></ul>
  38. 39. Diseño OA <ul><li>Medios para modelar explícitamente los aspectos. </li></ul><ul><li>Razonar sobre los concerns por separado. </li></ul><ul><li>Manejo de combinación & composición. </li></ul><ul><li>Resolver conflictos y especificar cooperación. </li></ul>

×