Recuperación y procesado de datos biológicos mediante Ingeniería Dirigida por Modelos * . Abel Gómez, Artur Boronat, Claudia Täubner, Jose Á. Carsí, Isidro Ramos Silke Eckstein Departament de Sistemes Informàtics i Computació. Institut für Informationssysteme. Universitat Politècnica de València. Technische Universität Braunschweig. Camino de Vera, s/n. Mühlenpfordtstraße 23, 2.OG. 46022 València. España. D-38106 Braunschweig. Deutschland. { agomez | aboronat | pcarsi | iramos } @ dsic.upv.es { c.taeubner | s.eckstein } @ tu-bs.de Resumen Este artículo muestra cómo el proceso de desarrollo de software dirigido por modelos (DSDM) es aplicable al campo de la bioinfor- mática ya que la estructura de los datos bioló- gicos se puede expresar mediante modelos de forma muy natural. En el contexto de la bio- informática es común la existencia de fuentes de datos (rellenadas de forma manual) hetero- géneas. Con el objetivo de validar la informa- ción de estas fuentes de datos, se han adap- tado diversos formalismos y herramientas de simulación. El proceso de introducción de da- tos —obtenidos de estas bases de datos— en las herramientas de validación se realiza tra- dicionalmente de forma manual. Este trabajo describe cómo se ha resuelto este problema si- guiendo una metodología de DSDM emplean- do transformaciones de modelos. Esto permi- te automatizar el proceso de migración de da- tos, obtener herramientas modulares, aislar el proceso de transformación de datos de los for- matos de persistencia de estos, y disponer de información de trazabilidad. Palabras clave: Desarrollo de Software Di- rigido por Modelos (DSDM), bioinformática, migración de datos. * Este artículo ha sido financiado por el Proyecto Nacional de Investigación Científica, Desarrollo e In- novación META TIN2006-15175-C05-01. 1. Motivación. La práctica tradicional en los estudios cien- tíficos de «experimentación → análisis → pu- blicación» está cambiando a «experimentación → organización de datos → análisis → publi- cación». Esto se debe a que, hoy en día, los datos no se obtienen únicamente de experi- mentos, sino que también se obtienen de si- mulaciones. Esta gran cantidad de datos ge- nerados no siempre tiene la misma estructura y puede estar almacecenada en bases de da- tos heterogéneas. Además, el elevado número de datos requiere el desarrollo de herramientas informáticas que nos permitan representarlos para analizarlos, y a su vez, realizar otras si- mulaciones con ellos. En el campo de la bioinformática encontra- mos esta problemática en el análisis y simula- ción de los mecanismos de señales de las cé- lulas (Pathways ). Un pathway es un conjunto de reacciones químicas que se producen en el interior de una célula tras la recepción de un estímulo. En estudios de este tipo se observa tanto el rellenado independiente de fuentes de datos como el desarrollo independiente de he- rramientas de modelado. Por ello, estos datos deben ser reconvertidos de forma manual para que puedan ser utilizados en las herramientas de simulación. En un escenario así, disponer de herramientas interoperables es deseable. El Desarrollo de Software Dirigido por Mo-
10
Embed
mediante Ingeniería Dirigida por Modelos*. Abel Gómez ... · Recuperación y procesado de datos biológicos mediante Ingeniería Dirigida por Modelos*. Abel Gómez, Artur Boronat,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Recuperación y procesado de datos biológicosmediante Ingeniería Dirigida por Modelos*.
Abel Gómez, Artur Boronat, Claudia Täubner,Jose Á. Carsí, Isidro Ramos Silke Eckstein
Departament de Sistemes Informàtics i Computació. Institut für Informationssysteme.
Universitat Politècnica de València. Technische Universität Braunschweig.
Este artículo muestra cómo el proceso dedesarrollo de software dirigido por modelos(DSDM) es aplicable al campo de la bioinfor-mática ya que la estructura de los datos bioló-gicos se puede expresar mediante modelos deforma muy natural. En el contexto de la bio-informática es común la existencia de fuentesde datos (rellenadas de forma manual) hetero-géneas. Con el objetivo de validar la informa-ción de estas fuentes de datos, se han adap-tado diversos formalismos y herramientas desimulación. El proceso de introducción de da-tos —obtenidos de estas bases de datos— enlas herramientas de validación se realiza tra-dicionalmente de forma manual. Este trabajodescribe cómo se ha resuelto este problema si-guiendo una metodología de DSDM emplean-do transformaciones de modelos. Esto permi-te automatizar el proceso de migración de da-tos, obtener herramientas modulares, aislar elproceso de transformación de datos de los for-matos de persistencia de estos, y disponer deinformación de trazabilidad.
Palabras clave: Desarrollo de Software Di-rigido por Modelos (DSDM), bioinformática,migración de datos.
*Este artículo ha sido financiado por el ProyectoNacional de Investigación Científica, Desarrollo e In-novación META TIN2006-15175-C05-01.
1. Motivación.
La práctica tradicional en los estudios cien-tíficos de «experimentación → análisis → pu-blicación» está cambiando a «experimentación→ organización de datos → análisis → publi-cación». Esto se debe a que, hoy en día, losdatos no se obtienen únicamente de experi-mentos, sino que también se obtienen de si-mulaciones. Esta gran cantidad de datos ge-nerados no siempre tiene la misma estructuray puede estar almacecenada en bases de da-tos heterogéneas. Además, el elevado númerode datos requiere el desarrollo de herramientasinformáticas que nos permitan representarlospara analizarlos, y a su vez, realizar otras si-mulaciones con ellos.
En el campo de la bioinformática encontra-mos esta problemática en el análisis y simula-ción de los mecanismos de señales de las cé-lulas (Pathways). Un pathway es un conjuntode reacciones químicas que se producen en elinterior de una célula tras la recepción de unestímulo. En estudios de este tipo se observatanto el rellenado independiente de fuentes dedatos como el desarrollo independiente de he-rramientas de modelado. Por ello, estos datosdeben ser reconvertidos de forma manual paraque puedan ser utilizados en las herramientasde simulación. En un escenario así, disponerde herramientas interoperables es deseable.
delos —DSDM— es una aproximación quepretende dar solución a problemas como és-te. En el DSDM, un modelo es una estructu-ra de datos que puede ser definida medianteun lenguaje de modelado (generalmente llama-do metamodelo). Un modelo permite definir lafuncionalidad, estructura y/o comportamientode un sistema [8] dependiendo del metamodeloutilizado. La utilización de modelos en un pro-ceso de DSDM permite automatizar el desa-rrollo de aplicaciones y su evolución mediantetécnicas de programación generativa [2], comolas transformaciones de modelos y la genera-ción de código.
Este artículo muestra cómo la filosofía deDSDM permite resolver los problemas surgi-dos en el estudio de los caminos de señales enel campo de la bioinformática. Los problemasde interoperabilidad entre aplicaciones puedenabordarse de una manera sistemática, donde(a) el formato de datos puede definirse comoun modelo y (b) los datos se definen como unacolección de objectos que son instancia de lasclases del este modelo. El tratamiento de losdatos desde la perspectiva del DSDM permite(c) el desarrollo de herramientas donde el tra-tamiento de éstos sea independiente de los for-matos de persistencia, obteniendo herramien-tas más modulares. Esto a su vez facilita (d)la automatización en la migración de los datosmediante el uso de técnicas de transformacio-nes de modelos. Todos estos factores reducen elcoste de producción de las herramientas afec-tando de forma directa y positiva en la pro-ductividad de los usuarios/biólogos.
El documento se organiza de la siguientemanera: en el apartado 2 se expone el contex-to biológico, introduciendo las razones por lasque es interesante el estudio de los caminos deseñales (pathways), y se describe la aproxima-ción actual, en la que esto es un proceso pocoeficiente. El apartado 3 introduce las bases deldesarrollo dirigido por modelos y la tecnolo-gía empleada para llevar a cabo la migraciónde datos. En el apartado 4 se describe la so-lución diseñada para resolver las deficienciasde la aproximación actual, y por último en elapartado 5 se exponen las conclusiones finalesy trabajos futuros.
Las reacciones químicas involucradas en unpathway suelen ser un proceso en cascada, pro-duciéndose entonces reacciones de forma con-currente. Por ello, para el modelado y análisisde estos procesos biológicos se han adaptadoy aplicado algunos de los formalismos desa-rrollados para el análisis de sistemas concu-rrentes. Ejemplo de ello son aproximacionesen π-cálculo [12], ambient calculus [11], LifeSequence Charts (LSCs) [3] o redes de Petri[7].
El caso de estudio parte de los trabajos rea-lizados por Taübner et al. [13], donde se hamodelado, simulado y validado el pathway delreceptor de tipo toll 4 (TLR4) —que se intro-duce en el siguiente punto— mediante redes dePetri coloreadas. A continuación se expone enprimer lugar el contexto biológico describien-do el problema abordado en [13] y en segundolugar se describen los detalles tecnológicos deéste: fuente de datos y herramienta de simu-
1Un estímulo puede ser, por ejemplo, la presenciade una determinada molécula en el entorno de la cé-lula.
lación seleccionadas y proceso de extracción ytratamiento de los datos.
2.1. Los receptores de tipo Toll. El path-way TLR4.
Los receptores de tipo Toll —Toll-like recep-tors (TLR)— son una familia de proteinas queforman parte del sistema inmunitario. Permi-ten la adaptación del sistema inmune de diver-sos seres vivos siendo responsables del recono-cimiento de diversos patrones (secuencias demoléculas) que identifican a diferentes patóge-nos. Una vez reconocido el patógeno (cualquierentidad biológica capaz de producir daño) es-timulan la respuesta de defensa contra él porparte del sistema inmunitario.
Actualmente se han identificado trece recep-tores de tipo Toll en humanos (TLR1-TLR13).Estos receptores reconocen moléculas que es-tán constantemente asociadas a amenazas con-tra el sistema inmune y que son muy especí-ficas a estas amenazas, no pudiendo confun-dirlas con moléculas propias. Algunas de es-tas moléculas específicas pueden ser los lipo-polisacáridos (LPS) presentes en la superficiede células bacterianas, proteínas presentes enlos flagelos de bacterias, ARN de doble cadenapresente en virus, etc.
Para el caso de estudio, por simplicidad,se toma como ejemplo una pequeña parte delpathway en el que interviene el receptor de tipoToll 4 —TLR4—, por ser el primero reconoci-do en mamíferos y el mejor estudiado hasta elmomento. A continuación se indican las reac-ciones que serán transformadas en el caso deestudio.
La notación expresa a la izquierda los reac-tivos y a la derecha los productos. El símbolo«�» expresa que esta reacción es bidireccio-nal, ya que se trata de una reacción de equi-librio químico —informalmente se puede des-cribir como una reacción que se mantiene has-ta que los reactivos y los productos alcanzanun estado de equilibrio, no llegándose a consu-mir ninguno de los dos—. Para (1), por ejem-
plo, podríamos expresar de forma sencilla losiguiente: la mólecula LPS se une a la molécu-la LBP, dando lugar a la molécula compuestaLPS:LBP.
2.2. Aproximación actual en el estudio delpathway del TLR4 en bioinformática.
kens). La figura 1 muestra un ejemplo de redde Petri, donde los círculos blancos son los lu-gares, el rectángulo relleno de color negro esuna transición, las flechas son los arcos dirigi-dos, y los puntos negros, los tokens.
(a) Estado inicial (b) Estado final
Figura 1: Ejemplo de red de Petri.
Una red de Petri coloreada es aquella en laque los tokens pueden tener un determinadocolor (esto es, algún atributo distintivo), pu-diendo caracterizar tokens de diferentes tipos.CPN Tools es una herramienta que permite laconstrucción, modificación y validación sintác-tica de redes de Petri coloreadas de forma grá-fica. Dispone además de un simulador (tantointeractivo como automático) para poder ins-peccionar la evolución de estos modelos.
La Ingeniería Dirigida por Modelos es un cam-po en la Ingeniería del Software que, duranteaños, ha representado los artefactos softwarecomo modelos con el objetivo de incrementarla productividad, calidad, y reducir los gastosen el proceso de desarrollo de software. Re-cientemente, existe un interés creciente en este
campo. Prueba de ello es la aproximación deModel Driven Architecture [8], apoyada por laOMG.
El Desarrollo Dirigido por Modelos ha evo-lucionado del campo de la Ingeniería Dirigidapor Modelos. En él, no sólo las tareas de dise-ño y generación de código están involucradas,sino que también se incluyen las capacidadesde trazabilidad, tareas de meta-modelado, in-tercambio y persistencia de modelos, etc. Pa-ra poder abordar estas tareas, las operacionesentre modelos, transformaciones, y consultassobre ellos son problemas relevantes que de-ben ser resueltos. En el contexto de MDA seabordan desde el punto de vista de los están-dares abiertos. En este caso, el estándar Me-ta Object Facility (MOF) [10], proporciona unmecanismo para definir metamodelos. El es-tándar Query/Views/Transformations (QVT)[9] indica cómo proporcionar soporte tanto pa-ra transformaciones como para consultas. Adiferencia de otros lenguajes nuevos, QVT seapoya en el ya existente lenguaje Object Cons-traint Language (OCL) para realizar las con-sultas sobre los artefactos software.
3.1. MOMENT. Un framework para laGestión de Modelos.
MOMENT [1] es una herramienta que da so-porte a los estándares propuestos por el OMGpara dar soporte a transformaciones. La herra-mienta proporciona un soporte algebraico pa-ra las tareas de transformación y consulta demodelos mediante un eficiente sistema de rees-critura de términos —Maude— y desde un en-torno de modelado industrial —Eclipse Mode-ling Framework (EMF)—. EMF [5] puede servisto como una implementación del estándarMOF, y permite la importación automáticade artefactos software desde orígenes de datosheterogéneos: modelos UML, esquemas XML,etc. Respecto a Maude, MOMENT aprovechalas capacidades de modularidad y parametri-zación de este sistema para proporcionar unentorno de transformación y consulta de mo-delos de forma genérica e independiente de me-tamodelo.
Como lenguaje para transformaciones MO-MENT se apoya sobre el estándar abier-
to QVT, proporcionando una implementacióntanto del lenguaje QVT-Relations como deOCL. QVT-Relations es un lenguaje de trans-formaciones declarativo que proporciona deforma implícita capacidades de trazabilidad.Para este lenguaje, MOMENT ofrece un am-plio soporte para transformaciones unidirec-cionales 1-a-1. Además, esta herramienta pro-porciona una completa implementación de losoperadores de consulta del lenguaje OCL.
4. Un enfoque de DSDM en la mi-gración de datos biológicos.
A continuación se presenta la solución pro-porcionada. En primer lugar, se describe elproceso de transformación y sus etapas, en se-gundo lugar se describen los modelos del do-minio origen y el modelo destino, y por últi-mo, se describe en mayor detalle el proceso detransformación.
4.1. Arquitectura e implementación de laherramienta.
El proceso de migración de datos, tal y comose deriva de las tareas anteriores, se realiza en
tres pasos: (1) recuperación y pre-procesadode los datos, (2) ejecución de la transforma-ción mediante un motor de transformacionesy (3) post-procesado y persistencia de los da-tos. En una aproximación de DSDM, el usode un motor de transformaciones implica quese deben definir en primer lugar los modelosorigen y destino de la transformación para po-der establecer las correspondencias entre unoy otro posteriormente.
La solución aquí presentada hace uso deMOMENT. MOMENT es una herramienta in-tegrada en el entorno Eclipse que proporcionasoporte para transformaciones. Como entornode modelado, MOMENT emplea el EclipseModeling Framework (EMF). Este frameworkproporciona como lenguaje de modelado Eco-re. Además, emplea como formato de persis-tencia XMI. EMF permite –entre otros— lacreación de modelos Ecore a partir de un es-quema XSD. No obstante, los modelos Ecoreobtenidos a partir de esquemas XSD son com-plejos y no siempre representan la semánticade los datos de forma clara. Por ello, se ha de-cidido definir de forma manual los modelos ori-gen y destino, teniendo sólo en cuenta aquellainformación relevante para el caso de estudio.
sencilla en Java ya que la correspondencia delos datos origen con el modelo en EMF es di-recta. La implementación de este primer pasode pre-procesado de los datos es una adapta-ción del trabajo realizado en [15].
Por último, el tercer paso de la migración(3) es de nuevo un proceso trivial en el que sepersisten los datos desde EMF (F) a un fiche-ro XML comprensible por la herramienta CPNTools (G). En este, paso además, pueden rea-lizarse otras tareas de post-procesado, comopor ejemplo, la inclusión de algún algoritmode redibujado (layout) sobre los elementos dela red de Petri.
Coefficient, omitida por motivos de claridad,que contiene un atributo coefficient de tipo en-tero. Estas clases permiten expresar que unamolécula interviene con un cierto coeficiente2
en una reacción, e intentan representar, segúnla expresividad de Ecore, la semántica de unaclase asociación.
La figura 4 muestra el modelo creado pa-ra la herramienta CPN Tools. En este caso,se ha decidido un diseño más alejado del dise-ño conceptual de una red de Petri Coloreada,incluyendo conceptos específicos de la propiaherramienta CPN Tools. Esto se debe a queun diseño así que permite tratar con todos losconceptos interesantes de la herramienta CPNTools desde EMF (color de los elementos grá-ficos y arcos, posiciones, etc.). Además, de es-ta manera el proceso de persistencia al ficheroXML final es trivial, siendo una corresponden-cia 1-a-1.
El modelo —donde la clase raíz es Cpnet—se compone de dos grande bloques de clases:aquellas que cuelgan de Globbox y aquellas quelo hacen de Page. La figura 4 muestra estos dosgrande grupos separados mediante una líneadiscontínua. El primer grupo de clases permi-te representar las declaraciones de la red (co-lores —Color sets—, variables, bloques, etc.).La herramienta permite definir distintos tiposde colores (Color Sets). De todos los tipos queproporciona, por simplicidad (ya que son losúnicos necesarios) sólo se han incluido el Co-lor Set simple «Enumerated» y el Color Setcompuesto «Product».
El segundo grupo de clases (aquellas conte-nidas en el elemento Page) representan a todoslos elementos visuales de la red de Petri co-loreada. Estos elementos visuales heredan to-dos de la clase DiagramElement, y además,pueden estar contenidos en distintos grupos—Group—. Así, dentro de una página pode-mos encontrar lugares —Places—, transicio-nes —Trans—, arcos —Arcs—, anotaciones—Annot—, etc. Por su parte, se dice que loslugares que se han definido son de un tipo (co-
2El coeficiente representa el número de molécu-las que aparecen en la ecuación de una reacción. Porejemplo, en la reacción 2H2 + O2 = 2 H2O, los coe-ficientes son los números que aparecen a la izquierdade las móleculas H2 y H2O.
lor) que debe haber sido definido en las de-claraciones (mediante el rol type desde la clasePlace a la clase ColorSet). Las clases InitMarky Mark permiten representar el estado de undeterminado lugar, indicando los tokens quese encuentran en éste. El tipo de estos tokensviene dado por el rol colorSetElement entre lasclases Mark y ColorSetElement.
El lenguaje con el que se expresan lasrelaciones entre ambos dominios es QVT-Relations, que se describe de forma breve acontinuación. En QVT-Relations, una trans-formación son un conjunto de relaciones esta-blecidas entre los dominios participantes en latransformación que deben cumplirse para queésta sea satisfactoria [9]. Un dominio es unavariable tipada que puede corresponderse conalgún elemento del modelo que va a transfor-marse. Éste puede tener un patrón, que puedeconsiderarse como un conjunto de restriccio-
Tabla 1: Correspondencias entre el dominio origeny el dominio destino.
nes que deben cumplir los elementos del mo-delo candidato —modelo sobre el que se aplicala transformación— para que se trate de unacorrespondencia válida.
Los dominios además, pueden caracteri-zarse mediante el uso de las palabras cla-ve checkonly y enforce. Para un dominiocheckonly, la transformación comprobará queexiste una correspondencia válida —que sa-tisfaga el patrón del dominio— en el modelocandidato. En caso de que el dominio destinosea enforce, si al ejecutar la transformaciónno existe ninguna correspondencia posible, secreará un elemento que cumpla con el patróndel dominio.
La relación ReactantsToPlaces, muestra unejemplo de la sintaxis para la definición derelaciones y dominios. Esta relación estable-ce la correspondencia entre una molécula yun lugar. Encontramos dos dominios: tpDo-
enforce domain cpnDomain place1 : Place{ id = molecName1 };
//...when
{ IsSimpleMolecule(molecule1); }where
{ ReactantsToArcs(molecule1,place1,...); }}
Regla 1: Regla ReactantsToPlaces.A la aplicación de una regla pueden añadír-
sele pre- y post-condiciones mediante el usode las cláusulas when y where. Por ejemplo,la regla ReactantsToPlaces sólo se aplicará encaso de que la molécula sea de tipo simple —IsSimpleMolecule(. . . ) es una función que me-diante una expresión OCL comprueba si la mo-lécula es simple o compuesta—. La cláusula
where establece que tras la aplicación de la re-lation se procederá a la ejecución de la reglaReactantsToArcs.
El proceso de transformación completo serealiza de arriba a abajo, navegando el mo-delo origen a través de las relaciones de con-tención, definidas como asociaciones de com-posición. Esto es, se parte del elemento raízdel modelo origen (Network), y se navega ha-cia abajo (Network → Pathways → Chains →Reactions → Coefficients →Molecules) crean-do en el modelo destino los elementos corres-pondientes, tal y como expresa de forma resu-mida la tabla 1.
Para las declaraciones, la transformacióncreará un ColorSet de tipo Enumerated a par-tir de cada molécula simple. A partir de lasmoléculas complejas se crearán los ColorSetde tipo Product, y que estarán formados porlos Enumerated ColorSets correspondientes alas moléculas simples que los forman.
Para los elementos visuales se parte de unobjeto de tipo Reaction. Para cada reacción,se crea un objeto de tipo Trans. Navegandoel rol reactantsCoefficient de la clase Reactionse obtienen los reactantes. Para cada uno deellos, se crea un objeto Place. Por último ya esposible enlazar cada place recién creado con el
Figura 5: Representación parcial del Pathway del TLR4 en CPN Tools.
elemento Trans correspondiente mediante unarco —Arc— de tipo PtoT (Place to trans, se-gún la terminología de CPN Tools). Para losproductos de la reacción se procede de formasimilar, en este caso navegando el rol produc-tsCoefficient. Como resultado del proceso detransformación podemos observar la figura 5,que muestra la representación de las reaccionesdel caso de estudio en CPN Tools. En la figu-ra se pueden observar cuatro triángulos nume-rados. Cada triángulo encierra los elementosgenerados para la reacción identificada con elmismo número. De esta manera, para la reac-ción (1) —LPS + LBP � LPS:LBP—, se hangenerado los elementos dentro del triángulo iz-quierdo (1). De igual manera ocurre con lostriángulos 2, 3 y 4, que se corresponden conlas consiguientes reacciones.
El código completo de la transformación ylos ficheros de ejemplo se encuentran en [6].
5. Conclusiones y trabajos futuros.
En este artículo se ha presentado un caso deestudio en el cual se aborda un problema de in-teroperabilidad entre aplicaciones en el campode la bioinformática mediante un enfoque diri-gido por modelos. En este entorno es común laexistencia de fuentes de datos y herramientasde simulación heterogéneas, y la natural repre-sentación de los datos biológicos como mode-los permite abordar estos problemas desde unpunto de vista más eficiente (acortando el ciclode vida del desarrollo de software) y más ele-
gante (puesto que las operaciones se realizancon un lenguaje más expresivo dada su natu-raleza declarativa).
El trabajo pesenta como ventajas frente alas aproximaciones tradicionales (1) la auto-matización de tareas que anteriormente se rea-lizaban de forma manual; (2) el desarrollode herramientas modulares, independizando elmecanismo de transformación del formato depersistencia de los datos y facilitando la ex-tensibilidad y mantenibilidad. (3) Aprovechalas ventajas de las transformaciones de mo-delos. El uso de modelos para representar losdatos a ser transformados permite represen-tar de forma más clara la estructura de éstos,siendo más intuitiva su manipulación ya quese trabaja con conceptos de alto nivel. (4) Seproporcionan capacidades de trazabilidad deforma implícita, ayudando a la localización deinformación errónea en los orígenes de datos.Por último, (5) el uso de un lenguaje comoQVT-Relations ofrece como ventaja (frente alas aproximaciones imperativas tradicionales)que permite expresar de forma declarativa —ypor tanto más descriptiva— las corresponden-cias entre los dominios origen y destino.
Futuras líneas de investigación de esta apro-ximación dirigida por modelos para el desarro-llo de aplicaciones en bioinformática van di-rigidas en dos direcciones. En primer lugar,la representación de los datos biológicos co-mo modelos permiten el aprovechamiento delos nuevos frameworks para la generación demetáforas visuales a partir de éstos, como es
el caso de GMF [4] o MS DSL Tools. Por otraparte las investigaciones en ingeniería dirigi-da por modelos pueden proporcionar un ricobackground tecnológico no únicamente para latransformación de datos de un dominio a otro,sino para tareas como la integración de estosobtenidos desde orígenes heterogéneos.
6. Agradecimientos
Agradecemos al Prof. Dr. H.D. Ehrich y M.Ziegler del Institut für Informationssyeteme dela Technische Universität Carolo-Wilhelminazu Braunschweig, su apoyo, colaboración y ex-periencia aportados en el desarrollo de estetrabajo. Igualmente agradecemos su duro tra-bajo a Pascual Queralt como soporte en el usode MOMENT-QVT.
Referencias
[1] A. Boronat, J. Iborra, J. Ángel Carsí,I. Ramos, and A. Gómez. Del método for-mal a la aplicación industrial en gestiónde modelos: Maude aplicado a eclipse mo-deling framework. Revista IEEE AméricaLatina, September 2005.
[2] K. Czarnecki and U. W. Eisenecker.Generative programming: methods, tools,and applications. ACM Press/Addison-Wesley Publishing Co., New York, NY,USA, 2000.
[3] W. Damm and D. Harel. LSCs: Breathinglife into message sequence charts. FormalMethods in System Design, 19(1):45–80,2001.
[4] Eclipse Organization. The graphical mo-deling framework, 2006. http://www.eclipse.org/gmf/.
[12] A. Regev, W. Silverman, and E. Y. Shapi-ro. Representation and simulation of bio-chemical processes using the pi-calculusprocess algebra. In Pacific Symposium onBiocomputing, pages 459–470, 2001.
[13] C. Taubner, B. Mathiak, A. Kupfer,N. Fleischer, and S. Eckstein. Modellingand simulation of the TLR4 pathwaywith coloured petri nets. 2006. EMBS’06. 28th Annual International Conferen-ce of the IEEE, pages 2009–2012, August2006.
[14] C. Taubner and T. Merker. Discrete mo-delling of the ethylene-pathway. In IC-DEW ’05: Proceedings of the 21st Inter-national Conference on Data EngineeringWorkshops, page 1152, Washington, DC,USA, 2005. IEEE Computer Society.
[15] M. Ziegler. Implementierung eines Trans-formationsmoduls in Java zur Abbildungvon Signaltransduktions-Instanzen aufCPN-Instanzen. Master’s thesis, Technis-che Universität Braunschweig, Braunsch-weig, Januar 2007.