APLICACIONES DE ESTE PARADIGMA

• Manejo de transacciones

  Una transaccion en un sistema de gestion de bases de datos (SGBD), es un conjunto de ordenes que se ejecutan formando una unidad de trabajo, es decir, una forma indivisible o atomica.

  La estructura de una transacción usualmente viene dada según el modelo de la transacción, estas pueden ser planas (simples) o anidadas.

  
  

  El Manejo Transaccional es uno de los temas cruciales en cuanto a requerimientos para aplicaciones empresariales. Esta motivación surge debido a que en todo sistema empresarial nos interesa mantener la integridad de nuestra información, con esto en mente es que surge el tema de transacciones.

  En la figura podemos observar un método de servicio que ejecuta llamadas a más de un DAO, y a su vez cada DAO modifica el estado de la base de datos al escribir y/o modificar su información.

  El objetivo de una transacción es ejecutar todas las líneas de código de nuestro método y guardar finalmente la información en un repositorio, por ejemplo en nuestro caso, una base de datos. Esto se conoce como commit de nuestra transacción.

  Si por alguna razón algo fallara en nuestro método de Servicio, se daría marcha atrás a los cambios realizados en la base de datos. Esto se conoce como rollback.

  Lo anterior permite que nuestra información, ya sea que se una única base de datos o no, esté íntegra, y no exista posibilidad de datos corruptos por errores o fallas en la ejecución de nuestros métodos.

  Spring:AOP e Hibernate han implementado el manejo transaccional a partir de la Programación Orientada a Aspectos debido al acceso de datos y funciones transversales

  
  

• Sincronización

  La sincronización expuesta aquí se basa en los procesos y nos referimos a ella por el hecho de que esta otorga varias técnicas de coordinación de hilos que se ejecutan en forma simultánea y procesos para poder completar una determinada tarea con el objetivo de que estas se ejecuten en un orden establecido y que no se dé lugar a eventos inesperados.

  Mencionamos a continuación en forma general los tipos de sincronización existentes: Barrier, Bloqueo/Semáforo (Lock/Semaphore), Unión de hilos (Thread join), Exclusión Mutua (Mutex), Monitores (Monitors), Sincronización no bloqueante (Non-blocking synchronization), Rendezvous, Contadores de eventos y secuenciadores (Event counters and sequencers).

  Con esto nos ahorramos el hecho de colocar en cada método la palabra clave lock, el cual garantiza la ejecución de una sección crítica de código o exclusión mutua también denominada, una sección crítica de código es aquella que no permite ser ejecutada al mismo tiempo, debido a que puede darse el caso de que haya lectura sucia o que al mismo tiempo dos o más hilos de ejecución traten de modificar el valor de una variable, por lo tanto se bloquea dicha sección de código en forma exclusiva en un ambiente concurrente, no permitiendo de esta forma a que otro hilo trate de ejecutar esa sección crítica en un instante dado.

  Además al evitar repetir esta palabra clave nos aseguramos de no repetir código por un lado y por otro de separar la funcionalidad básica del aspecto de sincronización.

  En la definición del aspecto de sincronización expuesto más arriba, podemos decir que existen dos métodos, el primero llamado OnEntry el cual habilita la entrada a la ejecución del código de sección crítica y se utiliza la clase Monitor que provee un mecanismo para sincronizar el acceso a los objetos y el segundo método llamado OnExit, que se usa para realizar el abandono de la sección crítica de la ejecución del código, por lo tanto se invoca al método Exit de la clase Monitor.

  
  
  

• Perfiles

  Tomaremos como ejemplo la Extensión de UML usando Perdiles:

  En la actualidad, UML (Unified Modeling Language) es uno de los lenguajes de modelado más utilizados para el diseño de sistemas. Este lenguaje permite especificar, construir, visualizar y documentar artefactos de un sistema de software de manera sencilla.

  Muchas veces UML es demasiado general y no es lo suficientemente expresivo para modelar elementos específicos de un dominio particular. En estas situaciones es necesario, extender UML.

  Por esta razón, UML estándar incluyó un mecanismo para extender y adaptar UML a diferentes dominios y plataformas: el “Perfil UML” (“UML Profile”)

  Para realizar la extensión UML 2.0 incluyó la definición del paquete “Profile”. Éste paquete incluye los mecanismos para redefinir estereotipos, valores etiquetados y restricciones.

  La propuesta de extensión del perfil, no permite modificar al metamodelo existente, sino adaptar al metamodelo existente, agregando constructores propios para un dominio particular.

  Los estereotipos son especificados como metaclases, los valores etiquetados como metaatributos y los perfiles como una clase de paquete.

  
  

• Manejo de Memoria

  Ya que la principal tarea de la memoria consiste en llevar un registro de las partes de memoria que se estén utilizando y las que no , con el fin de asignar espacio en memoria a los procesos cuando éstos la necesiten y liberándola cuando terminen, así como administrar el intercambio entre la memoria principal y el disco. El uso de este paradigma de programación ahorra el uso de memoria al no guardar multiples veces las mismas funciones y código en diferentes clases, sino que al aprovechar el fundamento de su paradigma, accede a esta información de manera más eficiente a un sólo bloque de código y no necesita tener código de ejecución sino que es ejecutado bajo ciertas reglas.

• Control de Acceso o Seguridad

  Debido al uso eficiente del paradigma dentro del uso de las cuentas y perfiles, también afecta directamente el uso de los controles de acceso y la seguridad. Ya que la aplicación se mantiene generalmente igual para cada usuario, solamente difiere su acceso (o no acceso). Por lo que sería rebundante replicar código para cada sesión o la certificación o no del usuario.

  Además, al haber solamente un bloque de código de datos importantes y confidenciales, habrá menos riesgo de encontrar dichos datos. Y es más sencillo controlar el acceso a esos datos si solamente están confinados a un control de acceso y no de manera múltiple.

  
  

• Logging

  De manera similar al Control de Acceso, el Logging es una forma menos generalizada, pero cumple con las mismas características.

  
  

• Manejo de Excepciones

  A través del enfoque de AOP, es posible interceptar las llamadas a los métodos y determinar cuando estos han generado una excepción para posteriormente aplicar la política de manejo más apropiada. Estas políticas puede ser parte del propio aspecto de gestión de excepciones. Como en el caso del registro de eventos, la implementación de este aspecto buscará reducir su implementación (y aplicación) a un atributo que decore el método cuyas posibles excepciones se quieren gestionar.

  Un Apropiado Soporte

  Al crear un mecanismo de gestión y manejo de excepciones, no deberíamos partir desde cero, ya que existe un montón de excelentes productos y frameworks que nos simplificarían esta tarea. Para este caso, emplearé los Microsoft Libraries, en particular el Exception Handling Application Block; sin embargo el enfoque de AOP y de este framework que he venido presentado permite emplear cualquier otra librería.

  Implementación

  Es importante que si no han leido las primeras partes de esta serie de artículos, aprovechen este momento para hacerlo, sobre todo la parte 1. A partir de este momento mis explicaciones considerarán que el conocimiento y los detalles técnicos explicados en esa parte ya son conocidos.

  El primer paso es crear el atributo (Attribute) que decorará las clases/interfaces para capturar su ejecución e inyectar el código de manejo de excepciones. Nuestro atributo se llamará ExceptionHandlingAttribute y extiende de InterceptableAttribute, la clase base en el framework de AOP que sirve para definir atributos de intercepción.