Dna Chip online R using Mango
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
dna Chip online R using Mango
L’HOSTIS-JACQUEMIN Yoan
Janvier - Juin 2007
Laboratoire d’accueil : Biologie Fonctionnelle Insectes et Interactions (BF2I)
IFR41 - UMR INRA/INSA de Lyon 203
Maı̂tre de stage : Hubert CHARLES
Master approches Mathématiques et Informatiques du Vivant - M1
1TABLE DES MATIÈRES
Table des matières
1 Abstract 3
2 Introduction 4
3 Matériels et méthodes : choix technologiques 7
3.1 Logiciels utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Structure de la Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Schéma général de fonctionnement . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Jeu de données test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Résultats : présentation de l’outil 12
4.1 Instanciation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Interface débutant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Interface avancée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Interface administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Discussion 17
6 Conclusion et Perspectives 18
21 ABSTRACT
1 Abstract
Amount of data in biology increased a lot since discovery like DNA Chip or other high-
throughput technologies. In order to accurately process this kind of massive datasets, new
and sometimes harder-to-understand statistical analyses have been developped. The goal
of my training was to create a web-tool able to perform this kind of analysis with several
specific goals to achieve :
– A two-way interface allowing to switch easily between Beginner and Advanced Mode.
The beginner mode should be designed for biologists, neither R-knowledge nor pro-
gramming should be required, whereas the advanced mode should be designed for
people with bioinformatics knowledge, knowing R-programming and willing to tweak
it to better match their data.
– An history allowing to come back and forth between achievied steps.
– The possibility to load a former analysis.
– An evolutive design and a clean code for easy-improving.
dCoRum uses PHP5, postgreSQL and R (improved by Bioconductor, several R packages
designed to analyse microarrays, and Mango an interactive R script wich guide users
through the whole analysis). Every steps (including informations, help and R code) are
stored in the database (actually a methodbase) and dynamically displayed on screen.
The database follows a nested design, meaning each element is included within ano-
ther : main steps contains main steps picts and methods which contains sub steps which
contains sub steps picts and params (short for parameters). One of the advantages of dCo-
Rum is the continuity of the R process, meaning there is no wasted time in data-loading
between each step. Another is there’s help almost everywhere, on steps, on methods, on
pictures, on parameters and so on. Furthermore it’s also easy to manage and improve
dCoRuM thanks to a web interface allowing to create/copy/edit and delete every element
in the database. Furthermore the nesting of elements is easy to catch thanks to color
code. dCoRuM encodes the 3 first steps of classical DNA chip analysis (Instanciation,
Background substract and Filtration), and short-end prospects will be to add classical
statistics like anova and classification. In the future, dCoRuM should be available on the
PRABI website and open to the community.
32 INTRODUCTION
2 Introduction
La recherche en biologie a subi ces dernières années de profonds bouleversements, en
partie dus au développement de nouvelles techniques, dites à haut-débit, telles que les
puces à ADN. Ces techniques permettent de quantifier l’expression de plusieurs milliers
de gènes en une seule analyse et ont ouvert la voie à de nouvelles façons d’envisager cer-
taines problématiques biologiques comme en biologie des systèmes (Newman et Weissman,
2006). Par exemple, l’expression différentielle des gènes suivant l’état de la cellule, suite
à des variations environnementales ou encore au cours de l’avancement d’une maladie,
peut maintenant être analysée globalement. Cependant, la quantité de données obtenue
grâce à ces techniques nécessite de développer de nouvelles méthodes de représentation et
des analyses statistiques parfois complexes pour répondre à la problématique biologique
analysée avec un risque d’erreur connu et acceptable (Churchill, 2002; Dudoit et al., 2002).
Schématiquement le processus d’analyse d’une expérience de puce à ADN comprend les
étapes suivantes :
1. Préparation du jeu de lames, dépots ou synthèse des sondes sur le support.
2. Préparation des ARNm ou des cDNA issus des échantillons biologiques et marquage
(fluorescent ou radioactif).
3. Hybridation (souvent en deux couleurs : rouge et vert).
4. Lavage des lames et acquisition via un scanner au format TIFF de l’image de la
lame.
5. Analyse de l’image, détection du signal, du bruit de fond et calibrage des spots.
6. Analyse qualité des lames et filtration des spots.
7. Moyennage des intensités et élimination du bruit de fond.
8. Analyse statistique :
– Détection de gènes candidats (exprimés différentiellement) ;
– Classsification ;
– Recherche de profil d’expression.
9. Intégration des données d’expression dans le contexte biologique.
42 INTRODUCTION
Le but de mon stage fut de développer une application web permettant d’analyser statis-
tiquement des puces à ADN (étapes 6 à 8) via le logiciel de statistiques R agrémenté des
librairies du projet bioconductor (Gentleman et Carey, 2004). Ce travail faisait suite à
un prototype créé par une équipe de stagiaires de troisième année de L’INSA de Lyon du
département Biosciences (Defay et al., 2006). De plus, j’ai eu la chance d’obtenir une ver-
sion d’un script R développé par l’équipe Bioinfome du Génopole d’Orsay appelé Mango
(Mucchielli et Marisa, 2006). Ce script code toute la partie initiale du processus d’analyse
et m’a ainsi permis de gagner beaucoup de temps au niveau de la programmation R de ce
processus.
Le cahier des charges de cette application web fut le suivant :
– Création d’une interface proposant 2 modes d’utilisation pour des publics différents.
Un mode d’utilisation opaque pour les débutants, guidant l’utilisateur sur les dé-
cisions à prendre en fonction des résultats affichés essentiellement sous forme de
graphes ; ceci sans interaction avec le processus R fonctionnant en arrière-plan. Ce
mode est principalement à destination des biologistes ne maitrisant pas ou peu les
techniques statistiques. Ainsi qu’un mode d’utilisation transparent pour les utili-
sateurs avancés, permettant à l’utilisateur de visionner les sorties R ainsi que les
erreurs et de modifier le code R qui va être exécuté sur le serveur. Ce mode est plu-
tôt à destination des bioinformaticiens qui désireraient améliorer l’adéquation entre
le code exécuté et leurs données ou bien obtenir des informations non disponibles
dans l’analyse par défaut de l’application.
– Un historique permettant d’effectuer des va-et-vient entre les différentes étapes lors
du déroulement de l’analyse.
– La possibilité d’effectuer cette analyse en plusieurs fois en reprenant à la dernière
étape effectuée.
– Une gestion des étapes la plus modulaire possible afin de pouvoir faire évoluer l’outil
facilement, ainsi qu’un code le plus clair possible, le but étant de faire reprendre
sinon le site au moins le concept par l’équipe du PRABI (Pôle Rhône-Alpes de
Bioinformatique) ce qui permettrait de l’offrir à la communauté scientifique.
52 INTRODUCTION
– Dans le même but, une interface sobre (accordée à la charte graphique du PRABI)
et en langue anglaise pour une portée internationale.
Fondamentalement, il s’agissait ici de créer une base de méthodes permettant de réali-
ser les différentes étapes d’une analyse statistique de puces à ADN avec R. Cependant,
dans le cadre de ce travail de première année de master, nous avons choisi de privilégier
la simplicité de l’architecture et de la programmation requise plutôt que de réaliser une
base de méthodes telle qu’elle peut être définie en ingénierie des méthodes (Rolland, 2005).
Après avoir présenté les choix technologiques réalisés, autant au niveau des logiciels utilisés
que de l’organisation de la base de méthodes, je présenterai l’interface du site web réalisé
ainsi que la page d’administration permettant la gestion des méthodes. Cette partie sera
suivie par une analyse critique du travail réalisé et de ses améliorations possibles, pour
terminer par une conclusion et les perspectives du projet.
63 MATÉRIELS ET MÉTHODES : CHOIX TECHNOLOGIQUES
3 Matériels et méthodes : choix technologiques
3.1 Logiciels utilisés
PHP (PHP : Hypertext Preprocessor) est un langage de scripts généraliste et Open
Source, spécialement conçu pour le développement d’applications web. C’est un lan-
gage fonctionnant côté serveur, c’est à dire que le code est exécuté sur le serveur et
renvoie, généralement, du code HTML qui sera affiché sur l’ordinateur client. Dans
le cadre du projet, il permet de faire le lien entre la base de méthodes, l’interface
web et le processus R fonctionnant en tâche de fond.
PostgreSQL est un système de gestion de base de données relationnelle et objet (SGB-
DRO). C’est un outil libre disponible selon les termes d’une licence de type BSD.
Dans le cadre du projet, il permet de stocker les méthodes, i.e., les informations
pour chaque étape, telles que le code R à exécuter, les images associées, l’aide, mais
aussi le cheminement logique de l’analyse.
R est un système d’analyse statistique et graphique (R Development Core Team, 2006)
correspondant à la fois au nom d’un langage de programmation dérivé du S (créé
par AT&T Bell Laboratories) et au logiciel permettant son interprétation. R est
distribué librement sous la licence GNU-GPL, son développement et sa distribution
étant assurés par la communauté scientifique et plus particulièrement par la ”R De-
velopment Core Team”. Les fichiers et les explications pour installer R, à partir du
code source ou des exécutables, sont distribués à partir du site internet du Compre-
hensive R Archive Network (http ://cran.r-project.org). Dans le cadre du projet, il
est utilisé conjointement avec les librairies Bioconductor et Mango afin d’effectuer
les analyses statistiques.
Mango est un script R interactif qui propose de visualiser, normaliser et d’analyser les
données de puces à ADN. C’est un script qui fonctionne en suivant un cheminement
relativement fixé. Il apporte aussi, grâce à son package R associé, de nombreuses
fonctions pour améliorer les fonctions présentes dans les librairies bioconductor. Il
a été développé à la Génopole d’Orsay au sein de l’équipe Bioinfome (Mucchielli et
Marisa, 2006).
73 MATÉRIELS ET MÉTHODES : CHOIX TECHNOLOGIQUES
Bioconductor est un ensemble de projets Open Source concernant la bioinformatique
(Gentleman et Carey, 2004). A l’origine, ces projets étaient concentrés sur l’ana-
lyse de puces à ADN via R. Cependant avec le succès croissant de cette initiative,
de nombreux packages R ont été développés dans divers domaines d’applications
bioinformatiques.
3.2 Structure de la Base
La base de méthodes présente une structure imbriquée, c’est-à-dire que chaque élé-
ment est contenu dans un autre, chaque type d’élément ayant sa propre table ainsi que
des champs qui lui sont propres. Le découpage est le suivant : les main steps (étapes
principales) contiennent des main steps picts (images d’étape principale) ainsi que des
methods (méthodes), elles-mêmes découpées en sub steps (sous-étapes) contenant des
sub steps picts (images de sous étape) ainsi que des params (paramètres).
La figure 1 propose une représentation complète de la base de méthodes, avec la descrip-
tion de chacun des champs des tables disponibles. Le code couleur utilisé ici, permettant
de distinguer plus facilement les différents niveaux hiérarchiques, est le même que celui
utilisé dans la page d’administration détaillée dans la partie Résultats.
Chacune des tables contient un identificateur unique afin d’établir des relations entre
elles sans ambiguité, ainsi qu’une aide associée à l’élément considéré. Les spécificités du
SGBD postgreSQL (ceci n’étant plus une exclusivité depuis la sortie de mySQL5) ont per-
mis de garantir l’intégrité de la base de méthodesde en établissant des liens entre les tables
via des clés étrangères. Par exemple, il n’est possible de relier une main steps picts qu’à
une main steps existante. De plus lors de la modification/suppression de cette main steps,
les main steps picts associées seront automatiquement modifiées/supprimées.
89
3 MATÉRIELS ET MÉTHODES : CHOIX TECHNOLOGIQUES
Fig. 1 – Description des différents champs de la base de méthodes de dCoRuM3 MATÉRIELS ET MÉTHODES : CHOIX TECHNOLOGIQUES
3.3 Schéma général de fonctionnement
dCoRuM est une application web qui utilise principalement 4 langages de programma-
tion, son processus peut donc être découpé en 4 couches en interaction (Fig. 2) : la couche
en HTML, permet à l’utilisateur de choisir les actions à réaliser et de visualiser les retours
de la couche PHP. La couche PHP, permet la prise en compte des choix de l’utilisateur,
communique avec les couches R et/ou SQL pour leur indiquer les actions à réaliser et met
en forme les retours de ces 2 couches. La couche SQL, fournit les informations demandées
par la couche PHP et modifie la base de méthodes suivant les instructions de la couche
PHP. Et finalement la couche R exécute les traitements demandés par la couche PHP et
lui retourne les résultats.
Fig. 2 – Interactions entre les différentes couches de dCoRuM
103 MATÉRIELS ET MÉTHODES : CHOIX TECHNOLOGIQUES
Au début de l’analyse, lors de l’instanciation des données, un processus R unique et
identifiable est lancé via la fonction start R. Cette fonction lance PHP5 en ligne de com-
mande afin de lancer le processus R en arrière-plan. Il est indispensable de passer par la
ligne de commande car elle seule permet de lancer un script PHP avec une durée d’exécu-
tion indéfinie. De plus, ce script PHP permet de spécifier les redirections vers des fichiers
des sorties R que ce soit pour la sortie standard, ou la sortie des erreurs.
Par la suite l’affichage alterne entre les pages de main/sub steps pour récupérer les com-
mandes de l’utilisateur. Ces deux pages sont codées de manière générique afin d’afficher
n’importe quel main/sub step correctement par rapport aux informations disponibles dans
la base de données et récupérer de façon adéquate les décisions de l’utilisateur.
Ces commandes sont ensuite transférées au processus R grâce à la fonction execute R après
vérification du code pour éliminer la possibilité d’exécution de commandes dangereuses
pour la sécurité du serveur (Pontillo et Mineo, 2005). Cette fonction permet de détecter
tout plantage du processus R, ainsi que la fin de l’exécution du bloc de commandes R.
Puis un .Rdata est créé et la page suivante dans le cheminement logique est affichée à
l’écran de l’utilisateur.
3.4 Jeu de données test
Le jeu de données que j’ai utilisé lors de mes test de dCoRuM provient d’une étude
réalisée par John Bermingham et Tom Wilkinson (Université de Dublin) portant sur les
différences entre les Buchnera issues de bactériocytes maternels et de bactériocytes d’em-
bryons à 3 stades de développement différents : small, medium and large. Buchnera est
une bactérie symbiotique intracellulaire vivant à l’intérieur des pucerons. Les bactériocytes
sont les cellules du puceron spécialisées dans l’hébergement de la bactérie symbiotique.
Le jeu de données comporte 21 lames, il est hybridé en double couleur (rouge et vert) et
chaque lame porte 6144 spots (Calevro et al., 2004).
114 RÉSULTATS : PRÉSENTATION DE L’OUTIL
4 Résultats : présentation de l’outil
Dans cette partie, je vais décrire les différentes pages de dCoRuM que les utilisateurs
débutants, avancés et administrateurs pourront rencontrer lors de l’utilisation de cet outil.
4.1 Instanciation des données
Fig. 3 – Page d’instanciation des données. (1) Barre de menu ; (2) envoi des fichiers de données ; (3) informations sur les
données.
La page d’accueil de dCoRuM permet de commencer une analyse en remplissant les
différents champs d’informations ou de continuer une analyse entamée. On peut découper
cette page en plusieurs zones : Tout d’abord en haut de la page (Fig. 3,1) se trouve le
bandeau de menu, proposant de recharger une analyse à partir de son numéro unique et
dans le futur le menu dynamique permettant de naviguer entres les étapes. Dans le corps
de la page, on trouvera deux zones, la première (Fig. 3,2) permettant de sélectionner
les fichiers utilisés pour l’analyse : les fichiers gpr contenant les informations d’intensité
des spots, le fichier de targets (permettant d’ordonner les lames, de les renommer et de
définir le plan d’expérience) le fichier de spottypes (permettant de catégoriser les spots à
partir d’expression régulières telles que témoins positifs, négatifs etc.) et éventuellement
un fichier “.gal” apportant des informations optionnelles sur les spots. La deuxième zone
(Fig. 3,3) permet de spécifier les noms des différentes colonnes des tableaux gpr qui seront
utilisées par R pour les analyses ainsi que diverses informations telles que le nombre de
blocs par lame ou le type d’expérience.
124 RÉSULTATS : PRÉSENTATION DE L’OUTIL
4.2 Interface débutant
Après avoir instancié les données, l’utilisateur accède à une page de visualisation des
données, permettant de vérifier que l’instanciation s’est correctement déroulée et de vi-
sualiser quelques graphiques basiques (données non présentées).
Fig. 4 – Copie d’écran d’une page type d’affichage d’étape de dCoRuM (ici, la soustraction du bruit de fond).
A partir de cette étape, les pages affichées seront organisées de la manière suivante : en
haut de la page s’ajoute deux liens (Fig. 4,1) : le premier permettant de se déconnecter tout
en affichant le numéro unique de l’analyse en cours, et le second permettant de récupérer
une archive au format zip contenant l’ensemble des fichiers générés. En dessous (Fig. 4,2)
est rappelée la position actuelle dans le processus d’analyse, c’est à dire le main step
et le sub step actuel. Le reste de la page est découpée en plusieurs zones : la première
(Fig. 4,3) affichant les images associées à cette étape, i.e., dont les noms correspondent
au masque défini dans la base de données, suivie par l’aide associée à cette étape (Fig.
4,4). En dessous (Fig. 4,5) se trouve la zone permettant d’afficher diverses informations
sur le processus R, dont la description détaillée sera faite dans le §4.3. Au bas de la page
(Fig. 4,6) se trouve la zone permettant la navigation entre les étapes : tout d’abord le
lien permettant d’afficher l’historique des étapes, puis un bouton permettant de revenir à
l’étape précédente et enfin une zone permettant de choisir entre les méthodes implémentées
ou de spécifier des paramètres avant de passer à l’étape suivante.
134 RÉSULTATS : PRÉSENTATION DE L’OUTIL
Fig. 5 – Exemple d’affichage des boites utilisées par dCoRuM. (1) Aide sur les méthodes. (2) Historique.
La grande majorité des liens disponibles sur les pages du site sont affichés dans une
boite apparaissant en surimpression au premier plan avec un fond transparent grâce à un
code javascript appelé Lightbox (Dhakar, 2006). Il en est ainsi pour les aides, les diverses
informations portant sur R, ainsi que pour l’historique.
Les boites d’aide (Fig. 5,1) sont générées automatiquement à partir de la base de méthodes.
Des aides sont disponibles sur les images associées à l’étape en cours, sur les différentes
méthodes implémentées et sur les paramètres à spécifier.
L’historique (Fig. 5,2) permet de naviguer entre les étapes sans relancer l’exécution du
code. Les étapes sont présentées avec une indentation permettant de différencier les
main steps des sub steps, de plus l’étape actuellement affichée est signalée par un nom
en caractère gras. Lorsque l’étape affichée n’est pas la dernière exécutée, les étapes inter-
médiaires sont barrées dans l’historique (Fig. 5,2). En effet ces étapes seront supprimées
si l’utilisateur décide de recommencer l’analyse à partir de celle affichée. De plus une
demande de confirmation permet de prévenir un effacement accidentel.
144 RÉSULTATS : PRÉSENTATION DE L’OUTIL
4.3 Interface avancée
Fig. 6 – Copies d’écran des affichages utilisés en mode avancé. (1) les paramètres spécifiés et le code exécuté. (2) le retour
du processus R.
L’utilisateur avancé a la possibilité d’afficher diverses informations sur le processus R.
Il peut afficher le code venant d’être exécuté ainsi que les paramètres actuels, modifier
le code R, afin d’obtenir de plus amples informations ou pour ajuster les paramètres des
fonctions utilisées, ainsi que les paramètres utilisés et relancer l’exécution de ces nouvelles
commandes (Fig. 6,1). Il peut aussi obtenir le retour du processus R (Fig. 6,2), i.e., ce que
R afficherait sur la console lors d’une utilisation normale. Et enfin, il a accès à la sortie
d’erreurs et d’avertissements de R (donnée non présentée).
Il a été décidé de réduire au minimum l’affichage des liens permettant l’accès à ces infor-
mations afin de ne pas surcharger l’interface, mais aussi de ne pas troubler l’utilisateur
débutant en affichant du code R qui lui serait incompréhensible.
154 RÉSULTATS : PRÉSENTATION DE L’OUTIL
4.4 Interface administrateur
Fig. 7 – Page d’administration de la base de méthodes. (1) Imbrication et code couleur de la représentation. (2) Exemple
de page de modification d’un élément
Cette page, dont l’accès est réservé à l’équipe d’administrateurs, fournit un accès com-
plet à la base de données afin de visualiser de manière conviviale l’intégralité de l’arbo-
rescence (Fig. 7,1) mais aussi d’exécuter les actions suivantes :
– Créer un élément de novo.
– Copier un élément déjà existant dans un autre élément de même type.
– Modifier un élément existant (Fig. 7,2).
– Supprimer un élément.
– Visionner les informations et les sous-éléments de cet élément.
Il est relativement facile de repérer à quel niveau de l’arborescence on se trouve grâce au
code couleur. De plus, certains champs ne pouvant pas être remplis lors de la création de
l’élément (par exemple les firststep des methods ainsi que les nextsteps des substeps), des
complétions automatiques ont été mises en place.
165 DISCUSSION
5 Discussion
Bien que le site ne soit encore qu’en version de développement, il permet de réaliser
les premières étapes du processus d’analyse à savoir l’instanciation, la filtration du bruit
de fond et la filtration des spots.
Ces trois étapes ont permis de tester plusieurs fonctionnalités indispensables au bon fonc-
tionnement du processus : la récupération des données et des paramètres fournis par
l’utilisateur et leur instanciation correcte dans le processus R, la création de fichiers de
sorties par R sous diverses formes (textes, images), et le point le plus important, la conti-
nuité du processus entre les différentes pages de l’analyse. En effet l’utilisation de PHP5
(CLI1 ) a permis de dépasser certaines limites des interfaces R existant sur le web telles que
Rweb (Banfield, 1998) ou encore Rphp (Pontillo et Mineo, 2005) qui ne permettent pas de
continuité du processus d’analyse entre les pages. Cette continuité est très intéressante car
elle évite de perdre du temps à recharger le fichier binaire de données (.Rdata) à chaque
nouvelle page, cette opération pouvant se réveler très longue au vu de la taille des jeux
de données à traiter. Ce choix d’architecture permet aussi de s’affranchir de l’utilisation
d’un intermédiaire en CGI2 (Firth et Lang, 2003) ou en Python (XiaoQin Xia et Wang,
2005). Ce système apporte donc une plus grande liberté ainsi, qu’à priori, une plus grande
rapidité d’exécution tout en diminuant la complexité globale de l’outil. Les autres points
du cahier des charges sont, eux aussi, respectés car il est possible de voir et de modifier à la
volée le code exécuté comme expliqué au §4.3 et l’aide à l’utilisateur est omniprésente sans
être envahissante grâce aux Lightbox (Dhakar, 2006). De plus, l’utilisateur peut recharger
une analyse entamée en retrouvant ses données dans l’état de la dernière étape réalisée,
l’historique de l’analyse ainsi que les paramètres qu’il avait spécifiés à chaque étape. Et
enfin, une interface de gestion de la base de méthode est disponible pour l’équipe d’admi-
nistrateurs. Cette interface est simple à utiliser et permet de faire évoluer rapidement la
base des méthodes sans qu’il y ait besoin de s’approprier le code de l’application. Cepen-
dant il convient d’adapter son code R à cette architecture (ex : les images doivent être
enregistrées en jpg et non affichées dans une fenêtre R).
1
Command Line Interace
2
Common Gateway Interface
176 CONCLUSION ET PERSPECTIVES
Malgré ces résultats encourageants, il reste encore à tester dCoRuM sur une plus grande
échelle et à différents niveaux. En effet, la charge imposée au serveur lors d’une utilisation
en parallèle de l’outil par plusieurs utilisateurs, mais aussi lors de travaux sur de plus gros
jeux de données ne sera pas réellement estimable avant des tests en situation réelle. De
plus, des problèmes peuvent apparaitre dans la suite du développement, soit au niveau
du processus d’anayse de Mango, soit au niveau de l’intégration sur un serveur public
(gestion du réseau, de droits ou encore de sécurité).
6 Conclusion et Perspectives
En conclusion, les principaux objectifs définis au début du stage ont été atteints,
en effet le site créé permet une utilisation à deux niveaux suivant les connaissances de
l’utilisateur, une facilité de déplacement dans le cheminement de l’analyse ainsi qu’une
modularité et donc une évolutivité de bonne qualité. De plus l’architecture en base de
méthodes, conférant une orientation objet au processus d’analyse, permet d’envisager une
intégration facile dans des systèmes d’informations plus complets. Par exemple, il pourrait
être intéressant de l’inclure dans un système tel que Genostar (http ://www.genostar.org).
A court terme, on doit envisager les améliorations suivantes : au niveau du code il faudra
ajouter toutes les étapes d’analyse statistiques différentielles et de classification (ANOVA).
Il faudrait aussi améliorer la gestion des plantages du processus R à cause d’erreurs dans le
code à exécuter. De plus, on peut envisager la mise à disposition des utilisateurs de pages
interactives de créations de fichiers de ciblage (targets.txt) et de fichiers de caractérisation
des spots. Ou encore, un menu dynamique permettant l’accès aux étapes en respectant
les pré-requis de celles-ci. A plus long terme, on pourrait envisager de réaliser une base
de méthodes respectant les spécifications de l’ingénierie des méthodes (Rolland, 2005),
bien que cela supposerait la création d’un package R dédié à cette fonction mais pas
nécessairement la réécriture complète de l’outil. Au moment de l’écriture de ce rapport
cet outil n’est pas encore installé sur les serveurs de l’université, faute de compte actif.
Cependant, il devrait être disponible courant juin. A partir de ce moment-là un accès à la
page d’administration sera donné à toute personne désireuse de l’essayer et de l’améliorer
afin de le tester à plus grande échelle et en particulier à l’équipe du PRABI, susceptible
de reprendre et d’améliorer cet outil.
18RÉFÉRENCES
Références
J. Banfield : Rweb : Web based statistical analysis. JSS, 1998. URL
http ://www.jstatsoft.org/v04/i01/Rweb/Rweb.html.
F. Calevro, H. Charles, N. Reymond, V. Dugas, J. Cloarec, J. Bernillon,
Y. Rahbé, G. Febvay et J. Fayard : Assessment of 35mer amino-modified oligonu-
cleotide based microarray with bacterial samples. Journal of Microbiological Methods,
57:207–218, 2004.
G. A. Churchill : Fundamentals of experimental design for cdna microarrays. Nat
Genet, 32 Suppl:490–495, Dec 2002. URL http ://dx.doi.org/10.1038/ng1031.
F. Defay, V. Fasolo, N. Oudin et V. Perie : Rapport interne ;3ème année bim du
département biosciences de l’insa de lyon, 2006.
L. Dhakar : Lightbox js, a javascript to pop-up with transparency, 2006. URL
http ://www.huddletogether.com/projects/lightbox/.
S. Dudoit, Y. H. Yang, M. J. Callow, et T. P.Speed : Statistical methods for
identifying differentially expressed genes in replicated cdna microarray experiments.
Rap. tech., Stanford University School of Medicine, 2002.
D. Firth et D. T. Lang : Cgiwithr : Facilities for processing web forms using r. JSS,
2003. URL http ://www.omegahat.org/CGIwithR/.
R. Gentleman et V. Carey : Bioconductor : open software development for
computational biology and bioinformatics. Genome Biol, 5(10):R80, 2004. URL
http ://dx.doi.org/10.1186/gb-2004-5-10-r80.
M.-H. Mucchielli et L. Marisa : Mango, an interactive r script for dna chip analyses,
2006. URL http ://bioinfome.cgm.cnrs-gif.fr/.
J. Newman et J. Weissman : Systems biology : many things from one. Nature, 444
(7119):561–562, Nov 2006. URL http ://dx.doi.org/10.1038/nature05407.
19RÉFÉRENCES
A. Pontillo et A. Mineo : Rphp, an r online with gui, 2005. URL
http ://dssm.unipa.it/R-php/.
C. Rolland : L’ingénierie des méthodes : une visite guidée. e-TI - la revue
électronique des technologies d’information, 1, 2005. URL http ://www.revue-
eti.net/document.php ?id=726.
M. M. XiaoQin Xia et Y. Wang : Webarray : an online platform
for microarray data analysis. BMC Bioinformatics, 6:306, 2005. URL
http ://www.biomedcentral.com/1471-2105/6/306.
20Vous pouvez aussi lire
