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
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
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 (Gp:) Clase A (Gp:) Clase A1 (Gp:) Attb1 Attb2 (Gp:) Método 1 (Gp:) Clase A2 (Gp:) Attb 3 (Gp:) Método 1 Método 2
POO: conceptos comunes 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. 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
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.
Página anterior | Volver al principio del trabajo | Página siguiente |