Metodología para el Soporte del Diseño de Framework Basados en Programación Orientada a Aspectos

Methodology to Support the Design of Framework based on Aspect Oriented Programming.

Xavier S. Medianero P.Universidad Tecnológica de Panamá

Facultad de Ingeniería de Sistemas Computacionales

xavier.medianero@utp.ac.pa

RESUMENEste trabajo presenta una propuesta sobre una metodología para el soporte del proceso de generación de frameworks basado en programación orientada a aspectos y una herramienta de apoyo para diagramar, interrelacionar, analizar y diseñar el sistema de clases y aspectos del framework para su posterior migración a código Java. La metodología incluye elementos que minimizan inconvenientes de la Programación orientada a aspectos como los estructurales, de comportamiento, por multifuncionalidad y de dinamismo. La metodología pretende minimizar los esfuerzos en la determinación de Puntos de Corte o Puntos de Unión de aspectos, al igual que incrementar la cohesión de las clases, componentes y aspectos, en conjunto con la implementación de una capa semántica superior para una mayor abstracción de concepto en el desarrollo de frameworks basados en Aspectos.

ABSTRACTThis paper is an approach about a methodology to support the process of generation of framework based on aspect oriented programming and a support tool for diagramming, interrelate, analize and design the classes and aspects sets of the framework for future migration to Java code. The methodology includes elements that minimize the disadvantages of aspect-oriented programming such a structural, behavior, dynamism and multifunctionality. The methodology seeks to minimize the efforts in determining the cut-point and join-point issues, as well as increasing the cohesion of classes, component and aspects together with the implementation of a superior semantic layer to greater abstraction of concept in the development of framework based on aspects.

Categories and Subject DescriptorsD.2.1 (Software Engineering): Requirements/Specifications – Methodologies & Tools.

General TermsDesign, Management, Documentation, Performance.

KeywordsFramework, Aspect Oriented Programming, AspectJ, Join-Point Model, Weaving Model.

Palabras ClavesFramework, Programación Orientada a Aspectos, AspectJ, Modelo Join-Point, Modelo Weaving.

1. INTRODUCCIÓNLos Frameworks son generadores de aplicación hacia un dominio específico [1]. Los framework contienen módulos, métodos y características de software cuya función es ser un molde para aplicaciones que se deriven del mismo, es decir, que utilicen el mismo núcleo y estén cubiertas por un área específica.

Los frameworks están compuestos por dos secciones: el núcleo conocido como “los puntos congelados”, que representan las clases, librerías, métodos y módulos que son iguales y que sirven como base para todas las aplicaciones, es decir la parte inmutable e invariable del framework, en otras palabras, todas las aplicaciones generadas por este framework tendrán las mismas características base guardadas en esta capa. La segunda sección son las ranuras conocidas como “los puntos calientes”, que representan los elementos que pueden adaptarse, agregarse o simplemente prescindir de ellos en la aplicación, puede imaginarse como un checklist donde se eligen los métodos extras que debe tener la aplicación, los elementos en las ranuras no deben ser obligatorios para el funcionamiento del framework [1].

Existen varios paradigmas utilizados en la elaboración de estos frameworks, dentro de los cuales se encuentra la orientación a objetos, a aspectos, a servicios, entre otros. El modelado de aspectos toma en consideración dos aspectos según [2]: modelos dinámicos que tratan los eventos y la traza de eventos y los modelos estáticos que ocupa los puertos de aspectos y el tipo de mensaje.

La utilización de frameworks basados en orientación a aspectos (Fb-AOP) presenta ventajas sobre las otras arquitecturas debido a que permite:

Encapsular la abstracción de los aspectos

Incnrementa la reusabilidad logrando mayor separación de conceptos.

Integra los elementos del núcleo con las propiedades y métodos de las ranuras que están en función de los aspectos.

Mejora el diseño del framework del software.

Maximiza la flexibilidad del prototipo.

Facilita la configuración de los puntos calientes en base a aspectos que son generalmente módulos que contienen las reglas del negocio.

La AOP presenta algunos problemas prácticos [3] como lo son los conflictos estructurales debidos a un frágil Punto de Corte (normas que regulan los Join-Point), en otras palabras, el modelo basado en Join-Point tiene ligeros problemas al momento de definir los Puntos de Corte cuando el código se ha expandido, ya que este depende de la estructura base de cómo fue programado el software causando que la evolución y expansibilidad del código sea dificultoso; conflictos de comportamiento que radican en la determinación exacta del lugar en donde deben ser ubicados los Join-Point, este problema fue tratado por el Modelo Conceptual [3].

Otros inconvenientes de la AOP radican en el posible mal funcionamiento de la aplicación con referencia al framework original causado por la adición de nuevos aspectos en el mismo, además de agregar otros comportamientos diferentes a los esperados en el flujo de instrucciones del framework [4]. Conflictos multifuncionales, presentes cuando un módulo presenta diferentes funcionalidades y es difícil de conceptualizar.

La flexibilidad de los frameworks radica en que la estructura de la AOP permite interferir en las llamadas de los métodos tanto antes de su ejecución, durante el proceso o después del mismo, esta flexibilidad es proporcionada por los Join-Point (puntos de función: lugar donde los aspectos pueden ser colocados) puesto el Fb-AOP está diseñado enfocado hacia el control y manejo de estos Join-Point.

El proyecto permitirá recopilar las ventajas de los Fb-AOP en una metodología que suprimirá mediante la aplicación de adaptaciones de estas técnicas, las principales desventajas del enfoque a AOP.

Dentro de las mayores limitaciones del enfoque AOP tenemos que la selección de aspectos está basada en el código, es decir, depende de las características del lenguaje de programación: llamada de métodos, acceso a datos, etc. No hay un Fb-AOP, inclusive en la dimensión basada en código, que se haya acercado a apoyar a todos, ni siquiera la mayoría, de las construcciones en cualquier lenguaje de programación determinado [5].

La programación orientada a aspectos permite la modularidad de conceptos y bloque de instrucciones que no pueden ser estructurados con los paradigmas de la programación orientada a objetos o a módulos [6].

La tecnología actual en la AOP permite varias alternativas para la abstracción y separación de conceptos, las cuales involucran la definición de aspectos del lenguaje, weaving process y la modelación de conceptos como aspectos [7].

Los modelos y framework existentes se especializan en solucionar y corregir un inconveniente en particular: ubicación de Join-point, mantenimiento al expandir el código, pérdida de la compactación de aspectos, entre otros. No se han unificado los conceptos para encontrar la solución de todas las desventajas en un solo esquema. Además, una metodología permitirá establecer normas y procedimientos que permitirá identificar y ubicar elementos de los aspectos dentro del software.

Aunado a esto, es común el problema del mantenimiento del software frente a los cambios de las reglas de negocios, porque un si los Join-point y los cut-points se encuentran seleccionados de forma errada, se complicará aún más la adaptación del código.

La incorporación de los modelos como Join-point, weaving [8], abstracción de aspectos por técnicas de separación horizontal y vertical de conceptos [9], en una metodología permite la compactación de las propuestas que reducen la desventajas de la AOP sirviendo como base a modelos futuros.

Además de incorporar estos modelos, Se presente realizar un caso de estudio enfocado a determinar un mecanismo para dar seguimiento a las decisiones de negocio, permitiendo identificar la ubicación para los Join-point y los point-cut, para la ubicación correcta de los aspectos y los advice. En este caso se evaluará la metodología y la herramienta aplicada.

Uno de los principales objetivos de los Fb-AOP es separar las clases, métodos, procedimientos y funciones de las reglas del negocio, es decir, moldear un enfoque de programación de tal forma que el framework en sí, no este dependiendo de métodos sino que sea una representación del flujo de las reglas de negocio, facilitando el mantenimiento del mismo, ya sea en procedimientos de eliminación y adición de códigos, o en la adaptación del código para la modificación de una nueva regla.

En conjunto a la metodología propuesta, la incorporación de una herramienta servirá como apoyo para aplicar la metodología, además, esta herramienta proporcionará los elementos base del framework de forma automática una vez ingresado ciertos parámetros de entrada se generará los principales métodos y estructuras base del framework.

En fin, esta metodología, la herramienta conjunta de diseño y generación del Fb-AOP recopila los más valiosos aportes de diferentes modelos (explicados posteriormente) a la vez que proporciona un procedimiento de cómo realizar un framework para cualquier dominio específico

2. TRABAJOS RELACIONADOSExisten trabajos similares que tratan sobre la elaboración, medición y motivación de porqué utilizar esta estructura frente al enfoque de programación orientada a objetos (OOP).

AOP presenta grandes ventajas sobre la OOP [10], entre las cuales se pueden destacar que el primero es más flexible que el segundo siendo AOP considerada como una extensión de las características de OOP, permite la creación de ambientes más robustos y pueden adaptarse más fácilmente al seguimiento de las reglas del negocio de un determinado lugar o compañía, además de segmentar un problema en pequeños conceptos dependiendo a aplicaciones y usos en lugar de funciones y

objetivos, además de permitir las invocaciones a cualquier método con un Punto de Corte lo cual facilita la modificación del mismo.

Una variedad de trabajos similares sobre Fb-Frameworks como los siguientes:

2.1 Framework basado en Componentes y Aspectos [2]Tiene como propósito es de diseñar un modelo de framework que combine los elementos: componentes y aspectos en un mismo modelo.

Su arquitectura está dividida en tres capas: componentes-aspectos (los módulos funcionales son trabajados como componentes y los no funcionales como aspectos), interfaz e información (las interfaces son divididas en entrada y salida) y conexión (es la forma para interconectar a los aspectos y a los componentes). Los componentes se encuentran a través de la red, mientras que los aspectos están desarrollados en el servidor.

Como todo framework el área de aplicabilidad está limitada a los ambientes que soporten su estructura, cuya implementación, según el autor, resulta práctica para su implementación.

La metodología a desarrollar incorpora mecanismos de construcción dinámica en tiempo de ejecución de los aspectos y métodos a invocar y ejecutar. También se aplica el modelo conceptual para evitar los errores comunes de los AOP Frameworks al momento de la expansión del código con la implementación de una vista lógica y física de las relaciones.

2.2 Framework basado en Modelo ConceptualSu propósito consistía en formar un grupo de clases, métodos de clases, paquetes y métodos particulares (información física), metadatos para la expresión de conceptos y funciones lógicas del software (información lógica).

Su arquitectura utiliza un modelo basado en sintaxis XML para conectar la información física y la información lógica; resultando fácil aplicar ontología para lograr encontrar mediante instrucciones (querys) la información física mediante la referencia a la información lógica y viceversa

Tiene como aplicabilidad solucionar el problema de los débiles Puntos de Corte mediante la utilización de meta niveles, metaclases que están vinculadas con las clases y que son generadas por la reflexión de la clase la cual es un aspecto.

2.3 Dynamic Weaver Framework“The Dynamic Weaver Framework (DWF) es un framework orientado a aspectos independiente de lenguaje. El cuál separa propiedades del sistema como autenticación, seguridad, calendarización, entre otras funcionalidad” [11].

Propósito: Este framework incorpora el mecanismo dinámico, es decir, los aspectos pueden ser agregados y removidos en tiempo de ejecución sin la necesidad de reconfigurar, bajar el sistema o detener la actividad del mismo.

Su arquitectura consta de los siguientes componentes:

Aspectos Weaver: intercepta la invocación de cada método y redirige el control hacia el Repositorio de Aspectos. Además este componente se encarga de entrelazar los aspectos en tiempo de ejecución.

Repositorio de Aspectos: Evalúa las condiciones en que se ejecutan los Puntos de Cortes, evalúa todos los aspectos requeridos en la invocación de un método.

Tabla de Aspectos: Contiene todos los aspectos implementados cuya ubicación es determinada por una llave hash. Esta tabla se crea en tiempo de ejecución.

Aspectos: Conceptos y Abstracciones de reglas de negocio, cada uno de ellos pueden tener varios Puntos de Corte.

Puntos de Corte: Determina el lugar donde puede ocurrir una invocación e intervenir el Aspectos Weaver, puede contener muchos Advices.

Advices: Define el comportamiento de un objeto frente a un determinado evento o trigger.

Aplicabilidad: Permite aplicar la reusabilidad, puesto que el acoplamiento entre los aspectos es mínimo; existe un alto nivel de abstracción de conceptos a aspectos y en la codificación no existen restricciones, su arquitectura es independiente del lenguaje. Permite separar el código completamente de los aspectos.

2.4 THAOP [12]THAOP es un framework liviano orientado a aspectos que utiliza una dinámica tecnología de tejido.

Propósito: La creación de un nuevo framework basado en aspectos utilizando un componente TH_CORE, el cual se ejecuta en tiempo de ejecución como una serie de herramientas, incluyendo un compilador.

Arquitectura: THAOP consiste principalmente de Librerías AOP, Especificación de Lenguaje de Definición de Aspectos ADLS

Está basado en Join-Point, Puntos de Corte, Advice, Interceptores (similares a los advice). Estos modelos tiene funcionalidad es similar a AspectJ.

Aplicabilidad: Es un framework liviano lo que lo hace mucho más flexible que Fb-AOP más complejos, y facilita la forma de describir aspectos, está basado en XML.

2.5 TITANTITAN es un framework que permite el modelado de sistemas y la integración de aspectos. Está enfocado a tareas de modelado UML utilizando IPS (Interaction Patterns Specifications) para describir la conducta de los aspectos [4].

El procedimiento de trabajo de TITAN consiste en una vez determinado un aspecto dentro de la lógica del negocio de la aplicación, como por ejemplo la dispensación de bebidas embotelladas [4], al aspecto original del suministro debe agregarse varios requerimientos, por ejemplo cuando ya no existan bebidas; si este aspecto no se contemplo originalmente, mediante el enfoque AOP, es posible adicionar el nuevo aspecto aplicándolo sobre el mismo Join-point, de tal forma que en su

ejecución mediante un advice es posible intervenir en el procedimiento original.

La arquitectura de TITAN sigue un procedimiento basado en los siguientes elementos [4]:

1) Descripción del sistema (IPS) y especificaciones UML.

2) Instancias de Patrones.

3) Validación de especificaciones UML

4) Revisión y validación del modelo.

5) Simulación, verificación y prueba.

6) Verificación del comportamiento del sistema frente a nuevos aspectos.

Propósito: permite modelar a través de aspectos procedimientos y diseños UML.

2.6 Otros ProyectosOtros proyectos se han enfocado en la solución de proyectos de cross-cutting (cuando una sección del código se repite muchas veces a lo largo del framework, en especial en las ranuras) y dependencia y cohesión de aspectos.

Los dos problemas expresados anteriormente [13] radican en los siguientes conceptos: Al momento de generar la codificación y los métodos del software, en muchas ocasiones se utilizan las mismas funcionalidades, un ejemplo clásico es la autenticación (login), por lo cual al momento de prestar mantenimiento es necesario la modificación de cada uno de los conceptos; para el segundo punto, la cohesión y dependencia de aspectos radica en que es posible que varios aspectos estén involucrados entre sí, lo cual dificulta la arquitectura del framework, ya que como se presento al inicio del documento, el mismo debe ser independientes de las ranuras y métodos parametrizables, por lo que una ranura de un aspecto no debe estar estructuralmente dependiendo de otro que no esté completamente asociado al mismo. Las soluciones a los mismos fueron proporcionadas en el Trabajo [13] mediante la separación de conceptos bajo una estructura denominada Universal.

3. TECNOLOGÍAS UTILIZADASLas tecnologías involucradas para el desarrollo del proyecto que serán utilizadas son las siguientes:

3.1 AspectJ [13]Son librerías, extensiones de código del lenguaje Java que están orientadas a aspectos. Estos módulos captan la esencia de los Join-point, Cut-Point, código adicional (Advice), weaving process (Objetos creados en el point-cut al aplicar instanciación de clases).

AspectJ es uno de los modelos de AOP más populares en la actualidad, permite la ejecución de programas bien definidos en concepto de organización de programación y ejecución de aspectos [6].

AspectJ implementa una serie de complementos Java para trabajar los Join-Point, descripción de los Cut-Point, implementa el uso de advice, introduction y aspectos [6].

AspectJ trabaja de la siguiente forma:

Join-Point: El mecanismo de invocación de métodos, ejecución, constructores y manejadores de excepción orientados a aspectos forman parte del Join Point.

Cut-Point: Maneja operaciones booleanas para determinar y marcar los puntos para activar los Join Point, estas llaves se encuentran colocadas antes, durante y después de una llamada a un Join Point, de tal forma que son un punto importante en la flexibilidad y para controlar el flujo de un módulo o método.

Los Cross-Cutting: permiten agregar conceptos y módulos de seguridad en los mismos, puesto que estos son los puntos de acceso y de vínculo para la ejecución de las demás funciones del framework [14].

Advice: Son las instrucciones de programación que se ejecuta antes, durante y después la intervención de un Join-point [6]. Se ejecuta cuando un Join-point es alcanzado, de esta forma es capaz de agregar un comportamiento extra a la funcionalidad. Los advice se definen para cada Cut-Point.

Introduction: permite a los aspectos modificar la estructura estática de un programa. La introduction permite la adición de variables, clases, métodos, declaraciones y el control de excepciones dentro mientras se ejecuta un advice [6].

El principal objetivo de la AspectJ es proporcionar que mediante las librerías, los métodos e instrucciones orientadas a objetos y a aspectos, tanto como los bloques secuenciales de código trabajen acopladamente a la par sin problemas al momento de la ejecución del software.

El uso de AspectJ puede crear sistemas imprevisibles [4], efectos secundarios no deseados provocados por la incorporación de aspectos, weaving parcial, alteración semántica de los advice, conflictos con los estados invariantes del sistema al adicionar un nuevo aspecto.

La aplicabilidad de ApectJ permitirá la incorporación de la AOP dentro del Framework mediante la utilización de la herramienta que se pretende diseñar, permitiendo el uso de cada uno de los elementos de este paradigma de programación.

3.2 Procedimiento HashingEs un algoritmo de programación que permite determinar la ubicación de elementos en una tabla lógica o física, este procedimiento utiliza una llave hash para determinar la posición del elemento. En este caso, determina la ubicación de los aspectos dentro del directorio de aspecto, en tiempo de ejecución.

La llave Hash es determinada generalmente por una función matemática, es posible que se ejecute colisiones, las cuales son tratadas con un procedimiento determinado.

Aplicabilidad: Las técnicas de Hashing en conjunto con los Aspectos Repository, permiten la asignación dinámica de los aspectos en tiempo de ejecución dentro del framework.

3.3 IDE Java: Netbeans / EclipseSon IDE (Plataforma de Desarrollos) para el desarrollo de aplicaciones con el lenguaje de Java, sobre los cuales existen módulos y librerías de desarrollo como AspectJ, los cuales incluyen métodos que controlan las características y los eventos de los aspectos.

3.4 Modelo Joint-PointEste modelo se basa en la utilización de Join-Point, Puntos de Cortes y Advice en la AOP.

Los Join-Point deben estar localizados en una posición coherente del flujo del proceso y sus procedimientos deben ser entendibles por el programador.

Los Puntos de Cortes son los que determinan en qué lugar pueden ser invocados los Join-Point.

Los Advice, son procedimientos que se ejecutan antes, durante o después del Join-Point

Es posible notar que es muy importante para este modelo la localización correcta de los Puntos de Corte, ya que estos determinan los Join-Point que ejecutan el código referente a los conceptos y aspectos.

Este modelo es comúnmente utilizado para el diseño de las aplicaciones y frameworks basados en aspectos.

3.5 Weaving ModelModel-Driven base Aspect-Oriented Model Weaving (MAMW) es un nuevo modelo de concepción que transforma el modelo de la Programación orientada a aspectos. El MAMW es utilizado para la transformación en meta-modelos que implementará el nivel de abstracción.

Utiliza un modelo de vínculos para contener los Join Points y elementos de información de la sintaxis. MAMW mejora el nivel de abstracción y unifica el modelo de la Programación AOP.

El procedimiento de Tejido (Weaving Model) es un modelo que modifica el programa original con el fin de tejer los aspectos y asociarlos con los Join-point correspondientes [15]. Weaving no es más que el procedimiento de integración de advices a sus correspondientes Join-points del código principal. Los aspectos son conformados por los Join-points, point-cuts y los advices.

El procedimiento de weaving consta de las siguientes características: El proceso de Weaving teje varios segmentos de código antes de la compilación, no permite la modificación dinámica del núcleo, ni de los módulos si contiene aspectos. Entre sus desventajas está la reutilización de código para el conjunto de aspectos ya que están separados a los Join-point del programa principal [15].

3.6 Aspect Dynamic Weaving ModelEl método de Tejido dinámico presenta los siguientes elementos característicos [16]:

Modelado Base y de Aspectos: Se basa en un meta-modelo, no incluye los aspectos (separación de conceptos y reglas), mientras que la otra sección incluye todas las descripciones de los aspectos.

Capa de vínculos que permite la interacción entre las dos capas de modelado superiores.

La capa de Weaver ejecuta los advice de cada Join-point interceptando las instrucciones en la capa de vínculos.

Buffer de Solicitudes: Permite guardar en una lista de todos los aspectos enlazados, estos son vinculados con la capa de Modelo. Todas las solicitudes nuevas también son respaldadas de tal forma que se utilizan y se cargan dinámicamente.

Gestor de Estados: que maneja y controla los estados de las otras capas.

4. PROPUESTALa propuesta presentada consta de tres partes:

La metodología para el soporte en el desarrollo de frameworks basado en aspectos, una herramienta plug-in de Eclipse para la representación y tratamiento de aspectos, al igual que la generación de código y la aplicación en un caso de estudio que involucra la generación del framework para el seguimiento de las reglas de negocio a partir de la implementación de la metodología.

4.1 Elementos de la Propuesta: Metodología La metodología consta de los siguientes pasos, en los cuales se creará una serie de reglas y procedimientos de apoyo:

(Paso1) Identificación de clases: mediante los procedimientos usuales del paradigma orientado a objeto, se abstraen y separan conceptos en base a la identificación de objetos y propiedades en común.

(Paso2) Determinar funciones y métodos: procedimiento usual en el procedo de Ingeniería de Requerimientos que busca asignar y determinar a cada clase identificada que atributos, funciones y métodos contendrá.

(Paso3) Clasificación por funcionalidades: consiste en la agrupación de clases según los métodos definidos que juntos tratan un requerimiento funcional o no funcional del sistema. Este punto permitirá tener una visión superior de las clases, objetos y métodos analizados.

(Paso4) Identificar métodos y clases multifuncionales: del paso anterior es posible encontrar clases y métodos que no se puedan encapsular fácilmente bajo una funcionalidad específica debido a su carácter multifuncional. Mediante reglas de apoyo que se diseñaran, facilitará este procedimiento.

(Paso5) Determinar los posibles aspectos en cada bloque de funcionalidad: Identificados los elementos y métodos, se analizan bajo el paradigma de abstracción a aspectos y se eligen candidatos para convertirse en aspectos y cuáles de ellos tendrán comportamiento dinámico.

(Paso6) Seleccionar los Join-Point y las normas que rigen los Cut-Point: Para cada aspecto candidato se seleccionan cuáles serán sus Join-Point dependiendo al impacto, estableciendo normas para determinar la ubicación correcta de estos puntos con el fin de que los aspectos cumplan el propósito deseado.

(Paso7) Determinar los Advice y crear los cross-cutting: identificando los advice dentro del código del framework concatenando la funcionalidad transversal deseada.

(Paso8) Determinar los aspectos candidatos para ser tratados como aspectos dinámicos: este paso consiste en la creación de normas que permitan identificar qué aspectos pueden ser tratados como dinámicos dentro del framework, es decir, que tengan la versatilidad de poder modificarse, omitirse o agregarse en tiempo de ejecución.

(Paso9) Aplicar la capa superior de metadatos y metaclases: guía para la creación de una capa superior que permita la definición ontológica de los aspectos según su comportamiento para referencias futuras.

4.2 Diseño de la Herramienta de ApoyoRepresentación de Aspectos: Utilizando y adaptando modelos se representarán los diferentes elementos de los aspectos, basados en [17] como los presentados en la Tabla1:

Autor Elemento Representación

Zakaria, et al2003 Aspecto

M. Bash,A. Sanchez

2003Join-Point

Zakaria, et al,2002 Cut-Point

Steinmacher2003 Advice

Aldawud, et al 2003 Cross-Cutting

Tabla1. Representación de elementos de los aspectos.

Representación en código: Codificar cada elemento dentro de la herramienta en formato UML / XMI, para la representación en código de los elementos y su posterior manipulación en la migración de data.

Reglas de Validación para la interrelación de los elementos de los aspectos: Normas para relacionar los elementos de forma coherente y lógica no permitiendo asociaciones no válidas.

Establecer funcionalidades de la Herramienta: diseñar las funciones básicas como copiar, pegar, nuevo documento, nuevo diagrama, etc.

Determinar elementos funcionales indispensables: Son propiedades que determinarán que elementos serán considerados como hot-spots y frozen-spots del framework, lo cual impactará al momento de la migración del código.

Diseñar los módulos para migración y generación del código base del Framework: funcionalidad que permitirá trasladar el

diseño planteando y diagramado en la herramienta a código Java. Este proceso replicará las clases, aspectos, métodos y atributos como elementos base en el código de framework..

4.3 Caso de EstudioComo forma de evaluación de los pasos de la metodología y de su integración dentro de la herramienta de apoyo. Se desarrollará un caso de estudio en donde se desarrollará un Framework basado en aspectos para el seguimiento de las reglas y decisiones de negocio aplicando estos elementos y evaluando los resultados.

4.4 CaracterísticasAl aplicar la metodología, los frameworks desarrollados tendrán las siguientes características:

Segmentación de Aspectos: Los aspectos son definidos como propiedades de cortes de componentes funcionales, es decir, las áreas de los puntos calientes son analizadas de forma independiente según sus funcionalidades. Después la identificación, todos los aspectos son reunidos e indexados en el contenedor de aspectos. Este proceso se logra en el Paso3.

Separación de Cross-Cutting: El Framework incluye la separación de componentes funcionales de los componentes no funcionales, lo cual mejora la reutilización del código de aspectos, puesto que esta clasificación permite organizar las clases y aspectos dependiendo de las funcionalidades siendo posible establecer los componentes de una determina función y encapsularlas en aspectos, de esta manera cuando se necesite utilizar sólo se hace referencia a estos componentes. La separación por cross-cutting se aplica definitivamente en el Paso7.

Dinamismo: en tiempo de ejecución el Framework permite la selección dinámica de los aspectos que se ejecutarán. Esto es posible debido al contenedor de aspectos, que permite listar estos elementos; esta indexación se cargará también en tiempo de ejecución.

El procedimiento que apoya este beneficio es el Paso8; a su vez trata un problema de la Orientación a Aspectos, que es la reducción de la complejidad al momento de determinar qué aspectos serán dinámicos y como se manejarán los mismos en tiempo de ejecución.

Cohesión: es un Framework AOP, utilizando conceptos clásicos de OOP y COP como bases. Aplicado la mezcla de los pasos de la metodología.

Conceptualización: se conceptualizan los métodos y funciones evitando inconvenientes al momento de la expansión del código, aplicando clases superiores: meta-data y meta-clases para evitar la redundancia cuando el código empieza a expandirse durante procesos de mantenimiento por ejemplo. A su vez, la conceptualización minimiza el inconveniente de expansión mediante el uso de metadatos y metaclases, pues le dan significado semántico a los aspectos y métodos, aplicado en el Paso9.

Intercepción de Invocaciones: es el conjunto de advice de aspectos que se ejecutaran antes, durante o

después de una determinada intervención. Esto es un propiedad natural de la AOP, está aplicado en el Paso7.

Basado en Join-Point Model: basado en este modelo, el Framework permite reducir el conflicto de los puntos de fusión débiles. La metodología disminuye la dificultad innata que radica en la ubicación de los Join-point y Cut-point mediante las reglas del Paso6.

Abstracción de Elementos Multifuncionales: Mediante las reglas del Paso4 y Paso5 se determinan y clasifican los aspectos cuya dificultad de abstracción es elevada debido a que su función se refleja en varios bloques y clasificaciones, a su vez se trata el problema de multifuncionalidad de la AOP.

4.5 ArquitecturaLa herramienta de apoyo para la generación del framework que utiliza la metodología presenta la arquitectura de la Figura2. El usuario implementa la herramienta y diagrama los elementos del modelo que desea diseñar, en conjunto con la determinación de los atributos y métodos de las clases y elementos de los aspectos; de tal forma que se ve gráficamente en una interfaz de usuario y de forma paralela se elabora la codificación

correspondiente.

Una vez terminado se generará en código Java los elementos identificados en los diagramas que serán la estructura base del framework.

Además, se genera una capa semántica superior de metadatos y metaclases que identificará las funcionalidad de los métodos, clases y elementos; estos valores se extraerán de la información colocada en los respectivos elementos y se creará de forma paralela al proceso anterior, con independencia al usuario.

4.6 ComponentesLos framework tendrán los siguientes elementos:

Núcleo: son las instrucciones, clases, funciones y métodos del Framework que no podrán ser modificables (kernel). Estos elementos deben ser notificados en la herramienta como Indispensables para que sean encapsulados dentro del núcleo en la migración del software.

Repositorio de Aspectos: es el lugar donde se almacena la representación de los conceptos y funcionalidades del Framework (aspectos); los mismos deben seleccionados y

ubicados en un cross-cutting de impacto, de tal forma que mantenga la separación de las funciones.

Controlador Dinámico de Aspectos: mantiene todos los aspectos organizados e indexados. El uso de un contenedor paralelo permite la organización en tiempo de ejecución según las prioridades y las invocaciones de cada aspecto o intercepción (llamadas antes, durante o después del aspecto).

Ranunas Modificables: son los bloques de abstracciones que fueron catalogados como no requerido dentro de la generación del software. Y que podrán ser modificados o hasta prescindir de ellos.

Meta Nivel: nivel superior que contiene el significado semántico de las clases, componentes y aspectos; de tal forma de poder identificar su funcionalidad rápidamente.

4.7 Herramientas y Metodología de la InvestigaciónSe utilizará el IDE de Eclipse para el desarrollo de la investigación, utilizando como soporte y librerías de apoyo (middleware) AspectJ que incorpora la segmentación de los Cut-Point, Join-Point, Advice a través de extensiones de código del

lenguaje Java.

Para el desarrollo de la metodología se utilizarán esquemas de trabajos relacionados donde se implementan el paradigma AOP analizando las variantes de aplicabilidad, además de visualizar el comportamiento de los elementos de los aspectos, a través de ellas se crearan las reglas y normas que denotarán la metodología. En la herramienta se adaptaran los diseños de representación de aspectos, se establecerán los elementos de cada uno de ellos relevante en el proceso de generación del código y la migración se llevará a cabo a través de transformaciones de XML y XMI a código Java.

5. CONCLUSIONESEl propósito de la metodología es la de servir de apoyo para el diseño de Fb- AOP en conjunto con la herramienta que es la de diseñar y representar los aspectos para la migración de código.

Los beneficios de esta investigación radican en proporcionar una metodología de soporte para el diseño de frameworks basados en programación orientada a aspectos, la cual minimiza los inconvenientes del paradigma de la programación orientada a aspectos, a la vez de proporcionar una nueva visión para el diseño, análisis y desarrollo de Fb –AOP.

Se tendrá con una herramienta en la cual es posible aplicar la metodología creada, esta herramienta proporcionará los elementos base del framework d3e forma automática una vez ingresado ciertos parámetros de entrada. La herramienta servirá como soporte para la representación y el tratamiento de los aspectos.

6. REFERENCIAS[1] M. E. Markiewicz and C. J. P. d. Lucena, 2001, "El

Desarrollo del Framework Orientado al Objeto." Software Engineer Summer.

[2] Y. Z. a. J.Zhang, 2005, "Interactive Framework and its Supported Environment between Component and Aspect,”.

[3] H. Hu, C. He, and Z. Li, 2009, "An AOP Framework and Its Implementation Based on Conceptual Model," ISECS International Colloquium on Computing, Communication, Control and Management.

[4] M. Perez-Toledano and C. Canal, 2007, "TITAN: a Framework for Aspect Oriented System Evolution," in International Conference on Software Engineering Advances, Cap Esterel.

[5] A. Nusayr, 2008, "AOP as Formal Framewok for Runtime Monitoring," in FSE-16 Doctoral Symposium, Atlanta, Georigia, USA.

[6] A. Kumar, R. Kumar, and P. S. Grover, 2008, "Toward a Unified Framework for Cohesion Measurement in Aspect-Oriented Systems," in 19th Australian Conference on Software Enginnering.

[7] M. Díaz, S. Romero, B. Rubio, E. Soler, and J. M. Troya, 2005, "An Aspect Oriented Framework for Scientific Component Development," in 13th Euromicro Conference on Parallel, Distributed and Network-Based Processing.

[8] X. Wang, S. Liu, and S. Li, 2007, "A Model Driven based Aspect Oriented Model Weaving Framework for

Distributed System," in 11th International Conference on Computer Supported Cooperative Work in Design.

[9] A. Solberg, D. Simmonds, R. Reddy, S. Ghosh, and R. France, 2005, "Using Aspect Oriented Techniques to Support Separation of Concerns in Model Driven Development," in 29th Annual International Computer Software and Applications Conference.

[10] Z. Hua, Z.-C. Wang, J. Hua, G.-X. Yang, and Y.-W. Liu, 2005, "The Framework of Agent-Oriented Programming," IEEE.

[11] D. P. Fletcher, F. Akkawi, R. L. Alena, and D. P. Duncavage, 2004, "From Research to Operations: Integrating Components with an Aspect-Oriented Framework and Ontology," IEEE Aerospace Conference Proceedings.

[12] H. J. Hwang and J. T. Choi, 2007, "Design of an Aspect-Based Framework to Improve the Dynamic Management of MFID middleware,".

[13] L. Zhou, Q. Wang, Y. Zhang, and C. Xing, 2008, "Solving AOP Problems with Universal Framework," International Symposium on Information Science and Engineering.

[14] V. Shah and F. Hill, 2003, "An Aspect-Oriented Security Framework," in DARPA Information Survivability Conference and Exposition (DISCEX'03).

[15] D. Majumdar and S. Bhattacharya, 2009, "A Design Model Based Exceution Framework for Aspect Oriented Systems," in International Conference on Methods and Models in Computer Science.

[16] G. Jun-Wei, T. Rong, and Y.-Q. Fang, 2008, "A MDA based Aspect-Oriented Model Dynamic Weaving Framework," International Conference on Computer Science and Software Engineering.

[17] F. Losavio, A. Matteo and P. Morantes, 2009, "UML Extensions for Aspect Oriented Software Development," Journal of Object Technology Vol. 8, No 5.