Amsterdam Trip

Next few days (till next Monday) we are going to be in Amsterdam . I´ll upload some pictures to the back.

Bye!

PD: I have some incoming posts: R grammar and ANTLR (PFC), AspectJ examples, Groovy/Grails introduction and something more.

AOP Benefits

Muchas de las críticas sobre la metodología AOP argumenta que en muchas ocasiones es demasiado complejo.

Personalmente, creo que al igual que cuando otras metodologías dieron el salto, como por ejemplo OOP, la novedad hace de ella su principal handicap.

Algunos de los beneficios del uso de una metodología AOP:

• Responsabilidades claramente diferenciadas . Cada módulo es el responsable de su funcionalidad principal; dejando a un lado los conceptos transversales (croscutting concerns). Así por ejemplo, un módulo cuyo principal cometido es implementar la lógica de acceso a datos de un sistema de ventas por internet, no tendrá que preocuparse de realizar pooling sobre la base de datos o de la transaccionalidad. Gracias a esta clara asignación de responsabilidades conseguimos una alta trazabilidad entre los requisitos y su correspondiente implementación.

• Incremento de la modularidad . Utilizando AOP conseguimos manejar cada uno de los conceptos de manera independiente con un acoplamiento mínimo. Incluso aunque tengamos presentes conceptos transversales que afecten en todos los ámbitos del sistema, la implementación resultante es modular.

• Retraso en las decisiones de diseño . Cuando se arquitecta un nuevo sistema siempre aparece el siguiente dilema: ¿debemos realizar un diseño sumamente complejo y detallado que intente abarcar todas las funcionalidades,incluso las futuras? o, por el contrario, ¿debemos arquiectar una solución que se corresponda con la situación actual?.

  Gracias a AOP, el arquitecto de la solución, puede retrasar la toma de determinadas decisiones de diseño dado que los futuros requerimientos se implementarán en aspectos independientes.

• Mejoras/Evoluciones más sencillas . AOP permite añadir una nueva funcionalidad sin más que desarrollar un nuevo aspecto (el cual no afecta al núcleo del sistema). Gracias a ello, el tiempo de respuesta ante nuevos requerimientos disminuye notablemente puesto que la implentación y diseño de los nuevos requisitos no supondrán, idealmente, una modificación del núcleo del sistema que estamos construyendo.

• Reutilización del código .AOP establece cada uno de los aspectos es un módulo independiente, de modo que resultan independientes entre si. En general, cada uno de ellos no suelen tener conocimiento del resto de elementos que conforman el sistema final.

  El único elemento consciente del acoplamiento entre los diferentes módulos son las reglas de tejido (weaving rules) , de modo que, si cambiamos éstas, podemos componer un sistema final completamente diferente.

• Reducción de costes. Las características descritas en los puntos anteriores generan sistemás desarrollos mucho más rápidos. Asimismo, eliminando la necesidad de modificar múltiples módulos para la implementación de un nuevo concepto que afecta al sistema completo, AOP provoca que dicha implementación sea más barata.

• Areas de conocimiento. Permitiendo que los desarrolladores estén centrados en su especialidad lograremos que el coste del desarrollo disminuya puesto que estaremos concentrando los esfuerzos.

En siguientes post veremos una introducción a AspectJ para adentrarnos un poquito más en el mundo de la orientación a aspectos.

Hasta pronto!

Some New York Photos (I)

Some of our New York pictures:

Murrays bagel: ummmmm!!! Our favourite breakfast :-)

M&M´s store:

Central Park from TOR:

St Pauls Chapel
Manhattan:

New York night from Empire State:

The SDHC card has more than 750 pictures :) ; i´ll upload some of them in future posts!

Bye!!