• Nom : FerutTerence
• Email : ferutt@echo.unice.fr
• Web: http://www-mips.unice.fr/~ferutt
• Location : EtudiantsMinfo0405Group
• Pays : France
• Commentaires : Despite all my rage I am still just a rat in a cage

TER 2005 - Amélioration de JAdapt

Avancée Chronologique

03 Mars 2005 au 14 Mars 2005 :

Après une première réunion avec M. Lahire au laboratoire I3S à Sophia-Antipolis le 03 Mars 2005, j'ai lu à sa demande la thèse de doctorat de M. Laurent Quintian, soutenue l'an passé, proposant un nouveau modèle de réutilisations des préoccupations.
Ce modèle offre les avantages de la programmation par aspects (ajouts de variables et de classes, interceptions de méthodes ou d'exceptions, ...) et de la programmation par sujets (fusion des classes).
Il est donc très intéressant mais peut encore être amélioré sur plusieurs points. L'amélioration du modèle en lui-même (cf article de M. Lahire) mais la création du module de composition proposé par Laurent peut aussi être amélioré afin de le rendre plus utilisable pour le développeur. Enfin le moteur de réalisation des adaptations peut aussi être amélioré.

15 Mars 2005 à fin Mars 2005

Suite à une seconde réunion à l'I3S avec Mr Lahire le 14 Mars 2005, nous avons pu mieux cerné le travail que nous effectuerons. Ainsi, après une première répartition du travail en interne, il me revient la tâche, que je partage avec Julien, de lecture et de compréhension du code de Laurent Quintian, concernant essentiellement la mise en place de son moteur. Je dois bien comprendre les mécanismes de vérifications du code, de mise à plat des adaptateurs ainsi que la réalisation de l'adaptation.
Mr Lahire pense qu'il est possible de découper ce moteur en plusieurs classes, une par "tâche" du moteur. Il apparaît effectivement que le moteur applique plusieurs traitements séquentiellement ; il semble donc tout à fait plausible de découper ce code pour améliorer sa lisibilité pour les futurs lecteurs, par pur soucis d'extensibilité. Nous essaierons aussi d'intégrer de nouvelles adaptations dans ce moteur si tant est que nous y arrivions. Cette tâche n'entre pas dans les objectifs de base, elle sera donc traitée en dernier lieu.

• week-end du 19/20 mars 2005 : rédaction de l'intégralité de la première version (non définitive) du cahier des charges

Fin Mars au 8 Avril 2005

• finition du cahier des charges et création des diapositives pour la présoutenance.
• pour la présoutenance je serai chargé de présenter le travail que nous réaliserons, de présenter l'équipe et enfin c'est aussi moi qui terminerai la présentation en concluant sur la difficulté à intégrer la compilation incrémentale.

Semaine du 2 au 8 Mai 2005

Première semaine de la phase de production et cette semaine aura permis de bien s'avancer. Après avoir mûrement réfléchi ces dernières semaines sur les modifications du moteur, nous sommes arrivé, Nicolas et moi-même à un nouveau modèle qui nous sembait combiner tous les avantages souhaités. A savoir extensibilité, ergonomie et facilité à prendre en main.
Après quelques journées passées à étudier en profondeur le code de Laurent Quintian, et à l'adapter (la verison fournie par M.Lahire ne fonctionnait pas), nous avons réussi tout d'abord à en tirer une version qui fonctionne et à intégrer les modifications à son moteur (Voir les améliorations proposées pour ce moteur). Ce travail nécessitant pourtant une impressionnante quantité de travail (23 classes à ajouter, avec héritage et ploymorphisme), je dois bien reconnaître que je suis assez fier d'avoir réussi à tout terminer en moins d'une semaine - et le tout déjà commenté. Ne reste plus qu'à tout faire valider par nos encadrants et lors de la réunion du 10 Mai.

Semaine de 9 au 15 Mai 2005

Après une excellente première semaine au point de vue de la productivité, un grand blizzard sibérien semble avoir traversé le vieux continent et le temps pour nous glacer le sang lors de la 1ère réunion de validation, le mardi 10. En effet nous avons découvert (nul n'en était conscient sauf M. Lahire) que nous devions repartir à zéro et laisser totalement tomber le plugin de Laurent pour repartir sur le modèle d'application construit par M. Lahire. Sur le coup nous avons grandement redouté de devoir tout laisser choir notre travail entamé, mais finalement avec soulagement nous devrions pouvoir l'intégrer mutatis mutandis dans le présent modèle. Je m'occuperai donc de cette intégration mais d'abord je commence à travailler sur l'implémentation du package language de ce modèle, implémentation permettant d'interfacer le JDT (java development tools), permettant de manipuler l'AST avec le modèle de langage, très générale et indépendante de java, proposé par M. Lahire.

Semaine de 16 au 22 Mai 2005

Semaine très difficile d'un point de vue personnel (beaucoup de temps passé à réviser mes examens de russe et le TOEIC© que nous passons la semaine prochaine). Peu d'avancée effective car de nombreux problèmes de compréhension se sont posés. J'ai donc commencé à coder le package langage, en faisant une première version que je savais probablement incorrecte mais me permettant d'avoir déjà une base et de mieux comprendre. Grosse communication par emails avec M. Lahire, j'ai eu énormément de mal à cerner comment bien aborder le problème mais maintenant en fin de semaine je vois enfin plus clair, mais il demeure de nombreuses choses que je ne sais pas encore comment coder ; on verra ces choses là en dernier.
En attendant je me suis coder un plugin de test (minimal) me permettant de pouvoir tester mon package sur un projet simple ; cependant j'obtiens une excpetion que je ne m'explique pas à l'exécution - à revoir.

Semaine de 23 au 29 Mai 2005

Encore une semaine chargée avec une réunion, un examen de russe et le TOEIC©. Cependant je pense avoir bien avancé malgré tout et tout ce qui concerne les accès aux éléments du langages est quasiment fini. Seules certaines modification restent à coder, le reste étant probablement presque fini. mais pour l'instant rien n'a pu etre testé (le plugin développé par mes soins nous sort toujours une ExceptionInInitializerError^? lors de l'utilisation d'une des méthodes de JavaCore^? ... frustrant !). Sinon en tant que chef de projet j'ai soumis mes inquiétudes quant à l'aboutissement de notre TER, et toute l'équipe s'est montrée également peut confiante. N'ayant pas compris le travail de base demandé nous étions partis sur de mauvaises bases et pour nous il est clair que le travail demandé par M. Lahire est vraiment colossal. Nous lui avons donc fait part de nos inquiétudes, ainsi qu'à M. Crescenzo, et ils se sont montrés très réceptifs et si nous pouvonx leur confirmer qu'effectivement ce TER demandé plus de travail qu'ils ne le pensaient à la base (donc si on peut leur justifier que nous n'avons pas chaumé et pourtant aps fini) alors ils sont prêts à nous soutenir lors de la soutenance finale, et nous ont réconfortés en insistant que la qualité est plus importante que la qualité : mieux vaut ne pas finir et présenter du beau code plutôt qu'un code brouillon et illisible.
En attendant nous allons essayer d'avancer au maximum et nous verrons bien où nous en serons à la fin. Nous avons prévus de commencer à rédiger notre part du rapport final et de commencer toutes les features telles que le tutoriel et les exemples qui sont faisables dans l'état actuel du projet.

Semaine de 30 Mai au 05 Juin 2005

J'ai commencé la rédaction du rapport car nous ne voulons pas devoir le faire au cours des derniers jours. Grâce à M. Lahire j'ai aussi enfin pu faire marcher mon plugin qui m'a permis enfin de tester mon code réalisé au cours des dernières semaines. Il y avait des fautes dedans mais dans l'ensemble c'est pas mal. J'ai réalisé (avec l'aide de Nicolas pour la base) un gros fichiers de test qui s'applique sur un projet et réalise un gros nombre de tests. Ce fichier permet de voir le travail que j'ai réalisé. Cependant je travaille actuellement sur le code source uniquement, hors pour les modifications je ne sais pas encore utiliser l'AST et c'est lui que je devrai plutôt utiliser.

Semaine de 06 Juin au 12 Juin 2005

Semaine qui commence sur l'affreuse victoire de Nadal à Rolland Garros :-(. J'ai cependant bouclé le rapport. C'est moi qui me suis chargé de toute la mise en page, du plan, de l'assemblage et de la rédaction de sa majeure partie. Pendant ce temps j'ai donc mis de côté mon codage pour mieux le reprendre en fin de semaine. Après soumission du rapport en version béta à nos encadreurs j'ai réalisé de nombreuses modifications encore pour produire un rapport final, déposé le jeudi 09 au MIPS. J'ai aussi rédigé avec Nicolas un manuel de maintenance tout en anglais, destiné aux personnes souhaitant reprendre notre travail, pour mieux cerner le travail restant à effectuer, et les points à améliorer. J'ai aussi beaucoup retravailler mon commentaire de mon code, dans le but de produire une javadoc aussi complète que possible, et entièrement en 2 langues. Dans les jours à venir je vais essayer de revoir les derniers bugs de langages, essayer de comprendre enfin comment rendre persistentes les modifications obtenues par l'AST, et voir comment travailler sur engines.

Semaine du 13 au 19 Juin 2005

Enorme semaine d'un point de vue personnel. D'abord j'ai réalisé l'archive finale qui a été livrée lundi, puis ensuite j'ai travaillé sur la désérialisation des fichiers xml des adaptateurs. Chose que j'ai réussi et de là, avec Nicolas nous avons abattu un travail absolument énorme ! En l'espace de quelques jours nous avons pu tester nos fonctions et réaliser moult adaptations. A l'heure actuelle nous avons plus d'une dizaine d'adaptations absolument OK, le logiciel et donc quasiment fini.

Analyse détaillée du Moteur d'Adaptations

Par Térence FERUT le 17 Mars 2005
Dans l'implémentation réalisée par Laurent Quintian, les entités décrites dans son formalisme et contenues dans le module XML sont d'abord réifiées grâce à l'API - il s'agit de la partie avant de son précompilateur.
Une fois ces entitées réifiées, la composition des préoccupations à proprement parlé peut commencer. Elle se décompose en plusieurs sous-parties:

• la vérification des typages,
  
• l'aplatissement des adaptateurs,
  
• la réalisation des adaptations.
  

Vérification du typage des Adaptateurs

Cette étape consiste à analyser les adapteurs fournis pour s'assurrer qu'ils seront bien compatible avec le programme java. Pour se faire, la vérification consistera en 2 phases successives, elles-mêmes consistuées de plusieurs étapes.

1ère Phase

• Respect des conventions de nommage : les conventions sont les mêmes que celles du langage java, l'adaptateur doit donc porter le nom du fichier qui le contient, et ce nom doit être unique dans le paquetage.
  
• Unicité des identificateurs dans les adaptateurs : Dans l'espace de nommage de l'adaptateur, tous noms de variables et d'adaptations doit être unique.
  
• Adaptateur générateur : Un adaptateur peut générer un nouveau paquetage et un paquetage ne peut être générer que par un seul adaptateur.
  

2ème Phase

Seuls les adaptateurs qui ont passé avec succès tous les tests de la 1ère phases continuent et subissent ceux de la 2ème phase.

• Existence des importations : les adaptateurs peuvent importer des paquetages ou des classes, ces derniers doivent exister - ou être générés par un autre adaptateur.
  
• Caractère abstrait ou concret de l'adaptateur : Un adapateur pouvant être abstrait ou concret, certains cas engendreront une erreur de typage (variable abstraite dans un adaptateur concret, variable abstraite valuée, variable concrète sans valeur etc ...)
  
• Existence d'un super-adaptateur : La notion d'héritage existe aussi pour les adaptateurs, la déclaration d'un super-adaptateur implique donc l'existence de ce dernier dans le domaine de visibilité de l'adaptateur.

Si un seul adaptateur échoue dans un seul des tests de vérification, le préprocesseur arrête ici son exécution.

Aplatissement des Adaptateurs

Les adaptateurs utilisent toute la technologie Objet, ils peuvent être abstraits ou concrets et peuvent servir de parents (super-adaptateurs) à d'autres adaptateurs.
Un adaptateur a donc accès aux adaptations définies par son super-adaptateur (s'il en a un) et aux adaptations du super-adaptateur de son super-adaptateur etc ainsi de suite jusqu'à aboutir à un adaptateur qui n'a pas de père.
On imagine aisément quelle peut être la difficulté, lors de phase de composition des préoccupations d'utiliser un adaptateur et toutes les adaptations auxquelles il a accès. Pour remédier à ce problème Laurent Quintian propose un aplatissement des adaptateurs. Cet aplatissement consiste à fusionner dans un adaptateur toutes les déclarations d'importation et de variables de son super-adaptateur, et ce récursivement. On ne conserve que les adaptateurs "feuilles" (c'est à dire ceux qui ne sont pas super-adaptateur d'autres adaptateurs) non-abstraits (seul un adaptateur concret peut définir une adaptation).
Ainsi on obtient de simples adaptateurs contenant, à un moment donné, tout le code qui leur est nécessaire pour fonctionner pleinement et de manière autonome. Ces adapteurs sont ainsi mis à plat.

Réalisations des Adaptations

La réalisation des adaptations s'effectue par modification de l'arbre de syntaxe abstraite construit par les analyses syntaxique et lexicale du code source. Tout d'abord les adaptations sont triées suivant leurs inter-dépendances (tout cycle est détecté). Ensuite on applique toutes les adaptations de tous ces adaptateurs suivant l'ordre du tri, pour les adaptateurs, puis suivant l'ordre de déclaration des adaptations pour chacun des adaptateurs traités.
La modification de l'arbre de syntaxe abstraite s'effectue suivant les implémentations décrites dans la thèse de Laurent, section 5.4.

Voir les améliorations proposées pour ce moteur

---

Détails des modèles proposés par Laurent Quintian et par Philippe Lahire

Par Térence FERUT le 18 Mars 2005

Le Modèle de JAdapt - Laurent Quintian

Le modèle proposé par Laurent Quintian apparaît dans sa thèse de doctorat, chapitre 5, page 83, sur la figure 16.

Cette figure représente la hiérarchie des adaptations. On note la présence de 3 types d'adaptations : les Interceptions, les Introductions et les Fusions.

• Les Interceptions s'appliquent aussi bien sur des méthodes que sur des variables d'instance ou de classe. Ces Interceptions apparaissant soit autour de la méthode (ou variable), soit avant ou après celle-ci, soit encore sur levée d'exception. Les Interceptions de variables se font par Interceptions des accesseurs (get) ou modificateurs (set) de ces méthodes. Cependant on notera que ce modèle ne permet pas distinguer clairement la différenciation entre l'interception d'une méthode et l'interception d'un attribut , car, même si, d'un point de vue implémentation (avec "tissage" c'est la même chose), pour le développeur il s'agit bien de concepts différents.
• Les Introductions peuvent être de 3 types. On peut introduire soit une méthode (MethodIntroduction) soit un attribut (AttributIntroduction) soit encore une superclasse (SuperClass). On ne peut pas imaginer plus simple mais c'est pourtant pleinement suffisant.
• Les Fusions enfin ne sont que très peu détaillées. Une fusion peu porter sur une méthode ou une classe mais nous ne savons rien sur la façon dont le code est fusionné (quelle partie passe "avant" l'autre, ou "après" l'autre, possibilités de fusionner le code d'une manière personnalisée etc ...)

Le Modèle de Philippe Lahire

Première constatation : alors que Mr Quintian proposait 3 adaptations (interception, introduction et fusion) Mr Lahire en propose une quatrième en sus : la redéfinition. Les autres adaptations sont bien mieux découpées et le pouvoir d'expression de ce modèle se veut supérieur à celui proposé précédemment. Voyons comment :

• Les Interceptions de méthodes et de variables sont clairement séparées. Les interceptions de méthodes sont les mêmes que dans le premier modèle. La différence se situe dans l'interception d'attribut. Les interceptions se font toujours par le biais d'accesseurs et de modificateurs mais on propose ici soit d'agir avant le l'accès (resp la modification) de l'attribut, soit après. Sur ce point là le modèle de Philippe Lahire se positionne par rapport au premier modèle, de Laurent Quintian.
• Les Introductions ne changent pas.
• La Fusion est elle aussi bien plus détaillée (et plus riche) que la précédente. On différencie immédiatement la fusion de deux classes avec la fusion de deux méthodes. La fusion de classes permet de fusionner soit uniquement les méthodes et attributs de deux classes (FeaturesOnlyAdded), soit de fusionner le corps des méthodes (CustomizedMerging). La fusion de méthodes permet de câler le corps de la méthode à fusionner soit avant le corps de la méthode cible (MergingBefore), soit après (MergingAfter) et permet aussi de spécifier si l'une des méthodes est abstraite (MergingWithAbstract).
• La Redéfinition permet soit de redéfinir une méthode (MethodRedefinition) soit de redéfinir un attribut (AttributeRedefinition).

Conclusions sur ces 2 modèles

Tout d'abord il y eut le modèle créé par Laurent Quintian. Bien que suffisant ce dernier était clairement trop simple, trop rigide et souvent beaucoup trop général.
Se basant sur les travaux de Laurent, Philippe Lahire a, par la suite, développé un modèle nettement plus complet, plus souple et plus extensible que le précédent. Ce dernier compose une hiérarchie beaucoup plus naturelle et plus complète que celle que nous proposait Mr Quintian. De plus Mr Lahire ajoute une quatrième adaptation à son modèle, la redéfinition, inexistante tantôt. Ce modèle, ultérieur au premier, sera le modèle utilisé dans notre TER.

Sources et repères Bibliographiques

• Thèse de Doctorat - Laurent Quintian - JAdapt : Un modèle pour améliorer la réutilisation des préoccupations dans le paradigme objet
  
• article de Mr Lahire - New Perspective to improve reusability in Object-oriented languages
  
• Eclipse
  

Sujets connexes

• Plugin Eclipse JAdapt - page du TER
  
• Bonfils David
  
• Julien Nicolas
  
• Leroy Sébastien

---

• Set ALLOWTOPICCHANGE = FerutTerence
• Soutenancedu20-06-2005.ppt: version finale des diapos .ppt

to top