Programación Orientada a Aspectos La verdad desnuda



Descargar 12,81 Kb.
Fecha de conversión11.03.2017
Tamaño12,81 Kb.

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.
  • Transistores Flexibles: desarrollo de nuevos materiales híbridos.
  • Data Mining: Extraer información de un texto.
  • Manejo de los derechos digitales.
  • Biometrics: identificación a través de huellas digitales, retina, facciones.
  • 10
  • 9
  • 8
  • 7
  • 6

5...4

  • Microphotonics: cristales que reflejan ondas de luz.
  • Robots: aprendizaje, desenvolvimiento con el ambiente.
  • Microfluidos: técnicas especializadas para un análisis mas veloces y precisos.
  • 5
  • 4
  • 3
  • 2

Número 1

  • Programación Orientada a Aspectos!
  • Empecemos a ver qué es la POA

Evolución del SW

  • 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

  •  Conceptos entrecruzados
  • Clase Libro {
  • …..
  • }
  • Clase Socio {
  • …..
  • }
  • Clase Alquiler {…..
  • }
  • * Errores

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

Estructura POA

  • 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

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

  • Clase A
  • Clase A1
  • Attb1
  • Attb2
  • Método 1
  • Clase A2
  • Attb 3
  • Método 1
  • Método 2
  • POA: conceptos entrecruzados

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

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
  • www.angelfire.com/ri2/aspectos
  • Comunidad de Aspectos
  • dependex.dc.uba.ar/~ferto/

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.


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal