Reina Quintero, Antonia María

Torres Valderrama, Jesús

idUS. Depósito de Investigación Universidad de Sevilla

Implicaciones de transformaciones oblicuas en el desarrollo de unframework generador de aplicaciones orientadas a aspectosAntonia MaReina Quintero Jesús Torres ValderramaDpto. de Lenguajes y Sistemas informáticos Dpto. de Lenguajes y Sistemas informáticosUniversidad de Sevilla Universidad de SevillaAvda. Reina Mercedes, s/n Avda. Reina Mercedes, s/n41012 Sevilla 41012 Sevillareinaqu@lsi.us.es jtorres@lsi.us.esResumenLa orientación a aspectos mejora la evolucióndel software localizando los cambios, mientrasque el desarrollo de software conducido pormodelos (MDD) basado en el estándar cono-cido como Model Driven Architecture (MDA)mejora la adaptación a los cambios tecnológi-cos, y por tanto, la evolución del software. Eneste artículo se propone un enfoque híbrido,de tal forma que podamos sacar partido de lasventajas proporcionadas por ambas propues-tas. En MDA se convierten en elemento clavelas transformaciones. El artículo se centra, portanto, en el análisis del tipo de transforma-ciones necesarias para llevar a cabo este en-foque híbrido, y en cómo la tipología de lasmismas afecta al transformador de modelos deun framework que genere aplicaciones en basea este enfoque híbrido.1. IntroducciónDebido a los constantes cambios que tienenque enfrentar los ingenieros software en los úl-timos años han surgido propuestas tanto paraconseguir una mejor evolución de los sistemassoftware, como para poder adoptar los cam-bios de tecnología con mínimo coste. En laprimera línea, se encuentra lo que se conoce co-mo el nuevo paradigma de desarrollo softwareorientado a aspectos (DSOA)[4]. En la segun-da se puede incluir el desarrollo conducido pormodelos (MDD), sobre todo con la propues-ta MDA[5] de la Object Management Group(OMG).Puesto que ambas líneas de trabajo no sonincompatibles, sino más bien, todo lo con-trario, es factible pensar que aunando ambosparadigmas podemos conseguir aplicacionesque se pueden adaptar más fácilmente a loscambios de requisitos y a los cambios de tec-nología. Así, nuestra propuesta se puede con-siderar como un enfoque híbrido, en el senti-do de que proponemos trabajar con conceptosseparados a cualquier nivel modelado, entendi-endo por niveles de modelo los niveles propues-tos por MDA: modelos independientes de laplataforma, modelos dependientes de platafor-ma y código).En [6] se detallaba la arquitectura de unframework generador de aplicaciones, basadoen MDA, que daba la posibilidad de mode-lar conceptos por separado. Estos aspectos seespecicaban mediante lenguajes de modela-do especícos de dominio, convirtiendo así lastransformaciones en elementos clave, ya quepueden llegar incluso a realizar funciones deweaver. Desde esta perspectiva, componer unaspecto y un modelo que especique la fun-cionalidad básica, se convertiría en la apli-cación de una serie de transformaciones, a dosmodelos, o a dos metamodelos.En este artículo se estudian los distintostipos de transformaciones existentes, para vercon cuál de ellas trabajará nuestro framework.Además, se analizan las implicaciones de lasmismas sobre el diseño de un componente delframework, el transformador de modelos. Paraello, el trabajo se estructura como sigue:En la sección 2 se presenta una catego-rización del tipo de transformaciones que nospodemos encontrar en la bibliografía, paraposteriormente determinar con cuáles de ellasdebe trabajar nuestro framework generadorde aplicaciones. El tipo de transformacionesserá determinante para denir los requisitosdel framework, sobre todo del transformadorde modelos.A continuación, en la sección Estructura deaplicaciones generadas por el framework, sehace una revisión de la estructura de las apli-caciones con las que va a trabajar el frame-work, con objeto de determinar los requisitosque imponen al mismo.En la sección sección 4 se denen las ca-racterísticas del transformador de modelos enbase al tipo de transformaciones que vamos acontemplar en el framework.Luego, en la sección 5, se exponen las op-ciones de implementación de las reglas detrasformación y motiva por qué se elige SQLembebido para implementarlas. Finalmente, seconcluye el trabajo y se apuntan futuras líneasde investigación.2. Categorizando transformacionesSegún la OMG [5], la transformación de mo-delos es el proceso de convertir un modelo enotro. Según France y Bieman [2], las trans-formaciones se pueden clasicar en transfor-maciones verticales y transformaciones hori-zontales. Las transformaciones verticales sonaquellas que se aplican a un modelo para obte-ner otro expresado con un nivel de abstraccióndiferente, mientras que las transformacioneshorizontales se aplican a un modelo para ob-tener otro del mismo nivel de abstracción. Unejemplo de transformaciones verticales en elámbito de MDA son las transformaciones nece-sarias para transformar un Modelo Independi-ente de Plataforma (PIM) en un Modelo Es-pecíco de Plataforma (PSM), mientras queuna transformación horizontal, puede ser lacomposición de un aspecto en un modelo sincambiar el nivel de abstracción.Czarnecki [1], sin embargo, distingue entretres tipos de transformaciones: verticales, ho-rizontales y oblicuas. De forma que las trans-formaciones verticales involucran transformarun modelo de alto nivel en un modelo de másbajo nivel, llamándolas también renamientoshacia adelante. Las transformaciones horizon-tales modican la estructura modular de unaaplicación al mismo nivel. Mientras que lastransformaciones oblicuas tienen componentestanto verticales como horizontales. En la 1 semuestra un esquema de los tipos de transfor-maciones que considera Czarnecki.Transformación HorizontalTransformación VerticalTransformación OblicuaFigura 1: Transformaciones tomadas de [1]En [3], además se identican los distintostipos de transformaciones verticales y horizon-tales que podemos aplicar a los modelos. Así,nos podemos encontrar con los siguientes tiposde renamientos:• Especialización.Este tipo de transformación toma comoentrada un objeto o conjunto de objetosmenos especializados y da como resulta-do un conjunto de objetos más especiali-zados.• Elaboración.Toma como entrada una conguración deobjetos menos detallada y da como resul-tado conguraciones de objetos más de-talladas.• Realización.PIM InterfazUsuarioPIMNavegaciónPIMSeguridadPIMDistribuciónPIMPersistenciaPIMConceptualPSMInterfazUsuarioJSFPSMNavegaciónJSFPSMSeguridadEJBPSMDistribuciónEJBPSMPersistenciaEJBPSMRelacionalCódigoFuente EJBCódigo Fuente JSFCódigoFuente SQLCódigoFuente EJBCódigoFuente EJBTransformaciónPIM -> Componente JSFTransformaciónPIM -> Componente JSFTransformaciónPIM -> Componente EJBTransformaciónPIM -> Componente EJBTransformaciónPIM -> Componente EJBTransformaciónPIM -> RelacionalTransformaciónGeneración Código TransformaciónGeneración CódigoTransformaciónGeneración CódigoTransformaciónGeneración CódigoTransformaciónGeneración CódigoTransformaciónGeneración CódigoFigura 2: Estructura de una aplicación generada por el frameworkLas conguraciones de objetos de la en-trada se transforman en objetos que rep-resentan su implementación.• Derivación.Nuevas especicaciones de objetos sederivan de las conguraciones de objetosque se toman como entrada.• Descomposición.Objetos individuales se transforman enconguraciones de objetos en la salida.Mientras que con respecto a las transforma-ciones horizontales nos podemos encontrar lossiguientes tipos:• Refactorización.Son transformaciones realizadas paramejorar la estructura de la especicacióndada por los desarrolladores.• Optimización.Su objetivo es mejorar algunas caracterís-ticas de una especicación, tales como surendimiento o el uso de los recursos.• Deslocalización.Es un tipo de transformación que se uti-liza para implementar aspectos, es decir,para encapsular elementos que cortan laestructura o el comportamiento de otroselementos, lo que en la terminología deorientación a aspectos se conoce comocrosscutting concerns.3. Estructura de aplicaciones gene-radas por el frameworkEn este apartado, analizaremos de qué tipo deaplicaciones se tiene que ocupar el framework,para posteriormente, comprobar qué implica-ciones tendrán estas decisiones en el diseño deltransformador de modelos.Como ya se ha comentado en la introdu-cción, algunas transformaciones servirán co-mo mecanismo de composición. Supongamosque tenemos separados los distintos concep-tos de nuestro sistema a nivel de modelo inde-pendiente de la plataforma, pero la platafor-ma especíca en la que queremos implementarnuestro sistema no proporciona mecanismos deseparación. En este caso, o bien a la hora degenerar los modelos especícos de plataforma,o bien a la hora de generar el código, ten-dríamos que componer esos modelos separa-dos.Para claricar un poco más este concepto,véase el ejemplo de la Figura 2. En él se mues-Editor ModelosValidador ModelosEditor de TransformacionesTransformador de modelosGenerador CódigoParserGeneradorEditor Código (IDE)Repositorio deModelosRepositorio deTransformacionesCódigoFuenteFigura 3: Componentes del framework generador de aplicacionestra la estructura que tendrá una aplicacióngenerada por el framework. Cuenta con tresniveles de modelos (PIM, PSM y código), quese pueden distinguir en horizontal, y variosaspectos separados (conceptual, persistencia,distribución, seguridad, navegación e interfazde usuario.Las transformaciones de PIM a PSM sontransformaciones verticales, ya que pasan deun nivel de abstracción mayor a un nivel deabstracción menor, mientras que las trans-formaciones PSM a componente Java ServerFaces (JSF) pueden ser oblicuas. Es decir, lastransformaciones de PSM a componente JSFpueden tener componentes verticales y hori-zontales, ya que no solamente disminuyen elnivel de abstracción, sino que mezclan dos con-ceptos, el interfaz de usuario y la navegación.Por tanto, en el caso de la Figura 2, los as-pectos de navegación y presentación se especi-can por separado a nivel de PIM, pero comoJSF, que es la plataforma elegida para imple-mentarlos, no presenta una separación clara deambos, en el modelo resultante de la transfor-mación tendremos ambos aspectos entremez-clados. Es decir, las transformaciones han re-alizado un trabajo de weaving.4. Características del transfor-mador de modelosComo ya se ha mencionado en la introdu-cción, en [6] se proponía la arquitectura deun framework generador de aplicaciones. Enla Figura 3, se puede observar que los princi-pales componentes denidos en la misma, son:un editor de modelos, un validador de mode-los, un editor de transformaciones, un trans-formador de modelos, un generador de códigoy un editor de código. De todos ellos, el com-ponente que se ve más inuenciado por el he-cho de tener que tratar con transformacionesoblicuas es el transformador de modelos, por lotanto, en adelante nos centraremos en analizarlas implicaciones de implementar este tipo detransformaciones sobre el mismo.En [1], se distingue entre generadorescomposicionales, y generadores transforma-cionales. Los generadores composicionales norealizan transformaciones que puedan redenirla estructura modular de una aplicación. Losgeneradores transformacionales, sin embargo,no solamente realizan renamientos, sino quetambién son capaces de trabajar con trans-formaciones que tengan un componente hori-zontal (bien sean transformaciones horizonta-les, bien sean transformaciones oblicuas). Estetipo de transformadores es más potente que elcomposicional.Así que nuestro transformador de modelosha de ser transformacional, y este hecho, esdeterminante en su arquitectura.La elección de cómo se van a implementarlas reglas de transformación va a ser otro pun-to determinante para diseñar la arquitecturadel transformador de modelos. Atendiendo a laclasicación realizada en [7], se pueden adop-tar tres enfoques distintos:• Manipulación directa de modelos. Lasherramientas que siguen este enfoqueofrecen al usuario acceso a una repre-sentación interna del modelo y una se-rie de Interfaces de Programador de Ap-liciones (APIs) para manipular la repre-sentación.La manipulación directa tiene la venta-ja de que el lenguaje que se suele uti-lizar para trabajar con las APIs sueleser un lenguaje de uso común tal co-mo Visual Basic o Java, con lo cual,los desarrolladores no necesitan un en-trenamiento extra para escribir transfor-maciones. Sin embargo, estas APIs sue-len restringir la clase de transformacionesque se pueden realizar. Además, como loslenguajes utilizados son de propósito ge-neral, no tienen abstracciones adecuadaspara expresar transformaciones, por lotanto, el escribir una transformación seconvierte en una tarea que consume tiem-po, y además, suelen ser algoritmos difí-ciles de mantener.• Representación intermedia. La herra-mienta exporta el modelo a un forma-to estándar, normalmente XML, y unaherramienta externa toma el modelo y lotransforma.La representación intermedia tiene la ven-taja de que existen en el mercado muchasherramientas que exportan o importanmodelos descritos en XMI, y que, por tan-to, se pueden utilizar heramientas XMLya existentes, como XSLT para realizartransformaciones. Sin embargo, la deni-ción de transformaciones, aunque seansimples, de modelos en XSLT requiere unesfuerzo considerable.Otro inconveniente importante de estetipo de arquitectura es que las transfor-maciones se realizan por lotes, con lo cuales difícil que el usuario tenga un diálogointeractivo con la herramienta.• Soporte de lenguaje de transformación.La herramienta ofrece un lenguaje queproporciona un conjunto de constructoreso mecanismos para expresar, componer yaplicar transformaciones de manera ex-plícita.Según los autores de [7], este enfoque es elque ofrece un mayor potencial de los tres.En la siguiente sección veremos cómo im-plementaremos las reglas de transformación, ypor tanto, nos ayudará a escoger una de estastres propuestas de arquitecturas.5. Implementación de las reglas detransformaciónA la hora de implementar las reglas de trans-formación que tiene que procesar nuestro ge-nerador de modelos, tenemos cuatro opcionesdistintas:• Utilizando un lenguaje de programacióny haciendo la codicación a mano.• Utilizando un lenguaje de queries embe-bido, tal como XPath [8] o XQuery [9].• Utilizando un sistema basado en reglas,tal como CLIPS, o Prolog.• Denir un lenguaje, bien procedural, biendeclarativo, bien una mezcla de ambos.Con la primera opción se pueden obtenerimplementaciones más ecientes, pero el tenerque escribir la codicación a mano es un graninconveniente. El elegir esta opción implicaríael elegir una arquitectura de manipulación di-recta de modelo.La segunda y tercera opción elimina algúntrabajo de escritura, pero ambas presentan elinconveniente de que para utilizarlos, hay queadaptar el formato del árbol de sintaxis ab-stracta al formato con el que trabaja o bien elsistema de reglas, o bien el lenguaje de queriesembebido.La segunda opción para expresar las trans-formaciones implicaría una arquitectura derepresentación intermedia, mientras que la úl-tima determina una arquitectura de soporte delenguaje de transformaciones.Como uno de los objetivos propuestos a lahora de realizar el framework es aprovecharlas herramientas existentes, entre todas estasopciones, la más viable es el uso de XPath oXQuery o XSLT, para poder trabajar con to-das las herramientas ya disponibles en XML.Como ya se ha comentado en la sección 4, esteenfoque requiere una experiencia considerablepara denir las transformaciones, así que, setendrá que proporcionar una forma de aligerareste esfuerzo, bien deniendo un lenguaje porencima de XSLT, bien deniendo un lenguajeespecíco de dominio para trabajar con estastransformaciones.6. Conclusiones y trabajos futurosEn este artículo se ha puesto de maniestola importancia del tratamiento de reglas detransformación oblicuas en el caso de que elpropio transformador tenga que actuar comoweaver. Además, se ha visto cómo la decisiónde tratar con transformaciones oblicuas en elgenerador de modelo, obliga a tener un genera-dor de tipo transformacional, descartando losgeneradores composicionales.De la misma forma, a la hora de imple-mentar las transformaciones, se ha determi-nado que la mejor opción, según los requisi-tos impuestos al framework, es utilizar SQLembebido en algún lenguaje del tipo XQueryo XPath, lo que implica una arquitectura detipo representación intermedia.Como trabajos futuros, estamos trabajandoen la denición de transformaciones a nivel demetamodelos, para conseguir el tejido de losmismos.Referencias[1] Czanercki, K., Eisenecker, U.W. Genera-tive Programming. Methods, Tools and Ap-plications . Addison Wesley, 2000.[2] France, R., Bieman, J.M. Multi-View Soft-ware Evolution: A UML-based Frameworkfor Evolving Object-Oriented Software. Inthe Proceedings of the International Con-ference on Software Mainteinance (ICSM2001). November, 2001.[3] Greeneld, J., Short, K., Cook, S. , Kent,S. Software Factories. Assembling Applica-tions with Patterns, Models, Frameworks,and Tools. Wiley Publishing, Inc, 2004.[4] Kiczales, G., Lamping, J., Mendhekar, A.and Maeda, C., Lopes, C.,Loingtier, J.M.,Irwin, J. Aspect-Oriented Programming.11th Europeen Conf. Object-Oriented Pro-gramming, 1997. Eds. M. Ak³it andS. Matsuoka. LNCS 1241, pp. 220-242,Springer Verlag.[5] Object Management Group. MDA Guide.Version 1.0.1, OMG, 2003.[6] Reina, A. M., Torres, J. Separación de con-ceptos y MDA: Arquitectura de un frame-work, I Taller sobre Desarrollo de SoftwareDirigido por Modelos, MDA y Aplicaciones(DSDM'04). Celebrado junto con las Jor-nadas de Ingeniería del Software y Bases deDatos (2004). Málaga, España. November,2004. ISBN: 84-688-8870-2.[7] Sendall, S., Kozaczynski, W. Model Trans-formation - The Heart and Soul of Model-Driven Sofware Development IEEE Soft-ware. Vol 20, no5, pp. 42-45. Sept/Oct2003.[8] W3C. XML Path Language (XPath) 2.0W3C Working Draft 04 April 2005(http://www.w3.org/TR/xpath20/)[9] W3C. XQuery 1.0: An XML Query Lan-guage W3C Working Draft 04 April2005.(http://www.w3.org/TR/xquery/)

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

https://idus.us.es/xmlui/bitstream/handle/11441/67253/Implicaciones%20de%20Transformaciones.pdf?sequence=1&isAllowed=y

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

Abstract

Similar works

Full text

Available Versions

idUS. Depósito de Investigación Universidad de Sevilla