Skip to topic | Skip to bottom
Home
Main
Main.JulienNicolasr1.11 - 18 Jun 2005 - 20:21 - JulienNicolastopic end

Start of topic | Skip to actions

TER 2005 - Amélioration de JAdapt

Avancée Chronologique

03 Mars 2005 au 14 Mars 2005 :

Notre première réunion m'a permis de mieux comprendre le paradigme de programmation par séparation des préoccupations, la lecture du TE de licence des mes camarades Sébastien et Térence et une discussion avec eux m'ayant déjà donné une assez bonne idée de la programation par aspec, une partie de ce qui nous intéresse dans ce TER. La lecture de la thèse de Laurent Quintian, que nous a fournie Mr Lahire, m'a permis aussi d'affiner cette compréhension. Nous avons pu aussi mieux distinguer les objectifs de ce TER qui sont principalement de supprimer les deux freins à l'utilisation du travail de Laurent Quintian, à savoir : il tourne sur une ancienne d'Eclipse et il faut faire, à la main, dans un fichier xml, la description du "manuel de réutilisation", ce qui est assez pénible.

15 Mars 2005 à fin Mars 2005 :

Notre deuxième réunion nous a permis de voir un peu mieux comment nous allons structurer notre effort et nous avons décidé avec Térence de nous plonger dans le code afin de bien le comprendre pour pouvoir faire toutes les modifications nécessaires à nos objectifs en le rendant plus réutilisable. Térence a déjà fait une analyse de l'ancien modèle du nouveau et de l'actuel moteur d'adaptation ici

Fin Mars 2005 au 8 avril 2005 :

Préparation à la soutenance du cahier des charges. Je serai chargé de présenter l'organisation du TER

9 Avril au 1er Mai

Période d'examens donc TER suspendu

2 Mai au 8 Mai (Semaine 18)

Début de la phase de développement. Avec Térence nous travaillons sur l'amélioration du moteur d'adaptation. Pour l'instant nous allons essayer de modifier sa structure sans modifier sa sémantique pour le rendre (plus) compréhensible et (plus) extensible. Désormais le travail du moteur est parfaitement visible gràce à son découpage hiérarchique imaginé par Térence qui travaille jour et nuit, (et dont le rythme n'est pas facile à suivre :$) sous forme d'étapes découpées en phases elles même découpées en tâches. Ce découpage permet à présent de comprendre le mécanisme du moteur très facilement et des points obscurs d'implémentation de l'ancien moteur apparaissent d'eux même (partie non conforme à la thèse ou non implémentée). Le comportement du moteur lui reste inchangé et les exemples de Laurent Quintian ont exactement le même comportement qu'avant, avec en plus un log de l'activité du moteur, affiché dans la console d'éclipse.

9 Mai au 15 Mai (Semaine 19)

Notre première réunion à eu lieu mardi 10 et nous constatons avec stupeur que nous n'avions pas bien compris ce que Mr Lahire nous avait expliqué lors de notre dernière réunion, et nous craignons désormais d'avoir perdu du temps de travail : est ce que le travail sur le nouveau moteur ne servira à rien ? Toute l'organisation du projet travaillée pour le cahier des charges est également remise en cause. En attendant de pouvoir clarifier cette situation avec M. Lahire nous ne savons pas trop quoi faire qui ne risque de servir à rien :(. Notre réunion avec M. Lahire nous a beaucoup soulagé. Toutefois, même si dorénavant nous avons bien compris que son modèle EMF décrit toute l'application et non simplement l'éditeur, et comment s'articule ce modèle, le travail nous semble désormais très important et ne sommes plus convaincu du tout de pouvoir mener à terme nos objectifs principaux. En effet, le travail ne consiste plus en une série d'améliorations du plugin existant, mais de tout recoder de A à Z. Nous ne pourrons, à priori, quasiment rien récupérer du code existant qui ne pourra que nous servir d'exemple. Nos tests ne pourrons pas etre effectués tant qu'une bonne partie du TER ne sera effectuée. Les adaptations dont je me charge, necessitent que la partie langage soit implémentée (et testée?) pour que je puisse les tester.

16 Mai au 22 Mai (Semaine 20)

J'ai codé quelques adaptations tout en me familiarisant avec le modèle de l'application. Les adaptations nécessitent, d'après ce modèle, l'implémentation de 3 méthodes :

  • getEntities() : cette méthode doit renvoyer la liste des éléments concernés par le point de jointure de l'adaptation: des classes, des méthodes ou des attributs suivant l'adaptation. A epsilon près (suivant le type d'élément) son implémentation devrait etre la meme dans chaque adaptation.
  • execute() : c'est la méthode qui execute l'adaptation, elle aussi devrait etre à peu près toujours la meme : pour tous les éléments concernés par l'adaptation (donc obtenus par getEntities()) lancer la méthode executeOnOneEntity() decrite ci-après.
  • executeOnOneEntity() : c'est la méthode qui réalise effectivement l'adaptaion sur un seul élément. Cette méthode en revanche pourra être très différente d'une adaptation à l'autre. Elle réalise aussi pour l'instant un test de validité spécifique pour chaque adaptation.

23 Mai au 29 Mai (Semaine 21)

A la fin de cette semaine, l'intégralité des adaptations ont été analysées. Une grande partie est codée et commentée (anglais + français). De plus je pense avoir bien cerné les difficultés de certaines adaptations et compte en discuter avec M. Lahire lors de notre prochaine réunion. M. Lahire nous a confirmé la pertinence de l'ajout dans les adaptations d'une méthode se chargeant de faire des vérifications spécifiques à l'adaptation. Une étape du moteur devrait se charger de lancer toutes ces vérifications, ainsi lors de la réalisation des adaptations (méthode execute()) il ne devrait y avoir aucun test à faire.

30 Mai au 5 juin (Semaine 22)

Lors de notre réunion avec M. Lahire, il a confirmé que les difficultés soupçonnées en étaient bien et il en a soulevé une supplémentaire. Cette semaine sera consacrée d'abord,avec Térence, à corriger un problème majeur qui nous empeche de faire des tests puis de valider petit à petit le langage puis les adaptations. Nous avons aussi prévu de faire une première version du rapport d'ici samedi. Le problème a été réglé au bout de 2 jours. Je commence à tester les adpatations, tout d'abord une des plus simples : l'introduction d'attributs. Je créer une adaptation à la main en lui fournissant les descriptor que je créé mois aussi ainsi que sa cible. Enfin je lance execute() sur l'adaptation. Ce simple test à permis de découvrir plusieurs imperfections, des méthodes qu'on ne pensait devoir implémenter mais qui le devaient stick out tongue et quelques erreurs pour d'autres. Bref, avec la rédaction du rapport je n'ai pas pu faire marcher l'adaptation jusqu'au bout à la fin de la semaine.

6 juin au 12 juin (Semaine 23)

Derniers détails apportés au rapport. Fin de l'implémentation des méthodes getEntities qui sont testées et loggées. Premier test réussi pour l'introduction d'attribut, il est entèrement commenté et loggé. D'autres devraient suivre rapidemment désormais. Debut du moteur de l'application.

13 juin au 19 juin (Semaine 23)

Le moteur est implémenté. On peut charger les préoccupations depuis un fichier sdt généré par léditeur. L'applatissement des adaptateur est implémenté. La plupart des adaptations ont pu etres testées et fonctionnent

Sujets connexes



to top

I Attachment sort Action Size Date Who Comment
JulienNicolas-ToselliLaurent-td-RNN.zip manage 1493.5 K 16 May 2005 - 06:37 JulienNicolas td RNN NicolasJulien?&&ToselliLaurent

You are here: Main > TWikiUsers > JulienNicolas

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WIKIDeptinfo? Send feedback