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.

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 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.

El Desarrollo de Software Dirigido por Mo-

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.

2. Caso de estudio.

Numerosos procesos biológicos son controladospor los denominados mecanismos de señales.Un camino de señales —signaling pathway—es una colección de reacciones químicas quetienen lugar en una célula como reacción a unestímulo1 (generalmente externo) disparandodiversos eventos en el interior de ésta. Estoseventos son los que controlan la progresión delciclo de vida (muerte, crecimiento, especializa-ción), activación o desactivación de genes parael momento de la reproducción, el movimientode la célula, etc. El estudio de estos caminos deseñales se realiza mediante el ensayo empíricode los estímulos externos que recibe una célu-la y recogiendo los datos sobre las reaccionesquímicas desencadenadas en su interior. Estosdatos obtenidos de forma experimental por losbiólogos son almacenados en diferentes basesde datos para su posterior estudio y consul-ta por otros expertos. Existen diversas fuentesdonde es almacenada la información como porejemplo TRANSPATHR©, BioCarta, KEGG oReactome.

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.

1. LPS + LBP � LPS:LBP2. LPS:LBP + CD14 � LPS:LBP:CD143. ST2 + TIRAP � ST2:TIRAP4. ST2 + MyD88 � ST2:MyD88

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.

Son numerosas las fuentes de datos de las quese puede extraer información sobre el path-way del TLR4. Algunas de ellas pueden serTRANSPATHR©, KEGG, Reactome o BioCar-ta. Estas bases de datos han sido rellenadas apartir de estudios empíricos y pueden contenerinformación incompleta e incluso contradicto-ria. Los actuales trabajos para la representa-ción y simulación de pathways se dirigen en larepresentación y simulación de estos pathwayspara poder validar la información obtenida enlos estudios empíricos.

Con ese objetivo se han adaptado diver-sos formalismos gráficos para la simulación depathways biológicos. Ejemplos de ello son losdiagramas de estados [14], los Life SequenceCharts [14, 3], o las redes de Petri colorea-das [13]. El trabajo en el que se fundamentala solución aquí presentada describe un pro-ceso mediante el cual es posible extraer losdatos del pathway TLR4 de la base de da-tos TRANSPATHR© con el objetivo de simu-larlo mediante la herramienta de simulación yvalidación de redes de Petri coloreadas CPNTools.

TRANSPATHR© es una base de datos quealmacena información acerca de caminos deseñales. Permite la exportación de datos enXML, y en su versión 7.4 contiene informa-ción sobre 62.549 moléculas, 23.076 genes y104.362 reacciones. Una red de Petri, por suparte, es una representación formal para unsistema distribuido discreto, que permite re-presentar eventos concurrentes. La red se for-ma por nodos (llamados lugares), transicionesy arcos dirigidos. Estos arcos conectan siem-pre un lugar con una transición o una transi-ción con un lugar. En los lugares puede haberun determinado número de tokens, que pue-den moverse de un lugar a otro cuando unatransición se dispara (una transición se habi-lita cuando todas sus entradas contienen to-

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.

En [13] el método empleado para poder rea-lizar la simulación a partir de los datos alma-cenados en TRANSPATHR© es manual. Estosupone que el usuario/biólogo que va a realizarla simulación debe consultar de forma manualla base de datos obteniendo el listado de reac-ciones que intervienen en el pathway que deseaestudiar. Con los datos obtenidos debe crear yeditar de forma manual la correspondiente redde Petri coloreada en CPN Tools, creando unoa uno cada uno de los lugares, transiciones, ar-cos, tokens, etc. En el trabajo al que se hacereferencia, esto supuso crear de forma manual—y únicamente para el ejemplo del pathwaydel TLR4— 75 lugares, 47 transiciones y casiun centenar de colores.

3. Ingeniería Dirigida por 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.

En el trabajo inicial sobre el estudio del path-way del TLR4 la migración de datos desdela base de datos origen hasta la herramientade simulación para su representación medianteuna red de Petri coloreada debe realizarse deforma manual. A continuación se muestra unasolución al problema de migración de datos delcaso de estudio empleando transformaciones,según la filosofía de desarrollo de software di-rigido por modelos. Esto supone las siguientestareas: (a) desarrollo del modelo de datos deldominio origen (TRANSPATHR©) y (b) desa-rrollo del modelo de datos del dominio destino(CPN Tools). (c) Definición mediante un len-guaje de transformaciones las reglas de trans-formación entre el dominio origen y el dominiodestino; (d) implementación del mecanismo depreprocesado de datos permitiendo reconstruirlos datos originales como instancias del mode-lo origen, y (e) definición del postprocesadode los datos, que implementa el mecanismo depersistencia al formato final.

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.

Figura 2: Arquitectura de la herramienta.

La figura 2 muestra la arquitectura de laherramienta. En ella se reflejan de forma claralos 3 pasos necesarios para realizar la migra-ción de los datos. En primer lugar se extraenlos datos de la base de datos TRANSPATHR©

(A), y se reconstruyen como una instancia enXMI (B) del modelo Ecore de TRANSPATHR©

(C). Este primer paso (1) se realiza de forma

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].

El segundo paso de la migración (2) es elprincipal y más complejo. Se realiza medianteMOMENT y su motor de transformaciones,ejecutando la transformación del dominio deTRANSPATHR© (reacciones, moléculas, etc.)al dominio de CPN Tools (lugares, transicio-nes, arcos, etc.). Tras la definición de las re-glas de transformación (D) entre los dominiosorigen (C) y destino (E), se aplica la transfor-mación sobre los datos recuperados de la basede datos (B) obteniendo una instancia en eldominio de CPN Tools (F).

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.

4.2. Desarrollo de los modelos.

En primer lugar se ha definido un modelo úni-camente con las partes que resultan de interéspara la simulación de un pathway eliminandolos conceptos innecesarios de la compleja basede datos TRANSPATHR©. La figura 3 mues-tra —mediante una metáfora visual similar aldiagrama de clases de UML— el modelo Ecoredesarrollado. En el modelo encontramos la cla-se Network, elemento raíz del modelo. Una Red—Network— contiene un conjunto de Path-ways, Reacciones y Moléculas. A su vez, unPathway se compone de diversas Cadenas —Chains— de reacciones, y una reacción puedeestar involucrada en diferentes cadenas. Porúltimo, las reacciones se relacionan con las mo-léculas. Una molécula puede ser un reactantede una reacción, puede ser un producto, o pue-de intervenir indirectamente como catalizadoro inhibidor. Las clases ReactantsCoefficient,ProductsCoefficient, EnzymesCoefficient e In-hibitorsCoefficient heredan todas de la clase

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.

Figura 3: Modelo de la base de datos TranspathR©.

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.

4.3. Proceso de transformación.

Finalmente, se han definido las reglas de trans-formación que permiten convertir los datos deldominio origen al dominio destino. Estas re-glas, expresan las correspondencias estableci-das por los biólogos —cuando construyen unared de Petri coloreada de forma manual— en-tre los datos de TRANSPATHR© y las primi-tivas de la herramienta CPN Tools. La tabla1 muestra de forma simplificada estas corres-pondencias entre el dominio origen y el domi-nio destino.

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-

Transpath CPN ToolsNetwork CpnetPathway Globbox

PageMolecule (complex) ProductMolecule (simple) Enumerated

Reaction TransMolecule (reactant) Place

Arc (de Place a Trans)Molecule (product) Place

Arc (de Trans a Place)

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-

Figura 4: Modelo de la herramienta CPNTools.

main se corresponde con el dominio origen(TRANSPATHR©) y cpnDomain con el domi-nio destino (CPN Tools). Para el dominio tp-Domain se comprueba que exista una molécu-la con un atributo, name, de tipo String. Paracada molécula que cumpla este patrón deberáexistir (y si no existe, se creará) un Place en eldominio destino (cpnDomain), cuyo atributoid contenga el nombre de dicha molécula.relation ReactantsToPlaces {

molecName1 : String;checkonly domain tpDomain molecule1 : Molecule

{ name = molecName1 };

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/.

[5] EMF. http://download.eclipse.org/tools/emf/scripts/home.php.

[6] A. Gómez. Ficheros de ejemplo para elcaso de estudio, 2007. http://moment.dsic.upv.es/jisbd07/files/.

[7] M. Heiner, I. Koch, and K. Voss. Analysisand simulation of steady states in meta-bolic pathways with petri nets, Aug. 022001.

[8] Object Management Group. MDA Gui-de Version 1.0.1. 2003. http://www.omg.org/docs/omg/03-06-01.pdf.

[9] Object Management Group. MOF 2.0QVT final adopted specification (ptc/05-11-01). 2005. http://www.omg.org/cgi-bin/doc?ptc/2005-11-01.

[10] Object Management Group. Meta Ob-ject Facility (MOF) 2.0 Core Specification(ptc/06-01-01), 2006. http://www.omg.org/cgi-bin/doc?formal/2006-01-01.

[11] Regev, Panina, Silverman, Cardelli, andShapiro. Bioambients: An abstraction forbiological compartments. TCS: Theoreti-cal Computer Science, 325, 2004.

[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.