Universidad Tecnolgica de Panam

Facultad de Ingeniera de Sistemas Computacionales

Ambientes de Programacin

Programacin Orientada a Aspectos

Integrantes:
Janice Martnez
Steven Martnez
Nstor Martnez
Abdiel Martnez

Profesora: Yadira Martnez

Martes 18 de Agosto de 2009.

Introduccin............................................................................................................3
Separacin de Asuntos (Separation of Concerns).................................................4
Programacin Orientada a Aspectos......................................................................7
Lenguajes Programacin Orientado a Aspectos..................................................11
AspectJ..................................................................................................................11
AspectJ Puntos de Unin..................................................................................13
Aplicacin de AspectJ...........................................................................................14
Estudiar la Solucin Convencional primero..................................................14
2 Limitar la implementacin...........................................................................15
3 Generalizar la Solucin..............................................................................15
AspectJ y las Fases de Desarrollo.......................................................................15
Diseo............................................................................................................15
Implementacin.............................................................................................16
Fase de Pruebas...........................................................................................18
Ejemplo de AspectJ..............................................................................................18
Requerimientos.................................................................................................18
Implementacin Java.....................................................................................19
Implementacin en C#...................................................................................21
Implementacion C# con registro de sucesos en consola..............................22
Implementacin usando AspectJ...................................................................24
Implementacin de Aspecto en .Net C#...............................................................26
Ejemplo de Rastreo (Tracing) de Alto Nivel por Aspecto..............................26
Implementacin de XTraceMethodBoundaryAttribute..................................27
Inicializacin en Tiempo de Compilacin......................................................27
Mtodos en Tiempo de Ejecucin.................................................................29
Conclusin............................................................................................................30
Referencias...........................................................................................................31

Introduccin
La industria de desarrollo de software ha evolucionado grandemente en los ltimos
aos. Algunas veces como desarrollador es difcil mantenerse al da con las nuevas
tecnologas o procesos que cada da se incorporan. Sin embargo a pesar de todos los
avances que se estn dando existen problemas para los cuales todava no se tiene una
solucin ideal. Uno de estos problemas es la correcta modularizacin, en especial,
cuando se lidia con un sistema complejo y grande. La adopcin de OOP (siglas en
ingles) ha ayudado grandemente a que se avance para subsanar este dilema; sin
embargo, no es suficiente. La programacin orientada a aspectos va un paso ms all y
aunque lejos de ser una solucin ideal, subsana algunos deficiencias del modelado que
se logra por medio de OOP .

Separacin de Asuntos (Separation of Concerns)

El principio de Separacin de Asuntos fue propuesto en la dcada de 1970 por Edsger
W. Dijkstra en su ensayo: Rol del pensamiento Cientfico. En este ensayo Esdger
estableca que un problema dado debe ser separado en varios aspectos o asuntos.
Quince aos despus es evidente que el concepto de separacin de asuntos es
grandemente adoptado por los profesionales de la computacin. Como prueba de esto
podemos citar el libro publicado por Chris Reade Elementos de Programacin
Funcional. En el cuales se describe la separacin de asuntos de manera mas
detallada. Reade declara que el programador debe ser capaz de hacer varias funciones
a la vez:
-

Describir lo que se va a computar

Organizar la secuencia de computacin en pequeos pasos

Organizar la administracin de la memoria durante la computacin.

Como ya lo estableci Esdger en su ensayo, el proceso de separar un problema en la

suma de sus partes no es algo nuevo. El mismo se aplica en reas diferentes a la
programacin o en otras ingenieras. Como la construccin de objetos ms tangibles,
por ejemplo podemos citar la construccin de un helicptero

Podemos definir asuntos como los diferentes temas o asuntos de los que es necesario
ocuparse para resolver el problema. Una de ellos es la funcin especfica que debe
realizar una aplicacin, pero tambin surgen otros como por ejemplo distribucin,
persistencia, replicacin, sincronizacin, etc. Usualmente asuntos son equivalentes con
caractersticas o comportamientos del programa.
La Separacin de Asuntos es la base que promovi el desarrollo de los lenguajes
orientados a objetos, en donde dado un buen diseo es posible alcanzar mayores
niveles de reutilizacin, independencia. Con miras a conseguir una mayor productividad,
tambin se han creado patrones de desarrollo que ayudan a alcanzar una mejor
separacin de asuntos. Podemos mencionar Modelo Vista- Controlador(Model View
Controller).

Las tcnicas de modelado utilizadas actualmente en la etapa de diseo de un sistema

se basan en partirlo en varios subsistemas que resuelvan parte del problema o
correspondan a una parte del dominio sobre el que trata. Estas tcnicas sufren en su
mayora la llamada "tirana de la descomposicin dominante" que consiste en
guiarse al modelar, implcita o explcitamente, por una visin jerrquica determinada de
la organizacin del sistema.

El problema de estas tcnicas es que no contemplan el hecho que hay puntos de

funcionalidades (usualmente la funcionalidades no principales del sistema) que se van a
repetir dentro de la jerarqua en secciones que no tienen relacin entre s. De tal
manera que estos puntos no se adaptan al principio bsico de la separacin de asuntos.
Actualmente la solucin es repetir el cdigo, lo que introduce una serie de problemas

como incremento en el costo de mantener el software, decremento en la reusabilidad,

entre otros.

Estas responsabilidades, que aparecen diseminadas en el cdigo atravesando partes

del sistema no relacionadas en el modelo, se denominan asuntos transversales. Las
tcnicas de modelado convencional no separan bien los asuntos transversales (crosscutting concern). Incluso los lenguajes orientados a objetos, a pesar de las muchas
ventajas que nos presentan sufren de esta desventaja en particular.

Los asuntos transversales dan lugar a cdigo disperso y enredado (scattering and
tangling).

En el caso de scattering en lugar que un componente se enfoque en

desarrollar un solo asunto, el componente desarrolla varios asuntos. Cmo

desarrollador debemos conocer sobre todos los asuntos que se estn desarrollando en
el componente. Incrementando la curva de aprendizaje del cdigo de la aplicacin.

Los asuntos transversales se pueden clasificar en: Compaeros (Peers). Estos son
asuntos que se distinguen claramente uno de otros. Los mismos tienen el mismo nivel
de importancia. En el ejemplo familiar del ATM, retiro de efectivo, depsito, transferencia
de fondos todos son asuntos transversales compaeros (Peers).1 Estos asuntos se
pueden desarrollar como sistemas independientes, sin embargo al desarrollarse dentro
del mismo sistema nos encontramos con el hecho de que existe sobreposicin en la
codificacin de los mismos.

La otra categora de asuntos transversales se denomina extensiones. Las extensiones

son componentes que se construyen sobre una base. Usualmente representan servicios
o caractersticas adicionales. Mantener las extensiones separadas nos permite que un
problema complejo sea entendible. El problema con las extensiones radica en que se
necesita incluir un llamado de las mismas en el componente base. Al hacer esto se ha
hecho un cambio intrusivo en el cdigo base. Es decir el componente base estaba
completo antes de que decidiera aadir una nueva caracterstica por medio de las
extensiones. El cdigo con el cual se une un componente base a una extensin se

(Jacobson, et al., 2004)

denomina cdigo de unin (glue code). No importa que tan bueno sea el diseo, con las
tcnicas de modelado convencionales, el cdigo de unin es necesario.

Un ejemplo clsico de asuntos transversales es el logging o registro de sucesos en

una aplicacin. El registro de sucesos no es parte de la funcionalidad principal de la
aplicacin y el mismo est diseminado prcticamente en todos los mdulos de una
aplicacin. En la Figura 2 es una representacin grfica de los distintos componentes
de una aplicacin. Las secciones en rojo representan los llamados que se hacen al
cdigo que graba los sucesos; los rectngulos representan los diferentes mdulos de la
aplicacin. Como se puede apreciar en la figura el cdigo de registro de sucesos est
diseminado por diferentes componentes.

Programacin Orientada a Aspectos

Las tcnicas convencionales de modelado son un gran herramienta para estructurar un
sistema complejo de manera jerrquica; sin embargo, como ya hemos establecidos
presentan limitaciones.

Para superar estas limitaciones es necesaria una nueva metodologa modular que nos
permita: alcanzar verdadera separacin de los asuntos, incluyendo los asuntos
transversales, en todas las fases de desarrollo de software (requerimientos, anlisis,

diseo, codificacin y pruebas). Est nueva metodologa tambin debe permitir la

composicin de asuntos de manera coherente e integral.

Programacin orientada a aspectos es una de las respuestas al problema de los

asuntos transversales.

La programacin orientada a aspectos son una serie de

tecnologas que tratan de proveer una mejor solucin a la separacin de asuntos

transversales. La solucin que la AOP (Aspect Oriented Programming) presenta es la
modularizacin de los asuntos transversales. La modularizacin de los asuntos
transversales se denomina aspectos.

Debido a la escasa literatura en espaol sobre el tema, se presenta la terminologa

original en ingls.

Aspect (Aspecto) es una funcionalidad transversal (cross-cutting) que se va a

implementar de forma modular y separada del resto del sistema. El ejemplo ms
comn y simple de un aspecto es el logging (registro de sucesos) dentro del
sistema, ya que necesariamente afecta a todas las partes del sistema que
generan un suceso.

Join point (Punto de Cruce o de Unin) es un punto de ejecucin dentro del

sistema donde un aspecto puede ser conectado, como una llamada a un
mtodo, el lanzamiento de una excepcin o la modificacin de un campo. El
cdigo del aspecto ser insertado en el flujo de ejecucin de la aplicacin para
aadir su funcionalidad.

Advice (Consejo) es la implementacin del aspecto, es decir, contiene el cdigo

que implementa la nueva funcionalidad. Se insertan en la aplicacin en los
Puntos de Cruce.

Pointcut (Puntos de Corte) define los Consejos que se aplicarn a cada Punto
de Cruce. Se especifica mediante Expresiones Regulares o mediante patrones
de nombres (de clases, mtodos o campos), e incluso dinmicamente en tiempo
de ejecucin segn el valor de ciertos parmetros. Un ejemplo sencillo se puede
aplicar a clases que representen figuras geomtricas. En

Introduction (Introduccin) permite aadir mtodos o atributos a clases ya

existentes. Un ejemplo en el que resultara til es la creacin de un Consejo de
Auditora que mantenga la fecha de la ltima modificacin de un objeto,
mediante una variable y un mtodo setUltimaModificacion(fecha), que podran
ser introducidos en todas las clases (o slo en algunas) para proporcionarlas
esta nueva funcionalidad.

Target (Destinatario) es la clase aconsejada, la clase que es objeto de un

consejo. Sin AOP, esta clase debera contener su lgica, adems de la lgica del
aspecto.

Proxy (Resultante) es el objeto creado despus de aplicar el Consejo al Objeto

Destinatario. El resto de la aplicacin nicamente tendr que soportar al Objeto
Destinatario (pre-AOP) y no al Objeto Resultante (post-AOP).

Weaving (Tejido) es el proceso de aplicar Aspectos a los Objetos Destinatarios

para crear los nuevos Objetos Resultantes en los especificados Puntos de
Cruce. Este proceso puede ocurrir a lo largo del ciclo de vida del Objeto
Destinatario:

Aspectos en Tiempo de Compilacin, que necesita un compilador

especial.

Aspectos en Tiempo de Carga, los Aspectos se implementan cuando el

Objeto Destinatario es cargado. Requiere un ClassLoader especial.

Aspectos en Tiempo de Ejecucin.2

(Wikimedia Foundation, 2009)

10

Lenguajes Programacin Orientado a Aspectos

Como toda investigacin lleva a una aplicacin prctica la programacin orientada a
aspectos no es la excepcin. Existen varios lenguajes de programacin que han
implementado, algunos ms exitosos que otros, tcnicas para poder aplicar los
aspectos. Algunos de estos programas son especficos a un dominio y no se pueden
usar como lenguajes multi-propsitos. Otros han sido iniciativas de universidades y al
carecer del respaldo econmico no han tenido la adopcin esperada, quedando en las
fases experimentales. Cmo un ejemplo de este ltimo caso se puede mencionar a
Aspect.Net.
Aspect.Net es una implementacin de programacin orientada a aspectos para el
Framework .Net promovido por Vladimir O. Safonov de la Universidad de San
Petesburgo. Aspect.Net est conformado por dos herramientas:
Editor de Aspectos: permite aadir nuevos aspectos, explorar y seleccionar o no los
posibles puntos de unin.
Tejedor (Weaver): estadsticamente aplica el consejo (advice) a los puntos de unin que
se establece basado en las reglas descritas en el aspecto.
La implementacin de Aspect.Net no utiliza reflexin (conjunto de clases que puede
inferir informacin sobre las mismas clases, mtodos, etc.; incluyendo llamados
dinmicos), ya que los autores consideraron que el uso de reflexin no era suficiente
para la integracin de los aspectos. Hay que resaltar que la iniciativa de Aspect.Net se
inicio en el 2005 y el Framework de .Net ha avanzado desde esa fecha. Sin embargo el
proyecto actual de Aspect.Net slo es compatible con el Visual Estudio 2005 y el mismo
no es fcil de conseguir, a pesar de ser gratis. El autor todava considera que est en
una fase experimental.

AspectJ
Es una extensin multi-propsito de Java que implementa la programacin orientada a
aspectos. Est formada por una serie de herramientas que permiten a los
desarrolladores de Java administrar mejor los problemas inherentes de los sistemas

11

grandes y en general aplicar mejor la modularidad dentro de los mismos, en especial

aplicar correctamente la separacin de los asuntos transversales. Originalmente fue
desarrollado por profesionales del Centro de Investigacin de Palo Alto de Xerox, ahora
es parte del proyecto Eclipse.

Es un lenguaje prctico que provee, en un paquete compatible con Java, un set slido
de caractersticas de Programacin Orientada a Aspectos. No est diseado para ser
una encarnacin en blanco de las ideas de Programacin Orientada a Aspectos, no es
una implementacin formal ni un estudio agresivo del dominio y las oportunidades de la
POA.

AspectJ es una extensin compatible de Java que permite el manejo de asuntos

transversales (crosscutting concerns). Se entiende por compatibilidad los siguientes 4
puntos.

Compatibilidad ascendente: todos los programas de Java legales deben ser

programas legales de AspectJ.

Compatibilidad de plataforma: todos los programas legales de AspectJ deben

correr en mquinas virtuales estndares de Java.

Compatibilidad de herramienta: debe ser posible extender herramientas actuales

para que soporten AspectJ; esto incluye IDEs, herramientas de documentacin,
herramientas de diseo, etc.

Compatibilidad de Programacin: programar en AspectJ debe de ser como una

extensin natural de programar con Java.

AspectJ soporta dos implementaciones para los asuntos transversales. La primera se

denomina asuntos transversales dinmicos (dynamic crosscutting); por medio de este
mecanismo es posible definir implementaciones adiciones que sean ejecutadas en
puntos bien definidos de una aplicacin.

La otra implementacin se llama asuntos

12

transversales estticos (static crosscutting). En ella se definen nuevas operaciones en

tipos existentes.

AspectJ Puntos de Unin

Los puntos de unin (Joint points) son un elemento crtico en el diseo de cualquier
mecanismo de un lenguaje orientado a aspectos. AspectJ no es la excepcin. Este
modelo provee un marco de referencia que hace posible la ejecucin coordinada de
cdigo de aspectos junto con cdigo que no hace referencia a los aspectos.

La

implementacin de los asuntos transversales dinmicos se logra mediante los puntos de

unin.
Los diferentes tipos de puntos de unin que AspecJ tiene se presentan en la siguiente
tabla:
Tabla 2.1 Dummy

Tipo de Punto de Unin

Momento de ejecucin en el Programa en

el cual

Llamada de un mtodo
Llamade de un constructor

El mtodo (o el constructor de la clase) es

llamado. Los puntos de unin son el objeto
que hace el llamado. Si el mtodo es
esttico entonces es en ningn objeto.

Recepcin de la llamada de un Un objeto recibe el llamado de un mtodo

mtodo
Recepcin

o un constructor. Puntos de unin de

del

llamado

constructor

de

un

recepcin se dan antes que el mtodo o

constructor se haya despachado. Ejemplo;
ellos ocurren dentro del objeto llamado, en
un punto del flujo de control despus que
el control ha sido transferido al objeto que
hace el llamado, pero antes que cualquier
mtodo/constructor haya sido llamado.

Ejecucin de un mtodo

Un mtodo individual o constructor es

13

Ejecucin de un constructor

invocado.

Lectura de una propiedad

Una propiedad de un objeto, clase o

interfase es leda.

Escritura de una propiedad

Una propiedad de un objeto, clase o

interfase es escrita.

Ejecucin

de

un

manejo

de El manejo de excepcin es invocado.

excepcin
-

Inicializacin de una clase

Inicializadores estticos de una clase, si

existes, son ejecutados.

Inicializacin de un objeto

Cuando los inicializadotes dinmicos de

una

clase,

si

estn

presentes,

son

ejecutados durante la creacin de un

objeto

Aplicacin de AspectJ
Estudiar la Solucin Convencional primero En este paso, se diagrama,
disea, e incluso se crea un prototipo de la solucin convencional. La solucin
convencional resalta las ventajas de la solucin que provee AspectJ, el propsito
principal es ayudar a entender el diseo necesario para una mejor solucin con AspectJ.
La idea es identificar el cdigo disperso y enredado (scattering and tangling) y luego
modularizarlo. Una vez se logra suficiente experiencia en este paso, se puede reducir la
importancia del mismo o incluso eliminarlo..

14

2 Limitar la implementacinAl limitar la solucin a solo mdulos que

actualmente necesitan la funcionalidad, se elimina el impacto, tanto positivo como
negativo, en otros mdulos. El objetivo es dejar la mayor cantidad del sistema sin
afectar como sea posible y reducir el esfuerzo necesario en las pruebas. Para hacer
esto, se pueden usar puntos de corte como within() para especificar slo puntos de
unin en los mdulos donde se quiera hacer aplicar los aspectos. Como alternativa se
puede configurar el sistema para que slo utilice eso mdulos.

3 Generalizar la SolucinUna vez se haya probado ampliamente la solucin y

estudiado su impacto, se debe modificar los puntos de corte o cambiar la configuracin
que ha estado limitando el rea de aplicacin de la solucin. Por ejemplo, en lugar de
restringir el registro de sucesos a ciertos mdulos, se remueven las restricciones para
que la solucin se aplique en todo el sistema. De esta manera nuevos mdulos se
beneficiarn de esta solucin de manera inmediata apenas ingresen al sistema, sin
necesidad de esfuerzo adicional. La nica manera en que el paso tres se puede concluir
exitosamente es mediante la aplicacin asertiva de los pasos 1 y 2. Tanto el diseo
como una prueba contenida de la solucin son las bases para la implementacin exitosa
de aspectos a una aplicacin existente. 3

AspectJ y las Fases de Desarrollo

Cada fase de desarrollo (diseo, implementacin, pruebas, manutencin), registra una
serie de actividades de tal manera que la aplicacin prctica en el uso de AspectJ vara
en cada una.

Diseo
Al igual que cualquier proceso de desarrollo de software un buen diseo es la piedra
angular para que el proyecto se desarrolle de manera exitosa; disear software usando
AspectJ no es la excepcin a la regla. Al considerar el uso de AspectJ desde las etapas
inciales del diseo se obtiene los mayores beneficios de la utilizacin del mismo, ya
que se garantiza que los asuntos transversales son manejados correctamente e
integrados efectivamente por medio de los aspectos.
La manera tpica de utilizar AspectJ en la fase de diseo incluye:
3

(Laddad, 2003)

15

Reconocer los asuntos transversales. Este paso es parte del mapeo necesario
de requerimientos a mdulos. Una manera sencilla de identificar estos asuntos
es la utilizacin de frases como: cada vez, en todo lugar. Si nos encontramos
utilizando estas frases para describir parte de las funcionalidades en distintos
mdulos, tenemos ante nosotros un asunto transversal. Reconocer los asuntos
transversales a tiempo, permite que estos sean delegados a aspectos que se

integran fcilmente a los mdulos existentes.

Disear los asuntos principales primero. Se debe aplicar tcnicas estndares
para disear los asuntos principales. Entre mejor se realice esta labor, ser ms
fcil aplicar los asuntos transversales. Se recomienda la utilizacin de interfaces

con roles claros.

Disear los asuntos transversales. Implementar los asuntos transversales
primordiales. Es una buena idea tambin hacer un bosquejo de los asuntos
transversales que se hayan reconocido, pero no se necesiten inmediatamente.
De tal forma que no se trabaje de manera repetida en el diseo al considerarse

las posibles mejoras al mismo.

Como se puede observar disear para Programacin orientada a aspectos no es muy
diferente que el diseo convencional. La utilizacin de AspectJ nos fuerza a entender
claramente el diseo de la aplicacin y a acogernos a los estndares definidos para
lograr un diseo de calidad. Una vez se logre esto, la aplicacin de aspectos que se
encarguen de integrar los asuntos transversales se har de manera efectiva y sin costos
adicionales.

Implementacin
En general el proceso de implementar un sistema utilizando AspectJ no es muy
diferente que cuando se utiliza un lenguaje de orientacin a objetos. Hay algunas
consideraciones bsicas en las cuales se debe hacer ms nfasis como:
-Separar en mdulos correctamente el cdigo: idealmente cada operacin debe
corresponder con una funcionalidad. La unidad granular para definir los puntos de unin
son los mtodos. Es importante que cada mtodo tenga una funcin clara y concisa. De
esta manera el aplicar un aspecto ser pan comido.
-Uniformidad en la nomenclatura: Esta es una regla que se debe aplicar
independientemente si se est trabajando con AspectJ o no. Toma incluso ms
relevancia cuando se utiliza AspectJ. Una de las ventajas de AspectJ es que se pueden
definir puntos de unin mediante el uso de comodines. Si somos consistentes con la
nomenclatura podremos aplicar eficientemente los puntos de unin.

16

Algunas otras consideraciones incluyen:

- Separar los asuntos principales de los asuntos transversales (Igual que en la
-

fase de diseo)
Buscar activamente secciones de cdigo que se presenten repetidas (scattering)

o enredadas (tangling).
Identificar los puntos de unin. Una vez se ha determinado la existencia de un
asunto transversal, se tiene que identificar ya de una manera tangible los puntos
en cdigo que requieren la aplicacin del asunto transversal. De igual forma se
debe determinar cul es la mejor manera de expresar el punto de corte que

contenga todos los puntos de unin identificados previamente.

Elegir la tecnologa correcta para implementar el asunto transversal. (API de
reglas, o el motor de reglas, etc). Esto depender de la arquitectura general del

sistema.
Disear los aspectos. Se puede considerar utilizar patrones como plantillas para
disear los aspectos. Tambin es necesario aplicar una nomenclatura
consistente a los aspectos en s. Esto facilitar la aplicacin e puntos de unin
dentro de los aspectos si as se requiera. Es vlido tambin determinar si los
mismos aspectos se pueden reutilizar en otros sistemas que presenten los

asuntos transversales que se quieren resolver.

En general al igual que en diseo la implementacin de los aspectos no es
estructuralmente diferente pues se basa en conceptos existentes aplicables a la
orientacin a objetos. El aspecto adicional sera la creacin del aspecto en s. Se hace
mayor nfasis en mantener una nomenclatura uniforme e identificar todos los puntos de
unin mediante la definicin de los puntos de corte.

Fase de Pruebas
AspectJ provee una serie de escenarios que ayudan a automatizar el proceso de
pruebas de la aplicacin. Debido a la naturaleza no intrusiva de los aspectos se puede:
Crear casos de usos: Por medio del uso de aspectos privilegiados se puede acceder a
los elementos privados de una clase. Esto permite que se creen programas de prueba
sin que se modifiquen la clase original que se quiere probar. Una vez se haya
garantizado que las pruebas dan los resultados esperados, los aspectos se pueden
sacar del sistema fcilmente.
Pruebas de desempeo: Para tal fin se pueden crear aspectos que ayuden a monitorear
el desempeo de la aplicacin cuando este en la versin beta.
Reporte de errores: se pueden usar aspectos que brinden informacin adicional acerca
del contexto de los errores. El contexto no slo incluye el stacktrace sino toda la

17

informacin que est disponible en el punto de unin donde se dio el error. En este
sentido los reportes de errores son superiores a la informacin estndar que proveen
los compiladores.

Ejemplo de AspectJ
Haciendo alusin al asunto transversal sobre registros de sucesos. Presentamos el
siguiente ejemplo. Es una pequea aplicacin que tiene como objetivo simular algunos
flujos existentes en un saln de clases.

Requerimientos
Los requerimientos del micro sistema son:
- Permitir a los estudiantes registrar clases
- Permitir a los profesores asignar tareas
- Permitir a los profesores fracasar estudiantes
- Listar la lista de tareas asignadas a una clase
- Listar la lista de estudiantes registrados en una clase
- Permitir al estudiantes que se retire de la clase
- Asignar a un profesor con determinada clase
- Registrar los sucesos que ocurran en el sistema
Debido a que este es un ejemplo prctico enfocado en mostrar las diferencias bsicas y
ventajas de utilizar AspectJ, la parte grfica del micro sistema no ser desarrollada. El
ejemplo se enfocar en crear las clases necesarias que satisfagan los requerimientos
antes sealados.
El siguiente diagrama de clases muestra el diseo inicial con el cual se pretende cumplir
con todos los requerimientos antes mencionados.

18

Como se puede observar en el diagrama la clase principal del sistema es la clase Class.
A continuacin podemos ver la implementacin del cdigo en AspectJ y posteriormente
la implementacin del cdigo en C#.

Implementacin Java
package com.object.model;
import java.util.ArrayList;
import java.util.*;
public class Class {
private ArrayList<Task> ActiveTasks;
private ArrayList<Student> RegisteredStudents;
private String _ClassName;
private Professor _Professor;
public Class()
{
ActiveTasks = new ArrayList<Task>();
RegisteredStudents = new ArrayList<Student>();
}
public void SetClassName(String name)
{
_ClassName = name;
}
public String GetClassName()
{
return _ClassName;
}
public void AddStudent(Student newStudent)
{
RegisteredStudents.add(newStudent);
}
public void RemoveStudent(Student newStudent)
{
RegisteredStudents.remove(newStudent);
}
public void AddTask(String name, Date dueDate)
{
Task newTask = new Task();
newTask.SetName(name);
newTask.SetDueDate(dueDate);
ActiveTasks.add(newTask);
}
public void RemoveTask(Task taskToRemove)
{

19

if(ActiveTasks.contains(taskToRemove))
{
ActiveTasks.remove(taskToRemove);
}
}
public void ListStudents()
{
for(int i = 0; i < RegisteredStudents.size(); i ++)
{
System.out.println("Student name: "
+ RegisteredStudents.get(i).GetName()
+ " " + RegisteredStudents.get(i).
GetLastName() );
}
}
public void ListTasks()
{
for(int i = 0; i < ActiveTasks.size(); i ++)
{
System.out.println("Task name: "
+ ActiveTasks.get(i).GetName()
+ " Due date: " + ActiveTasks.get(i).
GetDueDate().toString() );
}
}
public void SetProfessor(Professor newProfessor)
{
_Professor = newProfessor;
}
public Professor GetProfessor()
{
return _Professor;
}
}

Implementacin en C#
using
using
using
using

System;
System.Collections.Generic;
System.Linq;
System.Text;

namespace ObjectModel
{
public class Class
{
List<Student> RegisteredStudents;
List<Task> ActiveTasks;

20

Professor _Professor;
public string ClassName
{
get;
set;
}
public Class()
{
RegisteredStudents = new List<Student>();
ActiveTasks = new List<Task>();
}
public void AddStudent(Student newStudent)
{
RegisteredStudents.Add(newStudent);
}
public void RemoveStudent(Student newStudent)
{
RegisteredStudents.Remove(newStudent);
}
public void AddTask(string name, DateTime dueDate)
{
Task newTask = new Task();
newTask.Name = name;
newTask.DueDate = dueDate;
ActiveTasks.Add(newTask);
}
public void RemoveTask(Task taskToRemove)
{
if (ActiveTasks.Contains(taskToRemove))
{
ActiveTasks.Remove(taskToRemove);
}
}
public void ListTasks()
{
foreach (var tempTask in ActiveTasks)
{
Console.WriteLine("Taks name: " + tempTask.Name + " due
date " + tempTask.DueDate);
}
}
public void ListStudents()
{
foreach (var tempStudent in RegisteredStudents)
{
Console.WriteLine("Student name: " + tempStudent.Name +
" " + tempStudent.LastName);
}
}
}

21

Las dos implementaciones son muy parecidas y en apariencia cumplen con los
requerimientos sealados. Existen algunas diferencias inherentes al syntaxis propios de
los lenguajes, pero en teora la implementacin es la misma.

No obstante, si

observamos cuidadosamente nos podemos percatar que ninguna de las dos

implementaciones cumple con el requerimiento sobre registrar todos los sucesos que se
esten realizando en el sistema. Necesitamos hacer unos ajustes en ambas
implementaciones para satisfacer todos los requerimientos.

Implementacion C# con registro de sucesos en consola

using
using
using
using

System;
System.Collections.Generic;
System.Linq;
System.Text;

namespace ObjectModel
{
public class Class
{
List<Student> RegisteredStudents;
List<Task> ActiveTasks;
Professor _Professor;
public string ClassName
{
get;
set;
}
public Class()
{
Console.WriteLine("CTor init");
RegisteredStudents = new List<Student>();
ActiveTasks = new List<Task>();
Console.WriteLine("CTor end");
}
public void AddStudent(Student newStudent)
{
Console.WriteLine("AddStudent init");
RegisteredStudents.Add(newStudent);
Console.WriteLine("AddStudent init");
}
public void RemoveStudent(Student newStudent)
{
Console.WriteLine("RemoveStudent init");
RegisteredStudents.Remove(newStudent);

22

Console.WriteLine("RemoveStudent end");

public void AddTask(string name, DateTime dueDate)

{
Console.WriteLine("AddTask init");
Task newTask = new Task();
newTask.Name = name;
newTask.DueDate = dueDate;
ActiveTasks.Add(newTask);
Console.WriteLine("AddTask end");
}
public void RemoveTask(Task taskToRemove)
{
Console.WriteLine("RemoveTask init");
if (ActiveTasks.Contains(taskToRemove))
{
ActiveTasks.Remove(taskToRemove);
}
Console.WriteLine("RemoveTask end");
}
public void ListTasks()
{
Console.WriteLine("ListTasks init");
foreach (var tempTask in ActiveTasks)
{
Console.WriteLine("Taks name: " +
tempTask.Name + " due date "
+ tempTask.DueDate);
}
Console.WriteLine("ListTasks end");
}
public void ListStudents()
{
Console.WriteLine("ListStudents init");
foreach (var tempStudent in RegisteredStudents)
{
Console.WriteLine("Student name: "
+ tempStudent.Name + " " + tempStudent.LastName);
}
Console.WriteLine("ListStudents end");
}
}

Como se observa en la nueva implementacin, se ha tenido que agregar varas lneas

de cdigo para poder cumplir con el requerimiento sobre registro de sucesos. Han sido
necesario agregar ms de diez lneas de cdigo para poder implementarlo. Ahora bien
esto slo ha sido en una clase. Es decir que todas las clases de la aplicacin debern
ser modificadas con llamados similares. Se puede discutir que es un proceso mecnico,

23

que solo es copiar y pegar lo que lo hace fcil de implementar. No obstante este no es
el nico problema que esta implementacin presenta. Supongamos que se decide
cambiar de estrategia y ya no se quiera desplegar los registros de sucesos en consola,
sino que se quieran grabar en un archivo de texto o en una base de datos. Habra que
cambiar todos los llamados en las clases. Este proceso es ineficiente y distrae al
programador de la implementacin de las funcionalidades principales.

Implementacin usando AspectJ

package com.object.model;
import org.aspectj.lang.*;
public aspect LoggingAspect {
pointcut traceMethods()
: execution(* *.*(..)) && !within(LoggingAspect);
before() : traceMethods() {
Signature sig = thisJoinPointStaticPart.getSignature();
String sigName = sig.getName();
String declaringName = sig.getDeclaringTypeName();
System.out.println(declaringName + " " + sigName + " init");
}
after() : traceMethods(){
Signature sig = thisJoinPointStaticPart.getSignature();
String sigName = sig.getName();
String declaringName = sig.getDeclaringTypeName();
System.out.println(declaringName + " " + sigName + " end");
}
}

Por medio del uso del aspecto LogginAspect podemos incluir registros de sucesos en
todas las clases. Hemos modularizado exitosamente el asunto transversal. Ya que hay
un slo lugar donde se maneja el registros de suceso, sera muy sencillo cambiar el
mtodo consola por log4j o la librera estndar de Java para registrar sucesos
AspectJ tambin nos presenta una herramienta muy til con la que se pueden ver los
puntos de unin que cumplen la condicin.

24

Por medio del uso de esta herramienta podemos tener una idea exacta de cuantos
puntos de unin se han identificado para cada uno de los puntos de corte.

25

Implementacin de Aspecto en .Net C#

Para la implementacin de la tecnologa de programacin orientada aspecto nosotros
encontramos una herramienta llamada PostSharp. Existen otras libreras que permiten
la implementacin de esta tecnologa en .Net. Esta herramienta nos permite reducir el
nmero de lneas de cdigo en la mayora (si no todos) de los lenguajes .Net
implementando aspecto.
PostSharp nos facilita la implementacin en nuestro cdigo encapsulando los aspectos
como atributos personalizados, haciendo nuestra vida ms fcil y la implementacin
ms placentera.

Ejemplo de Rastreo (Tracing) de Alto Nivel por Aspecto

En este ejemplo se demuestra el rastreo utilizando de Postsharp.
En este ejemplo se podr hacer rastreo de excepciones, acceso a campos e invocacin
de mtodos.
Tambin hace rastreo de los valores de los parmetros.
En el ejemplo ilustra cmo utilizarlo en tiempo de inicio de compilacin.
Objetivo
Desarrollar los atributos personalizados
XTraceExceptionAttribute: escribe un mensaje cuando el mtodo a la cual se aplica
falla con una excepcin.
XTraceFieldAccessAttribute: escribe un mensaje cada vez que un campo a la cual es
aplicada es accesado, una operacin get o set.
XTraceMethodBoundaryAttribute: escribe un mensaje cuando el mtodo a la cual es
aplicada comienza o termina, ya sea exitoso o no.
XTraceMethodInvocationAttribute: escribe un mensaje cuando el mensaje a la cual es
aplicada es invocada (este mtodo puede estar definido en otro assembly).
Nosotros queremos hacer rastreo de la forma ms detallada posible, por ejemplo,
nosotros queremos escribir los valores de parmetros, valores de variables y ms.
Tambin queremos tomar ventaja de la inicializacin en tiempo de compilacin para
evitar formateando el texto a la hora de ejecutar.
Como los cuatro aspectos son muy similares, smo vamos a comentar el que se utiliza
de forma ms comn, XTraceMethodBoundaryAttribute.

26

Implementacin de XTraceMethodBoundaryAttribute
Como queremos insertar cdigo antes y despus del cuerpo del mtodo, vamos a
derivar nuestro atributo personalizado de OnMethodBoundaryAspect e implementamos
los mtodos OnEntry, OnSuccess y OnException.
El esqueleto de nuestro atributo personalizado es:
[Serializable]
public sealed class XTraceMethodBoundaryAttribute : OnMethodBoundaryAspect
{
public override void OnEntry(MethodExecutionEventArgs context)
{
}
public override void OnSuccess(MethodExecutionEventArgs eventArgs)
{
}
public override void OnException(MethodExecutionEventArgs eventArgs)
{
}
}

Inicializacin en Tiempo de Compilacin

Escribiendo el nombre con todos sus parmetros y los parmetros de tipo genrico no
es trivial. Requiere una potencia de clculo que no podemos rechazar si queremos que
nuestro aspecto de trace un rendimiento de ejecucin aceptable.
Hay muchas que se conocen en tiempo de compilacin: el nombre del tipo y el mtodo,
el nmero de parmetros genricos y el nmero y tipo de parmetros. As que
escogimos que en tiempo de compilacin, se va a crear una plantilla (formatear cadena)
y en tiempo de ejecucin, para formatear estas plantillas utilizando parmetros
concretos y parmetros genricos recibidos.
Por ejemplo, si nosotros tenemos un mtodo:
MyType<T1>::MyMethod<T2>(T2 arg1, int arg2)

la plantilla puede ser:

MyType<{0}>::MyMethod<{1}>({2}, {3})

En tiempo de ejecucin, nosotros proveeremos un arreglo con los parmetros.

27

La funcionalidad de preparar plantillas y la implementacin esta encapsulado en

las clases Formatter y MethodFormatStrings. Su implementacin no es de
inters en nuestra discusin, as que no lo vamos a describir en nuestro ejemplo.
Cmo podemos realizar esto con PostSharp?
Primero, definimos las instancias de los campos que contienen las cadenas de
formateo y otras cosas que no queremos computar o calcular en tiempo de
ejecucin. Despus, implementamos el mtodo CompileTimeInitialize para
configurar estos campos. Durante la post-compilacin, PostSharp Laos
serializar el objeto.

Eso significa que los campos que son inicializados en

tiempo de compilacin para ser utilizados en tiempo de ejecucin deben ser

serializables. Como este es el comportamiento predeterminado, no tenemos
que ponerle mucha atencin a eso.

Finalmente aqu est el cdigo de inicializacin en tiempo de compilacin:

string prefix;
MethodFormatStrings formatStrings;
bool isVoid;
public string Prefix
{
get { return this.prefix; }
set { this.prefix = value; }
}
public override void CompileTimeInitialize(MethodBase method)
{
this.prefix = Formatter.NormalizePrefix(this.prefix);
this.formatStrings = Formatter.GetMethodFormatStrings(method);
MethodInfo methodInfo = method as MethodInfo;
if (methodInfo != null)
{
this.isVoid = methodInfo.ReturnType == typeof(void);
}
else
{
this.isVoid = true;
}
}

28

Mtodos en Tiempo de Ejecucin

Vamos

de

vuelta

nuestro

esqueleto

de

nuestra

clase

XTraceMethodBoundaryAttribute. Tenemos que implementar los mtodos

OnEntry, OnSuccess and OnException. Todo lo que tenemos que hacer es
formatear las plantillas con los parmetros concretos y llamar el mtodo
Trace.TraceInformation.
public override void OnEntry(MethodExecutionEventArgs context)
{
Trace.TraceInformation(
this.prefix + "Entering " +
this.formatStrings.Format(
context.Instance,
context.Method,
context.GetArguments()));
Trace.Indent();
}
public override void OnSuccess(MethodExecutionEventArgs eventArgs)
{
Trace.Unindent();
Trace.TraceInformation(
this.prefix + "Leaving " +
this.formatStrings.Format(
eventArgs.Instance,
eventArgs.Method,
eventArgs.GetArguments()) +
(this.isVoid ? "" : Formatter.FormatString(" : {{{0}}}.",
eventArgs.ReturnValue)));
}
public override void OnException(MethodExecutionEventArgs eventArgs)
{
Trace.Unindent();
Trace.TraceWarning(
this.prefix + "Leaving " +
this.formatStrings.Format(
eventArgs.Instance,
eventArgs.Method,
eventArgs.GetArguments()
)+
Formatter.FormatString(" with exception {0} : {{{1}}}.",
eventArgs.Exception.GetType().Name,
eventArgs.Exception.Message));
}

29

Conclusin
Por medio del desarrollo de esta monografa se ha podido apreciar las ventajas que
AspectJ y PostSharp brindan en el desarrollo de un sistema. Descartando el esfuerzo
necesario para aprender sobre la sintaxis requerida para especificar los puntos de
cortes de los diferentes aspectos que se han querido introducir al sistema, el uso
correcto de garantiza un menor tiempo escribiendo cdigo. Si bien es cierto que esta
labor sera un proceso mecnico, por medio de estos marcos de trabajo se puede
eliminar el mismo.

En cuanto al esfuerzo y tiempo necesario para disear la aplicacin, AspectJ y

PostSharp requieren un poco ms de tiempo en elaborar un diseo efectivo. No slo es
necesario disear los componentes o mdulos de la manera convencional, sino que
tambin se deben identificar los asuntos transversales de manera clara y concisa. De
igual forma se debe identificar los puntos de corte y la sentencia necesaria para
aplicarlos correctamente. En este proceso de diseo tambin se debe hacer nfasis en
las convenciones para nombrar las variables, clases y mtodos. Ya que la uniformidad
en la nomenclatura nos facilitar la aplicacin de puntos de corte por medio del uso de
comodines. La uniformidad en la nomenclatura debe ser en cualquier caso parte del
diseo convencional.

Para llegar a comprender mejor el abanico de oportunidades que AspectJ y PostSharp

nos presentan a la hora de disear y desarrollar un sistema sera necesario adquirir
mayor experiencia prctica con el mismo. Quizs entre las desventajas de desarrollar
con estos marcos de trabajo es que nos fuerzan a pensar en un mejor diseo, conocer
las clases con las que uno trabaja en caso de no ser clases propias y las relaciones
entre ellas. Este proceso no es inmediato y requiere una curva de aprendizaje elevada
si se pretende aprovechar todo el potencial de AspectJ y PostSharp.

30

Referencias
Gael Fraiteur. Bringing AOP to .NET, PostSharp.
[En lnea]
http://www.postsharp.org/
An Overview of AspectJ. Kiczales, Gregor, y otros. 2001. Berlin : Springer
Berlin / Heidelberg, 2001. pgs. 327-354. 978-3-540-42206-8.
Eisenberg, Andrew. 20009. Aspects Everywhere: Language Extensibility
for JDT through Equinox Aspects. [En lnea] 23 de marzo de 20009. [Citado el:
21 de junio de 2009.] http://www.eclipsecon.org/2009/sessions?id=648.
Gonzlez, Abdiel E. Cceres. 2004. Programacin Orientada a Aspectos.
Mexico : Centro de Investigacin y de Estudios Avanzados Mexico, 2004.
Jacobson, Ivar y Ng, Pan-Wei. 2004. Aspect-Oriented Software
Development with Use Cases. s.l. : Addison Wesley Professional, 2004. 0-32126888-1.
Laddad, Ramnivas. 2003. AspectJ in Action - Practical Aspect-Oriented
Programming. New York : Manning, 2003.
Safonov, Vladimir. 2005. Aspect.NET: Aspect-Oriented Programming for
Microsoft.NET in Practice. [En lnea] 28 de julio de 2005. [Citado el: 17 de
junio de 2009.] http://dotnet.sys-con.com/node/113337?page=0,1.
Wikimedia Foundation. 2009. Aspect Oriented Programming, Wikipedia.
[En lnea] 2 de junio de 2009. [Citado el: 4 de junio de 2009.]
http://en.wikipedia.org/wiki/Aspect_oriented_programming.
. 2009. Separation of Concerns. [En lnea] 2 de mayo de 2009. [Citado el: 1
de junio de 2009.] http://en.wikipedia.org/wiki/Separation_of_concerns.

31