Arquitectura de Acceso a Datos en Sistemas Orientados a Objetos: Clasificacin y Descripcin de Mecanismos de Persistencia

Pablo Miranda Daniel Calegari Joaqun Prudenza Jorge Corral Andrs Segurola

Instituto de Computacin, Facultad de Ingeniera, Universidad de la Repblica Julio Herrera y Reissig 565, 5to piso 11300 Montevideo, Uruguay +598 (2) 7114244

{dcalegar,corral}@fing.edu.uy

ABSTRACT
Existen numerosas alternativas a la hora de seleccionar un mecanismo de acceso a datos persistentes y su posterior manipulacin. La eleccin de estos mecanismos depende del contexto en el cual quieran ser aplicados, impactando de diferentes formas en la arquitectura del sistema. A fin de elegir un mecanismo apropiado es necesario contar con una visin general, objetiva y bien estructurada de las alternativas disponibles. Una forma de lograr esto es disponer de una clasificacin de los mecanismos de persistencia existentes. Si bien existen trabajos en este sentido, las clasificaciones disponibles no son completas, no describen apropiadamente las categoras que definen, o no estn orientadas a que un desarrollador las utilice como gua para la seleccin. En este sentido, este trabajo propone una clasificacin de los mecanismos de persistencia existentes para sistemas orientados a objetos, pretendiendo subsanar las carencias identificadas anteriormente. Dicha clasificacin est compuesta por dos vistas: la primera presenta una descripcin detallada de cada uno de los mecanismos mientras que la segunda presenta un anlisis comparativo entre ellos. De esta manera, el programador no solo evaluar la adecuacin de cierto mecanismo en base a las caractersticas propias del mismo, sino adems podr comparar, en base a ciertos criterios definidos, su utilidad con respecto al resto de ellos.

1. INTRODUCCIN
El acceso a la informacin constituy, en sus orgenes, una tarea de muy bajo nivel realizada sobre cintas magnticas o tarjetas perforadas por grandes sistemas monolticos. Conforme los sistemas se volvan ms complejos mayores niveles de abstraccin fueron necesarios. Esto llev a plantear una clara separacin arquitectural entre el acceso a los datos y el procesamiento de los mismos. Actualmente, la realidad presenta sistemas distribuidos, interoperables, con fuentes de datos heterogneas y con capacidades de almacenamiento masivo [1]. En este contexto, el mecanismo utilizado para acceder a los datos es de vital importancia, no solo por su impacto en el desempeo final del sistema sino tambin a los efectos de asegurar atributos deseables de calidad como la mantenibilidad, reusabilidad, escalabilidad, etc. [2] Existen numerosas alternativas a la hora de seleccionar un mecanismo para acceder a los datos y posteriormente manipularlos. Algunas de ellas se describen en [3, 4, 5, 6]. Estas alternativas se diferencian en los enfoques utilizados, los contextos a los que aplican, su grado de usabilidad, portabilidad, desempeo, impacto a nivel arquitectnico, entre otros. En un principio, la amplia gama de posibilidades resulta abrumadora a la hora de seleccionar un mecanismo de persistencia concreto acorde a las necesidades. Quien asuma dicha tarea deber contar con la informacin necesaria para justificar su eleccin. Esta eleccin no debe estar influenciada por cuestiones de marketing o sesgos personales, sino por una adecuada evaluacin de los requerimientos. Por tal motivo, es de suma importancia contar con una visin general, objetiva y bien estructurada del problema. Con el objetivo de contribuir con esta visin objetiva, este trabajo propone una clasificacin de los mecanismos de persistencia existentes para sistemas orientados a objetos. Esta clasificacin presenta una descripcin de cada uno de los mecanismos con sus principales caractersticas, los contextos factibles de aplicacin, las ventajas y desventajas de su

Copyright 2006 Tata Consultancy Services Ltd.

Page 1 of 9

aplicacin, las herramientas representativas de cada mecanismo, etc. Adems, presenta un anlisis comparativo de los mecanismos, basado en un conjunto de criterios de comparacin, lo que permite obtener un mejor entendimiento global de las alternativas disponibles. Cabe notar que si bien existen trabajos en este sentido [7, 8, 9, 10], las clasificaciones realizadas no son completas, no describen apropiadamente las categoras que definen, o no estn orientadas a que un desarrollador las utilice como gua para la seleccin del mecanismo apropiado. La clasificacin propuesta pretende subsanar dichas carencias. El artculo est organizado de la siguiente manera. En la seccin 2 se introduce el problema en cuestin y se analizan los trabajos relacionados notando las carencias de los mismos. En la seccin 3 se presenta la clasificacin realizada as como una comparacin con las clasificaciones ya existentes. En la seccin 4 se presenta la descripcin de un par de mecanismos de persistencia a los efectos de ejemplificar la propuesta. Finalmente, en la seccin 5 se presentan las conclusiones mientras que en la seccin 6 se delinea el trabajo futuro.

puede ver en la Figura 1. La misma est orientada (por la naturaleza de los participantes del evento) a su utilizacin en forma prctica.

2. ARQUITECTURA DE ACCESO A DATOS

Podemos definir arbitrariamente a la arquitectura de acceso a datos como el conjunto de decisiones significativas sobre la organizacin de la persistencia y manipulacin de los datos persistentes. Esto incluye desde el mecanismo de persistencia utilizado hasta los propios datos que son persistidos. De la misma forma, podemos definir mecanismo de persistencia, en el contexto del desarrollo de un sistema orientado a objetos, como una tcnica que permite resolver la persistencia de objetos. Esto implica extender el tiempo de vida de estos mas all del tiempo de vida del proceso que los cre. Optar por uno u otro mecanismo implica evaluar las caractersticas de cada uno de ellos, correlacionndolos con las necesidades del sistema a construir. Por tal motivo, es de suma importancia contar con una visin general, objetiva y bien estructurada del problema. En este sentido, existen algunas clasificaciones pero ninguna de ellas ofrece una vista clara y completa del problema que asista al desarrollador a la hora de seleccionar un mecanismo (o un conjunto de de los mismos) basado en el contexto en que este se encuentre. A continuacin se presentan estas clasificaciones.

Figura 1. Esquema grfico de la Clasificacin I Cabe notar que el origen informal del evento hizo que no exista una definicin concreta y concisa de las categoras consideradas. Esto claramente imposibilita comprender el alcance de cada una de las categoras presentadas. De acuerdo con ello la utilidad de la clasificacin propuesta se ve seriamente restringida. Asimismo considerar un nico nivel en la jerarqua no permite exhibir un grado de granularidad adecuado ni agrupar categoras similares. Otras carencias detectadas se ven reflejadas en hacer hincapi en productos particulares y no considerar tcnicas menos establecidas como por ejemplo Programacin Orientada a Aspectos.

2.2 Clasificacin II: Survey of Persistence Approaches [8]

Se trata de una tesis de maestra que realiza una comparacin entre diferentes mecanismos de persistencia como un paso hacia la definicin de un mecanismo de persistencia ideal y transparente. Para ello se describen los mecanismos ms relevantes existentes (ver Figura 2) y se definen criterios de comparacin a ser aplicados a productos particulares. Los criterios ms importantes considerados son los siguientes: ortogonalidad de tipo, independencia de persistencia, alcance, integridad, soporte de transacciones, reusabilidad, lenguaje de consulta y performance. A continuacin se resume la definicin de los criterios antes mencionados. La ortogonalidad de tipo establece que todos los objetos tienen los mismos derechos de ser persistidos independientemente de su tipo. La independencia de persistencia se refiere al hecho de que no sea necesario realizar cambios en el cdigo fuente para lograr que un objeto sea persistente. Todo mecanismo requiere de una estrategia para indicar que objetos han de ser persistidos. Usualmente se cuenta con un objeto denominado raz de persistencia, tal que todos aquellos objetos alcanzables desde l son persistentes. Dicho enfoque es denominado persistencia por alcance. El propsito del chequeo de integridad es proveer medios que garanticen la

2.1 Clasificacin I: Software Practice Advancement 2006 [7]

En el contexto de un workshop realizado en la conferencia Software Practice Advancement 2006 (SPA 2006) se elabor una clasificacin de mecanismos de persistencia. Dicha clasificacin se llevo a cabo con el objetivo de ser parte de una gua a ser utilizada por los desarrolladores al momento de elegir un mecanismo de persistencia. La misma es el resultado de los conocimientos y experiencia de los participantes de dicho evento que incluy arquitectos, diseadores y desarrolladores. De acuerdo con ello se supone que la clasificacin obtenida es representante de las tcnicas mas utilizadas en la industria. Se trata de una clasificacin de un solo nivel donde se enumeran agrupaciones generales y luego se presentan productos concretos que caracterizan cada grupo, tal como se

Copyright 2006 Tata Consultancy Services Ltd.

Page 2 of 9

consistencia de los datos. El soporte transaccional provisto por el mecanismo se refiere particularmente a la cobertura de las propiedades ACID 1. El principio de reusabilidad es definido como la habilidad de ejecutar una aplicacin en un contexto persistente o convencional sin la necesidad de modificar el cdigo fuente. El criterio de lenguaje de consulta se refiere al mecanismo de recuperacin de objetos provisto. Las estrategias utilizadas por los diferentes mecanismos para mejorar su performance es otro de los criterios considerados.

Relacional, generadores de cdigo, frameworks, etc. Ntese que estas ltimas opciones no son consideradas en el libro.

Figura 3. Esquema grfico de la Clasificacin III

2.4 Clasificacin IV: Approaches to Adding Persistence to Java [10]

Figura 2. Esquema grfico de la Clasificacin II Con respecto a esta clasificacin se puede notar que la misma no est orientada al desarrollador ya que considera exclusivamente categoras guiadas por la tcnica de bajo nivel utilizada (bases de datos, serializacin, etc.). Se trata de una categorizacin de un solo nivel que no es completa al no incluir alguno de los mecanismos relevantes (Mapeadores Objeto-XML, ObjetoRelacional, etc.). Otra crtica a destacar es que la comparacin se realiza entre productos y no categoras, por lo tanto los resultados estn sujetos a la utilizacin del producto utilizado en la comparacin. Este artculo presenta una clasificacin basada en una serie de preguntas centradas en la plataforma Java [11], cuyas respuestas determinan la categora del mecanismo. Dichas preguntas se concentran en tres aspectos: ortogonalidad, transparencia e implementacin. Por ortogonalidad se entiende la propiedad de un mecanismo de permitir que cualquier instancia de una clase sea potencialmente persistente sin que los programadores estn obligados a indicarlo explcitamente. Esta definicin es de referencia ya que rara vez es deseable o posible en su forma ms pura. En este sentido, las preguntas apuntan a conocer el nivel de ortogonalidad del mecanismo, expuestas a continuacin: Se trata de persistencia por alcance (a partir de un objeto raz), o se utiliza algn otro mtodo para designar cuales objetos deben ser persistidos? El cdigo (de objeto) es comportamiento como datos)? persistente (tanto

2.3 Clasificacin III: Agile Database Techniques [9]

En este libro se describen los mecanismos de persistencia como alternativa al uso de una base de datos relacional (ver Figura 3), mecanismo que considera el ms relevante y sobre el cual se basa el contenido del libro. Se incluye, como parte de la definicin de las categoras, contextos de aplicacin as como tambin ventajas y desventajas de las mismas. La categorizacin se focaliza en el destino de los datos. Ms all de que es un criterio vlido para la clasificacin se trata de una particin demasiado general a la hora de utilizarla como gua en la eleccin de un mecanismo apropiado. Como un ejemplo de lo anterior si se considera la categora que tiene a una base de datos Relacional como destino de los datos, existen mltiples opciones para el desarrollador que estaran dentro de esta categora, como por ejemplo: mapeadores Objeto1

El estado de ejecucin del programa es persistente? Cul es el modelo de transacciones?

Por transparencia nos referimos a que un programa que potencialmente requiere la persistencia de objetos luce esencialmente igual a uno que no tiene este requerimiento. Por ms que la transparencia suele considerarse solo en trminos de cdigo fuente, al tratarse Java no solo de un lenguaje sino tambin de una maquina virtual estandarizada, otras consideraciones pueden incluirse. Las preguntas planteadas son: Es necesario modificar el lenguaje para persistir? Es necesario modificar el byte-code generado?

Atomicity, Consistency, Isolation y Durability

Por implementacin se refiere a si es necesario cambiar la propia implementacin de la plataforma para persistir, sin que el

Copyright 2006 Tata Consultancy Services Ltd.

Page 3 of 9

programador realmente conozca que es as. Las preguntas planteadas son: Se cambia el compilador de Java? Se cambia el intrprete de Java y el ambiente de ejecucin?

Lo presentado se trata de un enfoque diferente a los vistos anteriormente, donde cada conjunto de respuestas determina una categora. Debido a que no se define cuales combinaciones de respuestas son vlidas (si existe o no un mecanismo para ellas) no es una clasificacin clara. Una desventaja fundamental a destacar es que la clasificacin se restringe a la plataforma Java. Adems, se puede agregar que la misma se concentra nicamente en aspectos de ortogonalidad, transparencia e implementacin sin considerar otras caractersticas relevantes, como por ejemplo las consideradas en 2.2.

desarrollador. Esto implica que cada categora definida representa una opcin disponible para el desarrollador a la hora de persistir la informacin de su sistema. Ms all de que las categoras estn claramente diferenciadas, en la prctica un producto particular puede pertenecer a ms de una de ellas. Esto se entiende en el hecho de que el producto particular usa una o ms tcnicas concretas. Cabe destacar que se consideran sistemas cuya lgica es orientada a objetos. La Figura 4 muestra la clasificacin taxonmica en cuestin. Como se puede observar se trata de una categorizacin en dos niveles que incluye tanto tcnicas establecidas como ser acceso directo a bases de datos relacionales (una subcategora de acceso directo a bases de datos) como tambin tcnicas mas recientes y de creciente popularidad como ser: generadores de cdigo y mapeadores Objeto/Relacional. La existencia de un segundo nivel permite separar tcnicas que por mas que compartan una misma tcnica base (por ejemplo en el caso de los mapeadores), tienen caractersticas diferenciadas (como lo es en el caso de los mapeadores Objeto/Relacional y Objeto/XML). Concretamente, la clasificacin propuesta define categoras que contemplan: Mapeadores (mapeo de objetos a otro modelo de datos), Acceso Directo a Base de Datos (interaccin directa con una base de datos), Lenguajes Orientados a Objetos (soporte del lenguaje para la persistencia de objetos), Orientacin a Aspectos (implementacin de persistencia a travs de aspectos), Generadores de Cdigo (generacin del cdigo para persistencia mediante herramientas) y Prevalencia (persistencia mediante snapshots y fuerte uso de memoria principal). La clasificacin no est compuesta solamente por la taxonoma anterior, sino que incluye una descripcin detallada de cada uno de los mecanismos presentes as como un anlisis comparativo de estos.

2.5 Crticas a las Clasificaciones Anteriores

Las clasificaciones existentes presentan distintas carencias que las hacen inadecuadas para ser utilizadas por un desarrollador con el objetivo de entender la situacin actual en cuanto a mecanismos de persistencia. De las clasificaciones anteriores podemos destacar debilidades en los siguientes aspectos: Completitud. La falta de completitud de las mismas en cuanto a los mecanismos que stas consideran. Enfoque. La mayora de ellas no estn orientadas a las opciones que un desarrollador debe considerar. Definicin. En algunos casos las categoras o bien no se definen, o se hace de forma poco clara e incompleta. Granularidad. Las clasificaciones existentes consideran un solo nivel de categorizacin por lo que no presentan la granularidad necesaria para tener un panorama descriptivo de la realidad. Es por ello que una categora puede incluir mecanismos que deberan ser considerados de forma separada. Comparacin. Las comparaciones presentadas en [8] se basan en productos particulares. De acuerdo con ello no reflejan las caractersticas de los mecanismos en los cuales estos se basan.

3.1 Descripcin de los Mecanismos

La motivacin para describir cada mecanismo de persistencia es la necesidad de presentar un esquema de solucin (en un alto nivel de abstraccin) a un problema surgido repetidamente, documentando la experiencia existente en el abordaje de dicho problema. Por dicho motivo, se opt por definir una estructura comn para describir cada mecanismo de persistencia. Dicha estructura tiene elementos en comn con las utilizadas para describir patrones de diseo [11]. Para la exposicin de los distintos mecanismos de persistencia se har uso de la siguiente estructura: Nombre del Mecanismo. Nombre propuesto para la identificacin del mecanismo en cuestin. Intencin. Breve descripcin del objetivo perseguido por el mecanismo. Motivacin. Explica la necesidad que dio a lugar al surgimiento de dicho mecanismo.

3. PROPUESTA DE CLASIFICACIN DE MECANISMOS DE PERSISTENCIA

A los efectos de solucionar los problemas que contienen las clasificaciones existentes se desarroll una nueva clasificacin. Para ello, se tuvo en cuenta, adems de las clasificaciones antes mencionadas, todas las opciones actuales al momento de solucionar la persistencia de un sistema. Para lograr esto se decidi incluir nuevas categoras no consideradas y tomar un criterio de definicin de categoras basado en la perspectiva del

Copyright 2006 Tata Consultancy Services Ltd.

Page 4 of 9

Figura 4. Clasificacin taxonmica de mecanismos de persistencia para sistemas orientados a objetos Descripcin. Presentacin de aspectos generales de su funcionamiento, principales caractersticas y definicin de conceptos involucrados. Esquema Grafico. Representacin grafica de los componentes y/o conceptos bsicos involucrados de manera de permitir una rpida visualizacin del mismo. Contextos de Aplicacin. Descripcin de los ambientes en los cuales es recomendable la aplicacin del mecanismo. Se tienen en cuenta, entre otras cosas, plataformas, dominio de aplicacin y requerimientos de performance. Ventajas y desventajas. Enumeracin de los pros y contras de la aplicacin del mecanismo. Mecanismo Base. En caso de aplicar, se refiere al mecanismo general que se especializa. Por tratarse de una clasificacin taxonmica, el mecanismo especializado cumple con la descripcin presentada en el mecanismo base.

Mecanismos Relacionados. De existir mecanismos relacionados, son enumerados en esta seccin, explicando su relacin. Herramientas. Se sugieren algunas herramientas representativas del mecanismo, tanto acadmicas como comerciales.

Ntese que la estructura anterior aplica nicamente a los mecanismos concretos (lase hojas del rbol de categoras). En cuanto a lo que se denomina mecanismos base (aquellas categoras hijas directas de la raz Mecanismos de Persistencias) se realiza simplemente una descripcin general de lo que esta categora implica.

3.2 Anlisis Comparativo

La descripcin individual de cada mecanismo puede verse favorecida incluyendo una segunda vista de la clasificacin que involucre un anlisis comparativo de los mecanismos. Esto permite obtener un mejor entendimiento global de las

Copyright 2006 Tata Consultancy Services Ltd.

Page 5 of 9

alternativas disponibles, y en consecuencia, beneficia al programador en su eleccin del mecanismo a utilizar. Con ese objetivo, se deben considerar criterios que permitan contrastar de manera organizada las diferencias y similitudes entres las distintas alternativas. El conjunto de criterios definido est basado fuertemente en los criterios propuestos en [8] (correspondientes a la Clasificacin II de la seccin 2.2). Concretamente se consideran de inters los siguientes criterios: ortogonalidad de tipo, independencia de persistencia, alcance, integridad, soporte de transacciones, reusabilidad, lenguaje de consulta y performance. Este conjunto es extendido agregando nuevos criterios como ser: porte de la aplicacin, impacto de la evolucin de la base de datos [2], productos existentes, antre otros. El conjunto de criterios an no ha sido definido en su totalidad con lo que tampoco ha sido realizado en extensin el anlisis comparativo. Sin embargo, est programado como trabajo futuro que permitir, por un lado, completar la segunda vista de la clasificacin, y por otro, mejorar la descripcin de cada mecanismo individualmente.

El uso de generadores de cdigo en el rea de desarrollo de software ha tenido un considerable incremento en los ltimos aos. Un generador de cdigo es una herramienta que basndose en meta-data de un proyecto es capaz de generar cdigo correcto, robusto y que aplica los patrones de diseo pertinentes. Este cdigo generado se encarga de resolver parte de la problemtica del sistema. Los generadores de cdigo (cuando bien utilizados), pueden lograr que la evolucin del proyecto sea muy gil. La afirmacin anterior se basa en que un cambio en la implementacin detrs del cdigo generado se reduce a configurar el generador de forma diferente (por ejemplo utilizando una plantilla diferente) y luego proceder a generar el cdigo nuevamente. El incremento en la productividad que se puede lograr utilizando generadores es considerable, llegando a ser de varios ordenes de magnitud. A diferencia de pequeas herramientas de generacin de cdigo incluidas en los IDEs populares, los generadores de cdigo que consideramos en este documento son capaces de generar capas del sistema en su totalidad y en algunos casos aplicaciones enteras. Una aplicacin particular de los generadores de cdigo es la generacin de capas de acceso a datos o de cdigo necesario para lograr la persistencia a travs de frameworks u otra tcnica. Particularmente se puede hablar de la generacin de una capa de acceso a datos que responde al patrn DAO (Data Access Object) que se genera tomando como metadata la definicin del esquema de base de datos. Otra aplicacin comn es la generacin del esquema de base de datos a partir de la definicin de las clases del negocio y metadata de mapeo. Para resumir, mas all de que se utilice una herramienta off-theshelf o propia, la idea es desviar la parte pesada y predecible del desarrollo a un generador de cdigo.

4. EJEMPLOS DE MECANISMOS DE PERSISTENCIA

La estructura antes mencionada fue utilizada para describir todos los mecanismos de persistencia presentados en la clasificacin. A los efectos de ejemplificar la descripcin de los mecanismos de persistencia se presenta a continuacin la descripcin de los mecanismos denominados Generadores de Cdigo y Programacin Orientada a Aspectos.

4.1 Generadores de Cdigo

Intencin Concentrarse en la especificacin abstracta y de alto nivel de un sistema delegando su construccin a una herramienta (semi) automtica.

Esquema Grafico

Motivacin El surgimiento de numerosos frameworks que solucionan parte de la problemtica del desarrollo de una aplicacin empresarial y el creciente uso de patrones de diseo ha tenido como consecuencia el desarrollo de aplicaciones empresariales ms robustas en menos tiempo. Sin embargo el programador aun se ve obligado a realizar tareas repetitivas vindose afectada la productividad de estos. Un ejemplo de lo anterior se puede encontrar en la plataforma Java Enterprise Edition [11], donde gran parte del tiempo del programador se pierde en producir el cdigo involucrado en la definicin de EJBs. La idea de que el programador debe concentrarse en el cdigo que representa la lgica de negocio es la principal motivacin para la aparicin de los generadores de cdigo.

Contextos de Aplicacin Este tipo de tcnica es especialmente aplicable en situaciones donde la solucin buscada resulta de la repeticin de numerosas y similares iteraciones. Un ejemplo de estos escenarios es la generacin de una capa de acceso a una base de datos, donde la meta-data se encuentra en el esquema de la base de datos. El patrn utilizado para acceder a las diferentes tablas es el mismo, al tratarse de una tarea repetitiva, un generador de cdigo es la

Descripcin

Copyright 2006 Tata Consultancy Services Ltd.

Page 6 of 9

herramienta idnea. Bajo estas condiciones escribir el generador de cdigo (o configurar uno) que genere la capa, probablemente sea menos costoso que codificar la capa entera. Sin mencionar que al momento de tener que actualizar el cdigo debido a cambios en el esquema, si se cuenta con un generador, solo es necesario ejecutarlo nuevamente. Ventajas En el caso de que los requerimientos sobre el cdigo generado cambien, solo es necesario modificar el generador (o configurarlo apropiadamente) para luego ejecutarlo y obtener el cdigo fuente que cumpla con los nuevos requerimientos. El cdigo generado suele ser estable y libre de errores. Esto debido a que la depuracin del cdigo generado se hizo en una etapa anterior al proyecto, o sea en el propio desarrollo del generador. La generacin es extremadamente rpida, permitiendo que el cdigo generado este al da con los cambios en la meta-data del proyecto. La generacin es personalizable. En el caso de que se disponga del cdigo fuente del generador o que el mismo soporte plantillas de generacin, el cdigo generado puede ser altamente personalizado. Los desarrolladores pueden concentrarse en las reas del sistema que involucran la lgica de negocio y que requieren de razonamiento intensivo, esto tiene un impacto positivo en la moral y por lo tanto en la productividad. Grandes volmenes de cdigo escrito a mano tiende a presentar inconsistencias ya que los programadores sueles encontrar mejores formas de hacer lo mismo a medida que el proyecto avanza. La generacin de cdigo crea una base de cdigo consistente instantneamente, lo que incrementa la calidad del producto. Aun en el mejor sistema escrito a mano, el cambiar el nombre de una entidad (por ejemplo el nombre de una tabla) requiere cambios a lo largo del sistema (capa de objetos, documentacin y casos de prueba). Un enfoque de generacin de cdigo permite que este nombre se cambie en un solo lugar y que luego se regenere las partes involucradas para que utilicen el nuevo nombre.

Mecanismos Relacionados Los generadores de cdigo estn ntimamente relacionados con: bases de datos relacionales, mapeadores objeto-relacional y mapeadores objeto-XML. Esto se debe a que en general estos generadores tienen como salida de su proceso de generacin: cdigo fuente y archivos de metadata; necesarios para poder utilizar alguna de las tcnicas antes mencionadas.

Herramientas LLBLGen PRO [12]. Herramienta de generacin de capa de acceso a datos que realiza el mapeo ObjetoRelacional para la plataforma .NET. MyGeneration [13]. Generador de cdigo basado en plantillas que permite (entre otras cosas) la generacin de una capa de acceso a datos que realiza el mapeo Objeto-Relacional para la plataforma .NET. FireStorm/DAO [14]. Generador de cdigo para la plataforma Java capaz de importar un esquema de base de datos y generar a partir de este la capa de acceso a datos (aplicando el patrn de diseo DAO). JAG - Java Application Generator [15]. Herramienta de generacin de cdigo que permite la creacin de aplicaciones J2EE.

4.2 Programacin Orientada a Aspectos

Intencin Manipular la persistencia como un aspecto ortogonal a las funcionalidades, desacoplando el cdigo correspondiente del resto del sistema.

Motivacin La programacin orientada a aspectos (AOP) es un paradigma que permite definir abstracciones que encapsulen caractersticas que involucren a un grupo de componentes funcionales, o sea, que corten transversalmente al sistema. Cada uno de estas abstracciones definidas se denomina aspecto. Podemos encontrar en el desarrollo de un sistema aspectos de seguridad, manejo de excepciones, logueo, comunicacin, replicacin e incluso persistencia. En la programacin orientada a aspectos, las clases son diseadas e implementadas de forma separada a los aspectos, requiriendo luego fusionar las clases con los aspectos mediante el denominado aspect weaver. El aspect weaver une las clases y los aspectos, mediante puntos de juntura que establecen la relacin entre los mismos. Ejemplos de puntos de juntura son llamadas a procedimientos, ejecucin de mtodos, constructores, referencias a atributos, entre otros.

Desventajas Se debe invertir tiempo en realizar una de las siguientes tareas : desarrollar un generador de cdigo propio, seleccionar un generador ya desarrollado para el propsito especifico de solucionar la persistencia, o se debe construir una plantilla de generacin con la cual se pueda configurar un generador de propsito general. Siempre existir cdigo que de debe ser escrito a mano. Los generadores de capas de acceso a datos no suelen comportarse bien con bases de datos de caractersticas de diseo especiales (se debe seguir una estructura tpica). Mecanismo Base No tiene

Descripcin Se define la persistencia como un aspecto, donde se almacenan y obtienen los datos desde una unidad de almacenamiento secundario. Se ve que este requerimiento corta transversalmente

Copyright 2006 Tata Consultancy Services Ltd.

Page 7 of 9

un sistema. Uno de los objetivos de definir el aspecto persistencia es permitir que una aplicacin pueda ser diseada e implementada sin considerar los requerimientos de persistencia, debido a que la misma ser desarrollada de forma ortogonal a la implementacin de la lgica del sistema, para luego ser fusionada en una etapa posterior. Otros objetivos son lograr modularizar la persistencia para luego poder reutilizar el cdigo generado para el antedicho aspecto.

evolucin del mismo al tener localizado dnde realizar los cambios que afecten la persistencia de los objetos.

Desventajas Requiere del conocimiento de un nuevo paradigma con su teora, reglas y construcciones. No existen ejemplos prcticos que permitan demostrar que la utilizacin de AOP para la persistencia logre modularizarla y que dicho aspecto pueda ser reutilizado en otras aplicaciones. La programacin orientada a aspectos es an una tecnologa emergente, lo cual no lo hace un mecanismo aplicable ms all de los lmites acadmicos.

Esquema Grfico

Mecanismo Base No tiene.

Mecanismos Relacionados Si bien est tcnica tienen un enfoque diferente a las dems, debido a la introduccin de un nuevo paradigma que resuelva la persistencia, se puede apreciar una relacin con la tcnica de generadores de cdigo. En este caso el generador sera el llamado aspect weaver, que toma la implementacin del aspecto de persistencia como entrada, as como tambin la implementacin de los distintos componentes del sistema y genera el cdigo necesario para la persistencia de la aplicacin. Esta fusin es lograda mediante la definicin de puntos de juntura que son los links entre las clases y los aspectos.

Herramientas Contextos de Aplicacin Debido a que es una tecnologa emergente, se han realizado distintos prototipos y casos de estudio para lograr la aspectizacin de la persistencia, los mismos desarrollados en el rea acadmica. Se requerir de la evolucin de la tecnologa as como tambin la profundizacin en el rea por intermedio de diferentes proyectos para poder determinar: la independencia entre el aspecto persistencia y las clases de una aplicacin, la reusabilidad del aspecto frente a diferentes contextos de aplicacin y los efectos de la performance comparados con otros mecanismos de persistencia. AspectJ [16] Es un lenguaje de programacin orientado a aspectos construido como una extensin del lenguaje Java. AspectC++ [17] Es una extensin de los lenguajes C y C++ basada en traduccin fuente-fuente para dar soporte a orientacin a aspectos.

5. CONCLUSIONES
Basado en el estudio de clasificaciones existentes de mecanismos de persistencia, se realiz una nueva clasificacin que pretende subsanar las carencias detectadas. Concretamente se desarroll una clasificacin que fuese completa, con mecanismos bien definidos y orientada al desarrollador. Se consider como principal objetivo lograr una visin de los mecanismos disponibles que asistiese al desarrollador a seleccionar el mecanismo apropiado a sus necesidades. Adems, fue de sumo inters (a diferencia de algunas de las clasificaciones existentes) el mantenerse en un nivel abstracto a la hora de definir las categoras. Esto es, no basarse en plataformas ni lenguajes particulares, permitiendo as identificar

Ventajas Separacin de la persistencia; mantiene todo lo referente a la persistencia concentrado en determinada ubicacin en contrapartida a tener el cdigo que representa la persistencia de los objetos dispersos en distintos componentes. Esto incrementa la modularidad del sistema. Mantenibilidad; los sistemas que utilizan la persistencia como un aspecto facilitan el mantenimiento, entendimiento y

Copyright 2006 Tata Consultancy Services Ltd.

Page 8 of 9

las caractersticas de una tcnica y no de un producto particular. Con respecto a la completitud, se puso nfasis no solo en destacar mecanismos conocidos en la industria sino tambin en incluir mecanismos emergentes (aquellos que por el momento solo existen en mbitos acadmicos o no han logrado popularidad). Para un mejor entendimiento global de las alternativas disponibles la clasificacin fue estructurada en dos vistas: la descripcin individual de cada mecanismo y el anlisis comparativo de estos. La definicin clara y concisa de cada mecanismo se logr utilizando una estructura comn que permitiese incluir toda la informacin que se considera relevante para caracterizarlo. Por otro lado, se definieron un conjunto de criterios que permiten contrastar de manera organizada las diferencias y similitudes entres los diferentes mecanismos. Se ejemplific la clasificacin mediante la incorporacin de la descripcin de un par de ellos, aunque no pudo agregarse el anlisis comparativo por estar an en proceso de realizacin.

[5] Tyagi, S. et.al. Core Java Data Objects. Prentice Hall, 2004. ISBN 0131407317 [6] Herrington, J. Code Generation in Action. Manning Publications Co, 2003. ISBN 1930110979 [7] Software Practice Advancement 2006 (SPA 2006) http://www.spaconference.org/cgibin/wiki.pl/?GuidanceOnTheChoicesForPersistence [8] Takasaka S., Survey of Persistence Approaches, Master Thesis at Royal Institute of Technology, Stockholm University, Diciembre 2005. [9] Ambler, S., Agile Database Techniques. Wiley Publishing, 2003, ISBN 0471202835. Eliot J., Moss B., Hosking L., Approaches to Adding Persistence to Java, First International Workshop on Persistence and Java, Drymen, Scotland, Septiembre 1996. [10] Gamma, E. et al. Design Patterns. Addison-Wesley, 1st edition, 1995, ISBN 0201633612. [11] Java Enterprise Edition: http://java.sun.com/javaee/ [12] LLBLGen PRO: http://www.llblgen.com/pages/features.aspx [13] MyGeneration: http://www.mygenerationsoftware.com/portal/default.aspx [14] FireStorm/DAO: http://www.codefutures.com/hibernate/ [15] Java Application Generator: http://jag.sourceforge.net/ [16] AspectJ: http://eclipse.org/aspectj [17] AspectC++: http://www.aspectc.org/

6. TRABAJO FUTURO
El trabajo futuro a realizar incluye la validacin de la clasificacin a partir de herramientas concretas, verificando que no existan mecanismos no considerados por la clasificacin. De la misma forma es de inters validar tanto las ventajas y desventajas como contextos de aplicacin de los diferentes mecanismos mediante la implementacin de casos de estudio propios. Estos, adems, permitirn identificar nuevas caractersticas relevantes que no hayan sido consideradas. Finalmente, est programado completar la definicin del conjunto de criterios de comparacin y la realizacin del correspondiente anlisis comparativo entre mecanismos de persistencia. Esta labor permitir completar la segunda vista de la clasificacin y al mismo tiempo mejorar la descripcin de cada mecanismo individualmente.

7. REFERENCIAS
[1] Andersen, K., Vendelo, T., Past and Future of Information Systems. Butterworth-Heinemann, 1st edition, 2004, ISBN 0750661410. [2] Calegari, D., Vignaga, A., Perovich, D. Impacto de la Evolucin de la Base de Datos en el Diseo de un Sistema de Informacin. Proc. XXXII Conferencia Latinoamericana de Informtica (CLEI06). Santiago de Chile, Chile, 2006. [3] Bauer, C., King, G. Hibernate in Action. Manning Publications; 1st edition; 2004, ISBN 193239415X [4] Laddad, R., AspectJ in Action. Manning Publications Co, 2003. ISBN 1930110936

Copyright 2006 Tata Consultancy Services Ltd.

Page 9 of 9