Implicaciones de transformaciones oblicuas en el desarrollo de un framework generador de aplicaciones orientadas a aspectos

Impliaiones de transformaiones obliuas en el desarrollo de un framework generador de apliaiones orientadas a asp etos Antonia M a Reina Quintero Jesús Torres Valderrama Dpto. de Lengua jes y Sistemas informátios Dpto. de Lengua jes y Sistemas informátios Universidad de Sevilla Universidad de Sevilla Avda. Reina Meredes, s/n Avda. Reina Meredes, s/n 41012 Sevilla 41012 Sevilla reinaqulsi.us.es jtorreslsi.us.es Resumen La orientaión a asp etos mejora la evoluión del software lo alizando los ambios, mientras que el desarrollo de software onduido p or mo delos (MDD) basado en el estándar ono- ido omo Mo del Driven Arhiteture (MDA) mejora la adaptaión a los ambios tenológi- os, y p or tanto, la evoluión del software. En este artíulo se propone un enfo que híbrido, de tal forma que p o damos saar partido de las venta jas prop orionadas p or ambas propuestas. En MDA se onvierten en elemento lave las transformaiones. El artíulo se entra, por tanto, en el análisis del tip o de transforma- iones neesarias para llevar a abo este enfo que híbrido, y en ómo la tip ología de las mismas afeta al transformador de mo delos de un framework que genere apliaiones en base a este enfo que híbrido. 1. Intro duión Debido a los onstantes ambios que tienen que enfrentar los ingenieros software en los últimos años han surgido propuestas tanto para onseguir una mejor evoluión de los sistemas software, omo para p o der adoptar los ambios de tenología on mínimo oste. En la primera línea, se enuentra lo que se onoe omo el nuevo paradigma de desarrollo software orientado a asp etos (DSOA)[4℄. En la segunda se puede inluir el desarrollo onduido p or mo delos (MDD), sobre todo on la propuesta MDA[5℄ de la Ob jet Management Group (OMG). Puesto que ambas líneas de traba jo no son inompatibles, sino más bien, todo lo ontrario, es fatible p ensar que aunando amb os paradigmas p o demos onseguir apliaiones que se pueden adaptar más fáilmente a los ambios de requisitos y a los ambios de te- nología. Así, nuestra propuesta se puede onsiderar omo un enfo que híbrido, en el sentido de que prop onemos traba jar on oneptos separados a ualquier nivel mo delado, entendiendo p or niveles de mo delo los niveles propuestos por MDA: mo delos independientes de la plataforma, mo delos dep endientes de plataforma y ó digo). En [6℄ se detallaba la arquitetura de un framework generador de apliaiones, basado en MDA, que daba la p osibilidad de mo delar oneptos p or separado. Estos asp etos se esp eiaban mediante lengua jes de modelado esp eíos de dominio, onvirtiendo así las transformaiones en elementos lave, ya que pueden llegar inluso a realizar funiones de weaver . Desde esta persp etiva, omp oner un asp eto y un mo delo que esp eique la fun- ionalidad básia, se onvertiría en la apli- aión de una serie de transformaiones, a dos mo delos, o a dos metamo delos. En este artíulo se estudian los distintos tip os de transformaiones existentes, para ver on uál de ellas traba jará nuestro framework . Además, se analizan las impliaiones de las mismas sobre el diseño de un omp onente del framework , el transformador de mo delos. Para ello, el traba jo se estrutura omo sigue: En la seión 2 se presenta una ategorizaión del tip o de transformaiones que nos p o demos enontrar en la bibliografía, para p osteriormente determinar on uáles de ellas deb e traba jar nuestro framework generador de apliaiones. El tip o de transformaiones será determinante para denir los requisitos del framework, sobre to do del transformador de mo delos. A ontinuaión, en la seión Estrutura de apliaiones generadas por el framework , se hae una revisión de la estrutura de las apli- aiones on las que va a traba jar el framework, on ob jeto de determinar los requisitos que imp onen al mismo. En la seión seión 4 se denen las araterístias del transformador de mo delos en base al tip o de transformaiones que vamos a ontemplar en el framework . Luego, en la seión 5, se exp onen las op- iones de implementaión de las reglas de trasformaión y motiva p or qué se elige SQL emb ebido para implementarlas. Finalmente, se onluye el traba jo y se apuntan futuras líneas de investigaión. 2. Categorizando transformaiones Según la OMG [5℄, la transformaión de modelos es el pro eso de onvertir un modelo en otro. Según Frane y Bieman [2℄, las transformaiones se pueden lasiar en transformaiones vertiales y transformaiones horizontales. Las transformaiones vertiales son aquellas que se aplian a un mo delo para obtener otro expresado on un nivel de abstraión diferente, mientras que las transformaiones horizontales se aplian a un mo delo para obtener otro del mismo nivel de abstraión. Un ejemplo de transformaiones vertiales en el ámbito de MDA son las transformaiones neesarias para transformar un Mo delo Indep endiente de Plataforma (PIM) en un Mo delo Esp eío de Plataforma (PSM), mientras que una transformaión horizontal, puede ser la omp osiión de un asp eto en un mo delo sin ambiar el nivel de abstraión. Czarneki [1℄, sin embargo, distingue entre tres tip os de transformaiones: vertiales, horizontales y obliuas. De forma que las transformaiones vertiales involuran transformar un modelo de alto nivel en un modelo de más ba jo nivel, llamándolas también renamientos haia adelante. Las transformaiones horizontales mo dian la estrutura mo dular de una apliaión al mismo nivel. Mientras que las transformaiones obliuas tienen omp onentes tanto vertiales omo horizontales. En la 1 se muestra un esquema de los tip os de transformaiones que onsidera Czarneki. Transformación Horizontal Transformación Vertical Transformación Oblicua Figura 1: Transformaiones tomadas de [1℄ En [3℄, además se identian los distintos tip os de transformaiones vertiales y horizontales que p o demos apliar a los mo delos. Así, nos p o demos enontrar on los siguientes tip os de renamientos: • Esp eializaión. Este tipo de transformaión toma omo entrada un ob jeto o onjunto de ob jetos menos espeializados y da omo resultado un onjunto de ob jetos más esp eializados. • Elab oraión. Toma omo entrada una onguraión de ob jetos menos detallada y da omo resultado onguraiones de ob jetos más detalladas. • Realizaión. PIM Interfaz Usuario PIM Navegación PIM Seguridad PIM Distribución PIM Persistencia PIM Conceptual PSM Interfaz Usuario JSF PSM Navegación JSF PSM Seguridad EJB PSM Distribución EJB PSM Persistencia EJB PSM Relacional Código Fuente EJB Código Fuente JSF Código Fuente SQL Código Fuente EJB Código Fuente EJB Transformación PIM -> Componente JSF Transformación PIM -> Componente JSF Transformación PIM -> Componente EJB Transformación PIM -> Componente EJB Transformación PIM -> Componente EJB Transformación PIM -> Relacional Transformación Generación Código Transformación Generación Código Transformación Generación Código Transformación Generación Código Transformación Generación Código Transformación Generación Código Figura 2: Estrutura de una apliaión generada p or el framework Las onguraiones de ob jetos de la entrada se transforman en ob jetos que representan su implementaión. • Derivaión. Nuevas esp eiaiones de ob jetos se derivan de las onguraiones de ob jetos que se toman omo entrada. • Desomp osiión. Ob jetos individuales se transforman en onguraiones de ob jetos en la salida. Mientras que on resp eto a las transforma- iones horizontales nos p o demos enontrar los siguientes tip os: • Refatorizaión. Son transformaiones realizadas para mejorar la estrutura de la esp eiaión dada p or los desarrolladores. • Optimizaión. Su ob jetivo es mejorar algunas araterístias de una espeiaión, tales omo su rendimiento o el uso de los reursos. • Deslo alizaión. Es un tip o de transformaión que se utiliza para implementar asp etos, es deir, para enapsular elementos que ortan la estrutura o el omp ortamiento de otros elementos, lo que en la terminología de orientaión a asp etos se ono e omo rossutting onerns. 3. Estrutura de apliaiones generadas p or el framework En este apartado, analizaremos de qué tip o de apliaiones se tiene que o upar el framework , para posteriormente, omprobar qué implia- iones tendrán estas deisiones en el diseño del transformador de mo delos. Como ya se ha omentado en la intro du- ión, algunas transformaiones servirán omo meanismo de omp osiión. Sup ongamos que tenemos separados los distintos oneptos de nuestro sistema a nivel de mo delo indep endiente de la plataforma, p ero la plataforma esp eía en la que queremos implementar nuestro sistema no proporiona meanismos de separaión. En este aso, o bien a la hora de generar los modelos esp eíos de plataforma, o bien a la hora de generar el ó digo, tendríamos que omp oner esos mo delos separados. Para lariar un p o o más este onepto, véase el ejemplo de la Figura 2. En él se mues- Editor Modelos Validador Modelos Editor de Transformaciones Transformador de modelos Generador Código Parser Generador Editor Código (IDE) Repositorio de Modelos Repositorio de Transformaciones Código Fuente Figura 3: Comp onentes del framework generador de apliaiones tra la estrutura que tendrá una apliaión generada p or el framework. Cuenta on tres niveles de mo delos (PIM, PSM y ó digo), que se pueden distinguir en horizontal, y varios asp etos separados (oneptual, persistenia, distribuión, seguridad, navegaión e interfaz de usuario. Las transformaiones de PIM a PSM son transformaiones vertiales, ya que pasan de un nivel de abstraión mayor a un nivel de abstraión menor, mientras que las transformaiones PSM a omponente Java Server Faes (JSF) pueden ser obliuas. Es deir, las transformaiones de PSM a omp onente JSF pueden tener omp onentes vertiales y horizontales, ya que no solamente disminuyen el nivel de abstraión, sino que mezlan dos on- eptos, el interfaz de usuario y la navegaión. Por tanto, en el aso de la Figura 2, los asp etos de navegaión y presentaión se espei- an p or separado a nivel de PIM, p ero omo JSF, que es la plataforma elegida para implementarlos, no presenta una separaión lara de amb os, en el mo delo resultante de la transformaión tendremos amb os asp etos entremez- lados. Es deir, las transformaiones han realizado un traba jo de weaving . 4. Caraterístias del transformador de mo delos Como ya se ha menionado en la introdu- ión, en [6℄ se prop onía la arquitetura de un framework generador de apliaiones. En la Figura 3, se puede observar que los prinipales omp onentes denidos en la misma, son: un editor de mo delos, un validador de mo delos, un editor de transformaiones, un transformador de mo delos, un generador de ó digo y un editor de ó digo. De to dos ellos, el omp onente que se ve más inueniado p or el he- ho de tener que tratar on transformaiones obliuas es el transformador de mo delos, p or lo tanto, en adelante nos entraremos en analizar las impliaiones de implementar este tip o de transformaiones sobre el mismo. En [1℄, se distingue entre generadores omp osiionales, y generadores transforma- ionales. Los generadores omp osiionales no realizan transformaiones que puedan redenir la estrutura mo dular de una apliaión. Los generadores transformaionales, sin embargo, no solamente realizan renamientos, sino que también son apaes de traba jar on transformaiones que tengan un omp onente horizontal (bien sean transformaiones horizontales, bien sean transformaiones obliuas). Este tip o de transformadores es más p otente que el omp osiional. Así que nuestro transformador de mo delos ha de ser transformaional, y este heho, es determinante en su arquitetura. La eleión de ómo se van a implementar las reglas de transformaión va a ser otro punto determinante para diseñar la arquitetura del transformador de mo delos. Atendiendo a la lasiaión realizada en [7℄, se pueden adoptar tres enfo ques distintos: • Manipulaión direta de mo delos. Las herramientas que siguen este enfo que ofreen al usuario aeso a una representaión interna del mo delo y una serie de Interfaes de Programador de Apliiones (APIs) para manipular la representaión. La manipulaión direta tiene la ventaja de que el lengua je que se suele utilizar para traba jar on las APIs suele ser un lengua je de uso omún tal omo Visual Basi o Java, on lo ual, los desarrolladores no neesitan un entrenamiento extra para esribir transformaiones. Sin embargo, estas APIs suelen restringir la lase de transformaiones que se pueden realizar. Además, omo los lengua jes utilizados son de propósito general, no tienen abstraiones adeuadas para expresar transformaiones, p or lo tanto, el esribir una transformaión se onvierte en una tarea que onsume tiemp o, y además, suelen ser algoritmos difí- iles de mantener. • Representaión intermedia. La herramienta exp orta el mo delo a un formato estándar, normalmente XML, y una herramienta externa toma el mo delo y lo transforma. La representaión intermedia tiene la venta ja de que existen en el merado muhas herramientas que exp ortan o imp ortan mo delos desritos en XMI, y que, p or tanto, se pueden utilizar heramientas XML ya existentes, omo XSLT para realizar transformaiones. Sin embargo, la deni- ión de transformaiones, aunque sean simples, de mo delos en XSLT requiere un esfuerzo onsiderable. Otro inonveniente imp ortante de este tip o de arquitetura es que las transformaiones se realizan por lotes, on lo ual es difíil que el usuario tenga un diálogo interativo on la herramienta. • Sop orte de lengua je de transformaión. La herramienta ofree un lengua je que prop oriona un onjunto de onstrutores o meanismos para expresar, omp oner y apliar transformaiones de manera explíita. Según los autores de [7℄, este enfo que es el que ofree un mayor p otenial de los tres. En la siguiente seión veremos ómo implementaremos las reglas de transformaión, y p or tanto, nos ayudará a esoger una de estas tres propuestas de arquiteturas. 5. Implementaión de las reglas de transformaión A la hora de implementar las reglas de transformaión que tiene que pro esar nuestro generador de mo delos, tenemos uatro op iones distintas: • Utilizando un lengua je de programaión y haiendo la odiaión a mano. • Utilizando un lengua je de queries emb ebido, tal omo XPath [8℄ o XQuery [9℄. • Utilizando un sistema basado en reglas, tal omo CLIPS, o Prolog. • Denir un lengua je, bien pro edural, bien delarativo, bien una mezla de amb os. Con la primera op ión se pueden obtener implementaiones más eientes, p ero el tener que esribir la o diaión a mano es un gran inonveniente. El elegir esta op ión impliaría el elegir una arquitetura de manipulaión direta de mo delo. La segunda y terera op ión elimina algún traba jo de esritura, p ero ambas presentan el inonveniente de que para utilizarlos, hay que adaptar el formato del árb ol de sintaxis abstrata al formato on el que traba ja o bien el sistema de reglas, o bien el lengua je de queries emb ebido. La segunda op ión para expresar las transformaiones impliaría una arquitetura de representaión intermedia, mientras que la última determina una arquitetura de soporte de lengua je de transformaiones. Como uno de los ob jetivos propuestos a la hora de realizar el framework es aprovehar las herramientas existentes, entre to das estas op iones, la más viable es el uso de XPath o XQuery o XSLT, para p o der traba jar on todas las herramientas ya disp onibles en XML. Como ya se ha omentado en la seión 4, este enfo que requiere una exp erienia onsiderable para denir las transformaiones, así que, se tendrá que prop orionar una forma de aligerar este esfuerzo, bien deniendo un lengua je p or enima de XSLT, bien deniendo un lengua je esp eío de dominio para traba jar on estas transformaiones. 6. Conlusiones y traba jos futuros En este artíulo se ha puesto de maniesto la imp ortania del tratamiento de reglas de transformaión obliuas en el aso de que el propio transformador tenga que atuar omo weaver . Además, se ha visto ómo la deisión de tratar on transformaiones obliuas en el generador de mo delo, obliga a tener un generador de tipo transformaional, desartando los generadores omp osiionales. De la misma forma, a la hora de implementar las transformaiones, se ha determinado que la mejor op ión, según los requisitos impuestos al framework, es utilizar SQL emb ebido en algún lengua je del tip o XQuery o XPath, lo que implia una arquitetura de tip o representaión intermedia. Como traba jos futuros, estamos traba jando en la deniión de transformaiones a nivel de metamo delos, para onseguir el tejido de los mismos. Referenias [1℄ Czanerki, K., Eiseneker, U.W. Generative Programming. Methods, Tools and Appliations . Addison Wesley, 2000. [2℄ Frane, R., Bieman, J.M. Multi-View Software Evolution: A UML-based Framework for Evolving Objet-Oriented Software . In the Pro eedings of the International Conferene on Software Mainteinane (ICSM 2001). Novemb er, 2001. [3℄ Greeneld, J., Short, K., Co ok, S. , Kent, S. Software Fatories. Assembling Appliations with Patterns, Models, Frameworks, and Tools. Wiley Publishing, In, 2004. [4℄ Kizales, G., Lamping, J., Mendhekar, A. and Maeda, C., Lop es, C.,Loingtier, J.M., Irwin, J. Aspet-Oriented Programming . 11th Europ een Conf. Ob jet-Oriented Programming, 1997. Eds. M. Ak³it and S. Matsuoka. LNCS 1241, pp. 220-242, Springer Verlag. [5℄ Ob jet Management Group. MDA Guide. Version 1.0.1 , OMG, 2003. [6℄ Reina, A. M., Torres, J. Separaión de on- eptos y MDA: Arquitetura de un framework , I Taller sobre Desarrollo de Software Dirigido p or Mo delos, MDA y Apliaiones (DSDM'04). Celebrado junto on las Jornadas de Ingeniería del Software y Bases de Datos (2004). Málaga, España. Novemb er, 2004. ISBN: 84-688-8870-2. [7℄ Sendall, S., Kozazynski, W. Model Transformation - The Heart and Soul of ModelDriven Sofware Development IEEE Software. Vol 20, n o 5, pp. 42-45. Sept/Ot 2003. [8℄ W3C. XML Path Language (XPath) 2.0 W3C Working Draft 04 April 2005 (http://www.w3.org/TR/xpath20/) [9℄ W3C. XQuery 1.0: An XML Query Language W3C Working Draft 04 April 2005.(http://www.w3.org/TR/xquery/)