Dimension: px
Commencer à balayer dès la page:

Download ""

Transcription

1 Numéro d'ordre: D THÈSE Présentée devant l'institut National des Sciences Appliquées de Rennes pour obtenir le grade de Docteur de l'insa de Rennes Mention informatique par Erwan Jahier Équipe d'accueil : Lande, IRISA École Doctorale : MATISSE Composante universitaire : Insa de Rennes Titre de la thèse : Analyse dynamique de programmes : mise en uvre automatisée d'analyseurs performants et spécications de modèles d'exécution soutenue le 15 Décembre 2000 devant la commission d'examen M. : Daniel Herman Président MM. : Baudouin Le Charlier Rapporteurs Pierre Deransart MM. : Dominique De Waleffe Examinateurs Olivier Ridoux Md. : Mireille Ducassé Directrice de thèse

2

3 À Nolwenn et Aziliz, mes deux gros cailloux.

4

5 Remerciements Le jury. Daniel Herman, Professeur à l'université de Rennes 1, est incontestablement la personne qui, par l'intermédiaire de son cours génie logiciel en seconde année de Deug, m'a donné l'envie de faire de l'informatique plus tard. Je suis donc particulièrement heureux qu'il m'ait fait l'honneur de présider ce jury. Je remercie Baudouin Le Charlier, Professeur à l'université de Namur, et Pierre Deransart, Directeur de recherche à l'inria, d'avoir accepté la charge de rapporteur. Je remercie également Dominique De Walee, Directeur technique de la société Mission Critical, et Olivier Ridoux, Professeur à l'université de Rennes 1, d'avoir participé au jury en tant qu'examinateurs. Je remercie enn Michel Van den Bossche, PDG de Mission Critical, dont j'ai grandement apprécié la présence lors de la soutenance. Les relecteurs de l'ombre. Un grand merci pour leur courage et leur abnégation aux relecteurs néophytes, Nolwenn et Yvon Cornec pour la partie en français, et Marcel Seaudreau pour la partie en anglais. Fabien Gaucher et Yvan Roux ont aimablement accepté de jeter un dernier un coup d'oeil à ce document avant son impression ; les erreurs typographiques, grammaticale et ortograques y restant sont donc, il va de soi, de l'entière responsabilité de ces derniers. Kangaroo land. Iwarmly thank Fergus Henderson for his wonderfull technical support and code reviews. I also thank the whole smashing Mercury group with which it was a real pleasure to work during those three years. During my rst year of Phd, I had the chance of spending one month of french winter in Melbourne summer; Zoltan Somogyi, Fergus Henderson, Thomas Conway, Tyson Down, Mark Brown, David Jeery, Lee Naish, and Harald Sondergaard made my stay oversees an unforgivable moment. I am especially gratefull to Lee and Harald for taking me away toa3daywalk that give me the occasion to see my only true wild kangaroo... which was dead along the road! Universités. J'ai passé une bonne partie de mes trois années d'aspirant docteur dans les locaux du département informatique de l'insa. J'ai eu l'occasion d'y côtoyer des gens adorables. Les secrétaires, Lucette Bohuon et Joëlle Leroyer ; les ingé-sys, Jean- Louis Neveu et Véronique Abily ; et des enseignants-chercheurs, tels Marie-Joe Pédrono, Pierre-Yves Glorennec et Yvan Leplumey, dont j'ai particulièrement apprécié la gentillesse. Je garde également un souvenir impérissable de la voix chaude et forte du résident en campagne du bureau d'en face ; un certain Yves Cochet. J'ai ensuite eectué une année d'ater à l'ifsic, où j'ai eu le bonheur de collaborer avec Yannick Letertre, Lucien Ungaro, César Viho, Gilles Lesventes et Jean-Christophe Engel. De tous, je garderai toujours le meilleur souvenir. Le groupe Lande. J'ai apprécié la compagnie de chacun des membres de cette ne équipe, que ce soit les permanents : Pascal Fradet, Thomas Genet et Jensen, Daniel Le Métayer, Florimond Ployette, et Olivier Ridoux ; ou bien les thésards, avec, par ordre de

6 2 disparition, Valérie Gouranton, Ronan Gaugne, Tommy Thorn, Valérie-Anne Nicolas, Julien Mallet, Lionel Van Aertryck, Sarah Mallet, Mickaël Périn, David Mentré ; et les suivants qui suivent : Marc Éluard, Siegfried Rouvrais, Frédéric Besson, Sébastien Ferré, Thomas Colcombet, Jean-Phillipe Pouzol, Yoann Padioleau, et Valérie Viet Triem Tong. J'ai particulièrement aimé cohabiter (pour reprendre le cri d'amour du crapaud, comme disait Desproges) avec mes voisins de bureaux successifs ; Julien, pour nos discussions enammées, surtout les fois où nous étions du même avis, et Thomas (G.) pour son éternelle bonne humeur. Les sportifs. Je ne saurais achever cette salve de remerciements sans rendre un hommage appuyé à la dream team du RUC Tennis : Patrice Burgevin, Ronan Fablet, Frédéric Guyomarch', Pierre Hellier, Guillaume Moreau, et leur entraîneur poète Maxime Dejoux, dit Maxou le fou. La pugnacité de Patrice n'aura malheureusement pas su à sauver l'équipe d'une relégation tant redoutée (par lui, essentiellement, en fait). Les conseillers. Durant ma vie d'étudiant puis de doctorant, trois personnes à la gentillesse sans borne m'ont prodigué leurs conseils éclairés. Yannick Letertre, que je suis venu solliciter à plusieurs reprises dès mon arrivée à la fac ; Didier Caucal, toujours disponible et attentif ; et Olivier Ridoux, dont les précieux conseils dans les moments délicats sont pour beaucoup dans l'aboutissement decetravail. Enn et surtout, je remercie Mireille, qui cumule quasiment tous les critères pour apparaître ici, puisqu'elle fut à la fois membre du jury, de l'insa, et du groupe Lande, ainsi qu'une relectrice méticuleuse, une collègue d'enseignement, une conseillère avisée, et une joueuse de Tennis émérite. Mais elle fut surtout une directrice de thèse disponible et exemplaire. Ses conseils abondants et divers qui m'ont toujours parus pertinents, soit immédiatement, soit dans un deuxième temps. Par le truchement d'un procédé (déposé) de sur-annotage polychrome de versions préliminaires d'articles, Mireille m'a appris la rigueur dans l'écriture et dans la démarche scientique. Sa franchise m'a également été très protable. Son sens de l'organisation restera pour moi un modèle du genre. Mireille m'a transmis un goût immodéré pour le travail planié, jalonné par des échéances raisonnables et respectées... Évidemment, j'entends d'ici les mauvaises langues persier. En avoir le goût n'est certes pas susants, aussi, je m'engage solennellement à y parvenir dans une prochaine vie. Je remercie par ailleurs les autorités concernés qui ont acceptées l'utilisation, dans ce document, de trois langues ; le français, l'anglais et le grecque (cf p. 114). La thèse est une épreuvequivaut la peine d'être vécue, ne serait-ce que par la richesse des rencontres qu'elle suscite. Dans des registres très diérents, Michel Van Den Bossche, Didier Caucal, Mireille Ducassé, Fergus Henderson, Daniel Herman, et Olivier Ridoux (entre autres!) resteront pour moi des modèles.

7 3 Avertissement Foreword L'introduction, les chapitres des parties I et IV, ainsi que les titres et les mini-tables des matières de tous les chapitres sont en français. Le corps de la partie technique de la thèse, à savoir le corps des chapitres des parties II et III, sont en anglais. The introduction, the whole chapters of part I and IV, as well as titles and minitables of contents of all chapters are written in French. The body of the technical part of the thesis, namely, the body of part II and III chapters, are written in English.

8 4

9 Table des matières 5 Table des matières 1 Introduction L'analyse dynamique, un domaine de recherche délaissé Thèse et contributions Du choix de Mercury Débogage déclaratif et analyse de trace Organisation du mémoire I Contexte de l'étude 19 2 Extraction Préambule sur les modèles d'exécution Les sémantiques de langage de programmation Mise en uvre des modèles d'exécution Instrumentation d'un interpréteur Instrumentation du code source Instrumentation du code intermédiaire Instrumentation du code machine Utilisation des appels système Synthèse et discussion Analyse d'exécutions Vues abstraites d'exécutions Trace chronologique Modèles basés sur des graphes ou des arbres Prols d'exécutions Mise en uvre automatisée de moniteurs Utilisation de deux processus en coroutine Utilisation de processus légers Utilisation d'appels de procédures Synthèse et discussion

10 6 Table des matières II Mise en uvre automatisée d'analyseurs d'exécutions 43 4 Morphine, un système de débogage programmable pour Mercury Mercury Le système de trace de Mercury Les principaux concepts de Morphine Une session de mise au point avec Morphine Construction de moniteurs d'exécutions Intégration de Morphine dans le système de trace Performance de fget vis à vis de la construction de moniteurs Discussion et conclusion Mise en uvre automatisée de moniteurs d'exécutions ecaces Introduction Un opérateur pour analyser les exécutions: foldt Une dénition de foldt indépendante du langage Une mise en uvre de foldt pour Mercury L'interface utilisateur de foldt pour Mercury Applications Prols d'exécution Abstractions graphiques Couverture de jeux de tests Experimentations Méthodologie Tables des résultats Discussion Travaux connexes Conclusion III Spécications de modèles d'exécution 99 6 Spécications de modèles de traces de programmes logiques Introduction Une sémantique opérationelle pour Prolog Description de la sémantique Exemples Une spécication formelle du modèle des boîtes de Byrd Description de la spécication Prédicats tracés, prédicats opaques Animation de la spécication par une transcription en λprolog Extensions du modèle des boîtes de Byrd Un traitement spécial pour les prédicats déterministes Un port unify

11 Table des matières Numéro de clauses aux ports unify Profondeur d'exécution Numéro d'invocation de buts Numéro chronologique d'événements Réunion des extensions Travaux connexes Utilisation de sémantiques opérationelles structurelles (SOS) Génération d'environnements de programmation Autres systèmes de mise au point basés sur des sémantiques Comparaison avec notre travail Conclusion IV Bilan et perspectives Travaux en cours et perspectives Validation formelle de traceurs Applications de l'opérateur foldt Détection d'invariants Prolage de valeurs Évaluation de la qualité du code Tests Débogage algorithmique Généralisation du noyau d'analyse dynamique Connexion de foldt avec des outils de visualisation Programmation par Contraintes Conclusion Résumé des contributions Vers un environnement d'analyse dynamique extensible et multi-langage 127 A Programmes Mercury 131 A.1 qsort.m A.2 queens.m B Programmes λprolog 135 B.1 La sémantique de Nicholson et Foo en λprolog B.2 La spécication du modèle des boîtes de Byrd en λprolog B.3 La spécication du modèle des boîtes de Byrd étendu avec des compteurs et le port unify

12 8 Table des matières

13 Table des gures 9 Table des gures 2.1 Parallèle entre modèles d'exécution et modèles d'objets 3D Récapitulatif de l'évaluation des diérents modes d'extraction Récapitulatif de l'évaluation des diérents modes d'analyse d'exécution Le prédicat append/3 en Mercury Un exemple d'événement de la trace de Mercury Un exemple de trace exhaustive Illustration du mécanisme de ltrage d'événements de Morphine Le résultat du programme mastermind erroné Un résultat du prédicat display_mastermind/ Un moniteur qui compte le nombre d'appels Un moniteur qui compte le nombre d'événements à chaque port Un moniteur qui compte le nombre d'événements à chaque profondeur Un moniteur qui collecte l'ensemble des solutions d'un programme L'implémentation de la fonction trace() pour Morphine Coût des moniteurs des gures 4.7 à Ce que l'utilisateur doit faire pour dénir un moniteur avec foldt Un moniteur qui compte le nombre d'appels Invoquer le moniteur de la gure Les divers composants mis en jeux lorsque l'utilisateur invoque la commande : run_mercury(queens), foldt(count_call, Result) Un moniteur qui compte la profondeur maximale d'une exécution par intervalle de 500 événements Un exemple de session utilisant le moniteur de la gure Un moniteur qui compte le nombre d'événements à chaque port Un moniteur qui compte le nombre d'événements à chaque profondeur Un moniteur qui collecte l'ensemble des solutions d'un programme Le graphe de ot de contrôle de l'exécution du programme des 5 reines Un moniteur qui calcule le graphe de ot de contrôle d'une exécution Le graphe de ot de contrôle avec des compteurs de l'exécution des 5 reines Le graphe d'appels dynamique de l'exécution du programme des 5 reines Un moniteur qui calcule le graphe d'appels d'une exécution L'arbre de preuves de l'exécution du programme des 5 reines

14 10 Table des gures 5.16 Un moniteur qui mesure le taux de couverture de prédicat des 5 reines Un moniteur qui mesure le taux de couverture de site des 5 reines Une sémantique opérationnelle par continuation de Prolog Les types des fonctions sémantiques de la gure Une spécication formelle du modèle des boîtes de Byrd Un programme Prolog (celui donné par Byrd pour illustrer son modèle de boîtes) La trace produite par le programme de la gure Les types des fonctions sémantiques de la gure 6.3 étandues pour prendre en compte la profondeur Une spécication d'un modèle des boîtes de Byrd étendu Résultat de la spécication de la gure 6.7 avec le programme de la gure 6.4 et la requête?- p Une transformation de code source Prolog qui implémente une trace suivant le modèle des boîtes de Byrd Correction du traceur de la gure Les fonctions sémantiques de la gure 6.1 étendues pour prendre en compte les arguments

15 11 Chapitre 1 Introduction Table des matières du chapitre L'analyse dynamique, un domaine de recherche délaissé Thèse et contributions Du choix de Mercury Débogage déclaratif et analyse de trace Organisation du mémoire Du coût de production des diérentes phases du cycle de vie d'un logiciel. Des études telles que celle faite récemment par Hatton [Hatton 1997] montrent que la plus grande partie du coût de production d'un logiciel n'est pas engendrée lors de la phase de développement, mais lors de la phase de maintenance. Hatton indique que 20 % du coût de développement est généré lors de la phase de développement, 40 % lors de la phase de correction des bogues, et 40 % lors de la phase d'ajout de nouvelles fonctionnalités. C'est donc bien lors de la phase de correction-maintenance qu'il y a le plus d'opportunités d'obtenir des gains de productivité importants. Les analyses de programmes sont des outils très utiles pour réduire les coûts de production, à chacune de ces diérentes étapes. Analyse de programme ; analyses statiques, analyses dynamiques. Les analyses de programme inférent et vérient des propriétés sur le programme. Elles fournissent une grande aide au programmeur à chaque étape du développement d'un logiciel. Elles sont utiles lors de la phase de développement initial pour assurer les propriétés spéciées dans le cahier des charges ; lors de la phase de maintenance pour comprendre le fonctionnement et les éventuels dysfonctionnements du programme ; et lors de la phase d'ajout de nouvelles fonctionnalités pour s'assurer que les modications ne viennent pas invalider les propriétés du programme. Une analyse de programme est dite statique si elle ne prend en entrée que le code source du programme. Elle est dite dynamique si les propriétés sont inférées ou vériées par l'observation de l'exécution du programme.

16 12 Introduction De l'intérêt des analyses dynamiques par rapport aux analyses statiques. Permettant d'exhiber des propriétés moins générales que les analyses statiques car dépendantes des données d'entrées, les analyses dynamiques se révèlent néanmoins très utiles en pratique. Tout d'abord parce que certaines propriétés de programme sont indécidables. Par exemple, vérier qu'une fonction qui calcule la solution d'une équation polynomiale à coecients dans les entiers produit un entier naturel (dixième problème de Hilbert) est indécidable. Certes, il est possible de vérier certaines propriétés indécidables en restreignant le pouvoir d'expression des langages par l'intermédiaire d'un système de type [Milner 1978]. Mais toutes les propriétés de programmes ne peuvent pas être vériées ainsi sans restreindre de façon exagérée le pouvoir d'expression du langage. Tout l'enjeu de la recherche sur les langages de programmation consiste à trouver un ensemble de restrictions qui permettent de garantir le plus grand nombre de propriétés possible, sans trop diminuer le pouvoir d'expression du langage. Les analyses dynamiques sont très utiles lorsque que l'on est confronté à des propriétés pour lesquelles il n'existe pas un compromis satisfaisant. Par ailleur, quand l'utilisateur cherche à comprendre le fonctionnement ou les dysfonctionnements d'un programme, les analyses dynamiques permettent d'obtenir des informations beaucoup plus précises que les analyses statiques. Des systèmes d'analyses dynamiques tels que les débogueurs, les moniteurs et les proleurs sont donc bien nécessaires, notamment lors de la phase la plus coûteuse du cycle de production d'un logiciel ; la phase de maintenance. Dénition 1 (débogueur, moniteur, proleur) Un analyseur dynamique est un système qui génère des informations relatives à l'exécution des programmes. Un débogueur est un système d'analyse dynamique qui opère de façon interactive, c'est-à-dire, qui permet à l'utilisateur de spécier à la volée, les informations et les propriétés qu'il désire avoir sur l'exécution en cours. Un moniteur d'exécutions est un système d'analyse dynamique non interactif. Un proleur est un moniteur qui donne des informations relatives au temps d'exécution des diérents composants du programme. Les moniteurs extraient et vérient des propriétés globales, relatives à l'ensemble de l'exécution, alors que les débogueurs font la même chose pour vérier des propriétés plus locales. Mais tous ont la même nalité : extraire ou vérier des propriétés relatives aux exécutions. Pour autant, les débogueurs et les moniteurs sont souvent implémentés séparément. L'une des idées défendue dans notre thèse est qu'en faisant partager la même architecture aux diérents analyseurs dynamiques, on permet à ces outils de s'enrichir mutuellement. 1.1 L'analyse dynamique, un domaine de recherche délaissé Malgré les coûts très importants générés lors de la phase de maintenance, peu d'efforts en terme de recherche ont porté sur les environnements de programmation en général, et sur l'analyse dynamique en particulier [van Emden 1993, Wadler 1998]. Selon Wadler [Wadler 1998], le manque d'intérêt porté aux environnements de programmation

17 Thèse et contributions 13 est l'une des principales raisons expliquant le peu d'impact de la recherche sur les langages de programmation dans le monde industriel. Le manque d'intérêt porté à l'analyse dynamique est dû au fait que ces outils sont extrêmement coûteux à mettre en uvre, rendant ainsi une telle recherche dicilement valorisable dans un contexte académique. Les raisons expliquant le coût induit par la mise en uvre d'outils d'analyse dynamique sont les suivantes. Des systèmes techniques à mettre en uvre. Les analyseurs dynamiques sont des programmes techniques à mettre en uvre. Pour les implanter, il est typiquement nécessaire de modier le système d'exécution, que généralement seule une poignée de personnes maîtrise parfaitement. Pas de maîtrise sur le système sous-jacent. Le fait de reposer sur un système complexe (un compilateur), bien souvent développé par des tiers, ne pose pas uniquement des problèmes en termes de développement initial, mais aussi en termes de maintenance. Des outils diciles à réutiliser. Les outils ainsi développés sont vite périmés. En eet, étant généralement intégrés au compilateur, il est dicile de réutiliser de tels outils pour d'autres systèmes, dans d'autres contextes. Des besoins versatiles. Il est extrêmement dicile de connaître les besoins en outils d'analyse de programmes, car ils varient d'un utilisateur à l'autre. En eet, la compréhension de l'exécution d'un programme pour la personne chargée de maintenir un code varie en fonction de sa compétence, de son expérience du système de programmation utilisé, ainsi que de sa connaissance du code à maintenir [Ducassé & Emde 1988]. Il est dicile de connaître a priori les besoins de ces diérents utilisateurs dans ces diérents cas de gure. Il est donc souhaitable que chaque utilisateur, quel que soit son niveau de compétence sur le code à maintenir, puisse spécier facilement les analyses dynamiques qui lui permettent de comprendre le comportement de l'exécution des programmes. 1.2 Thèse et contributions Dans cette thèse, nous proposons une architecture qui vise à faciliter la construction d'analyseurs dynamiques performants. Ces analyseurs ont des performances du même ordre de grandeur que leurs équivalents, implémentés à la main, par modication du système de compilation. Ils peuvent être mis en uvre par des utilisateurs sans connaissance particulière du système de compilation, que, de plus, ils n'ont pas besoin de modier. Ceci permet aux utilisateurs d'implémenter les outils dont ils ont besoin. Cette architecture est basée sur : 1. Une instrumentation systématique du programme exécuté qui produit une image très détaillée de l'exécution : la trace.

18 14 Introduction 2. Un ensemble de primitives qui permettent d'analyser cette trace ecacement (à la volée). Dénition 2 (trace d'exécution) Une trace d'exécution est un ensemble d'informations produites par l'exécution d'un programme. D'une certaine manière, le résultat d'un programme peut être vu comme une trace, très grossière, de son exécution. Pour comprendre la façon dont un programme a calculé son résultat, on procède à une instrumentation qui rajoute des eets de bords, fournissant ainsi de l'information supplémentaire sur les états intermédiaires de l'exécution. Cette information est analysée et abstraite avant d'être présentée aux utilisateurs. Ainsi, pour la construction de tout analyseur dynamique, nous distinguons les étapes suivantes ([Ducassé & Noyé 1994]): 1. Dénition d'un modèle de l'exécution (ou modèle de trace). 2. Extraction de l'information correspondant à ce modèle. 3. Analyse/abstraction de l'information extraite. 4. Visualisation du résultat de l'analyse. Dans cette thèse, nous nous concentrons uniquement sur les trois premières étapes. Souvent, ces quatre étapes ne sont pas considérées explicitement, ni séparément. Par exemple, l'extraction de l'information et son analyse sont faites en même temps. Notre architecture repose sur une séparation explicite entre le système d'exécution et le système d'analyse d'une part, ainsi qu'entre les diérentes phases de la construction de l'analyseur d'autre part. La structure modulaire de cette architecture devrait faciliter la réutilisation des analyseurs pour d'autres systèmes d'exécution. Cette approche est largement inspirée d'opium [Ducassé 1999c], un débogueur extensible pour Prolog. Nous avons étendu les primitives d'opium dans le cadre de la construction de moniteurs d'exécutions. Cette étude a été menée dans le cadre du langage de programmation logique et fonctionnel Mercury [Somogyi et al. 1996]. Cependant, les concepts utilisés sont indépendants du paradigme de programmation. La trace sur laquelle nous basons la construction de nos analyseurs (étape 1) se doit de reéter le plus dèlement possible la sémantique opérationnelle du langage. C'est pourquoi nous proposons également un cadre de modélisation des traces d'exécutions basé sur une sémantique opérationnelle du langage. Cette spécication formelle de la trace nous permet de valider expérimentalement les traceurs et de prouver leur correction. Cette étude a été menée dans le cadre de Prolog standard [Deransart et al. 1996]. Contributions. Les contributions de notre travail sont les suivantes : Opium [Ducassé 1999c], un débogueur extensible de programmes Prolog, a été adapté pour le langage Mercury [Somogyi et al. 1996]. Ce travail a été réalisé en collaboration avec les chercheurs du projet Mercury de l'université de Melbourne, dans le cadre du projet ARGo, un projet de recherche et développement Européen Esprit.

19 Du choix de Mercury 15 Nous avons étendu les primitives d'opium pour permettre la construction de moniteurs d'exécutions ecaces. Le système d'analyse d'exécutions résultant, Morphine, est disponible 1 sous licence GNU/GPL, et est distribué avec Mercury 2. Morphine a également été déposé à l'agence de protection des programmes (APP). Nous avons montré comment Morphine pouvait être utilisé pour implémenter une large palette de moniteurs d'exécutions. Nous avons initié une réexion jetant les bases d'une notion de couverture de jeux de tests dans le cadre de la programmation logique. Nous avons proposé une spécication formelle du modèle de Byrd, ainsi qu'une extension de ce modèle. Ce travail fournit un cadre pour la validation expérimentale et formelle de la correction des traceurs pour Prolog. 1.3 Du choix de Mercury Actuellement, des langages impératifs tels que Fortran, C, C++ ou Java, ont plus d'impact que les langages de programmation logique ou fonctionnelle sur l'industrie du logiciel. Nous tenons donc à justier dès maintenant notre choix d'avoir utilisé Mercury pour illustrer notre thèse. Tout d'abord, beaucoup des concepts utilisés dans cette thèse sont indépendants du paradigme de programmation, comme le démontre une étude allant dans le même sens fait pour le langage C [Ducassé 1999b]. De plus, Mercury nous paraît être un langage plus proche de ce que seront les langages des années futures. Nous voyons deux raisons qui permettent de penser cela. La première raison est que Mercury est un langage permettant au compilateur de faire un grand nombre d'optimisations. Dans un premier temps, et dans une certaine mesure, l'utilisateur écrit son programme sans avoir à se soucier de performance ; le compilateur s'occupe tout seul d'optimiser les programmes. C'est en ce sens que Mercury est placé dans la catégorie des langages dits déclaratifs. De ce point de vue, Mercury est bien plus déclaratif que Prolog par exemple. Pour un grand nombre d'applications, Mercury produit du code dont les performances sont équivalentes à celui provenant d'un programme écrit en C. La deuxième raison est que Mercury est un langage qui permet au compilateur de faire une pléthore d'analyses statiques qui détectent un grand nombre d'erreurs dès la compilation. Ceci permet de réduire considérablement le coût associé à toute les phases de développement. Enn, notre point de vue est de considérer que, quand cela est possible, il est préférable d'essayer de détecter les erreurs en utilisant d'abord une analyse statique, et de n'observer l'exécution des programmes uniquement quand on ne peux plus faire autrement. En eet, il est important en termes de coût de développement de détecter les erreurs le plus tôt possible. De plus, la localisation peut parfois être

20 16 Introduction très précise avec ce type d'analyse. Les analyses statiques ne permettent pas de détecter toutes les erreurs, ni d'optimiser toutes les sources d'inecacité. Il reste donc un grand champ d'applications pour les analyses dynamiques. Développer des outils d'analyse dynamique dans le contexte d'un langage qui eectue un grand nombre d'analyses statiques nous oblige à nous intéresser aux vrais problèmes : ceux qu'aucune analyse statique ne peut résoudre. En d'autres termes, toutes les erreurs syntaxiques et autres étourderies ayant été capturées très tôt par le compilateur, il ne reste que les erreurs logiques, structurelles, qui demandent une compréhension profonde du fonctionnement du programme. Des outils exibles et extensibles sont alors d'autant plus nécessaires. 1.4 Débogage déclaratif et analyse de trace Il est parfois armé que pour mettre au point des programmes, et notamment ceux écrits dans des langages déclaratifs, il est préférable d'utiliser une approche déclarative. On parle à ce propos de débogage déclaratif ou débogage algorithmique, dont Shapiro a été le précurseur [Shapiro 1983]. La philosophie du débogage algorithmique est la suivante : un langage déclaratif décharge l'utilisateur des préoccupations (bassement) opérationnelles. L'utilisateur a simplement à s'intéresser au quoi, laissant le soin au système d'exécution, compilateur ou interpréteur, de gérer le comment. Lors de la phase de mise au point, comme lors de la phase de développement, l'utilisateur doit donc simplement s'occuper de vérier que la sémantique déclarative de son programme est cohérente et conforme à son cahier des charges. En outre, les sémantiques opérationnelles des langages déclaratifs sont généralement complexes. Présenter une image opérationnelle à l'utilisateur n'est donc pas nécessairement pertinent. Mercury, le langage que nous utilisons pour illustrer nos propos, est l'un de ces langages dits déclaratifs ; les déclarations de types, de modes et de déterminismes permettent au compilateur de faire un grand nombre de vérications statiques et d'optimisations. L'utilisateur a donc peu à s'occuper de performance lors du développement du programme ; c'est le compilateur qui eectue ce travail. Pour autant, nous estimons qu'il est faux de penser que le programmeur n'a jamais à se soucier de la façon dont le programme s'exécute. En eet, les optimisations faites par les compilateurs modernes sont très utiles, mais elles ne concernent somme toute que certaines optimisations simples. Lorsque l'algorithmique d'un programme est en n 3, il est bien rare que le compilateur puisse la transformer en un programme en n 2. Ainsi, quand le programme donne le bon résultat, mais dans un intervalle de temps anormalement grand, il s'agit d'être capable de comprendre quelles parties du programme sont sources d'inecacité. De plus, à partir d'une trace reétant la sémantique opérationnelle, il est toujours possible, et souhaitable, de reconstruire une vue de plus haut niveau ; il est même possible d'en construire plusieurs, comme nous le montrons dans la suite (voir notamment la section où nous montrons comment reconstruire un arbre de preuves à par-

21 Organisation du mémoire 17 tir de la trace). Mallet et Ducassé [Mallet & Ducassé 1999] le font également dans le cadre des bases de données déductives. Ainsi, à partir d'un modèle opérationnel très détaillé de l'exécution, nous pouvons construire à la fois des outils ayant une connotation opérationnelle, et des outils présentant une image déclarative de l'exécution. 1.5 Organisation du mémoire Première partie Contexte de l'étude et état de l'art. Cette partie introduit les concepts du domaine et étudie les travaux antérieurs relatifs à la construction automatisée d'analyseurs dynamiques ainsi qu'à leur dénition formelle. Deuxième partie Construction automatisée de moniteurs d'exécutions. Nous présentons une architecture qui permet de faciliter la construction d'analyseurs dynamiques dans le cadre du compilateur Mercury. Nous montrons également comment utiliser cette architecture pour implémenter une grande variété d'analyseurs dynamiques ; proleurs d'exécutions, couverture de jeux de tests, abstractions basées sur des graphes. Les mesures que nous avons eectuées révèlent que les analyseurs résultants ont des performances du même ordre de grandeur que des analyseurs implémentés à la main par modication du système de compilation. Troisième partie Spécication de modèles d'exécutions. Nous proposons dans cette partie un cadre de spécication des modèles de trace d'exécutions de programmes Prolog basé sur une sémantique opérationnelle. Ces spécications formelles de la trace nous permettent de valider expérimentalement les traceurs et de prouver leur correction. Quatrième partie Conclusion et perspectives. Nous décrivons enn des travaux en cours et nous donnons un certain nombre de pistes de recherche à court, moyen et long terme. Schéma de lecture Chacune des parties de ce document devrait pouvoir être lue indépendamment des autres. Cependant, pour les personnes peu ou pas familières avec la problématique de l'analyse dynamique, il est tout de même recommandé de lire auparavant la première partie. Chacune des parties est découpée en chapitres. Pour la partie II, il est conseillé de lire les chapitres dans l'ordre. Les langages de programmation utilisés pour l'illustration de notre thèse sont Mercury dans la deuxième partie et Prolog dans la troisième. Aucune connaissance a priori de ces langages ne devrait être nécessaire pour suivre le l du discours.

22 18 Introduction

23 19 Première Partie Contexte de l'étude Dans cette partie, nous présentons un certain nombre de travaux antérieurs relatifs à la mise en uvre automatisée d'analyseurs dynamiques. Toute analyse dynamique se décompose en une phase d'extraction de l'information, et en une phase d'analyse de cette information. Nous étudions au chapitre 2 la première phase, et la deuxième au chapitre 3.

24

25 21 Chapitre 2 Extraction Table des matières du chapitre Préambule sur les modèles d'exécution Les sémantiques de langage de programmation Mise en uvre des modèles d'exécution Instrumentation d'un interpréteur Instrumentation du code source Instrumentation du code intermédiaire Instrumentation du code machine Utilisation des appels système Synthèse et discussion Pour pouvoir analyser les exécutions, la première étape consiste à extraire un certain nombre d'informations à certains points de programme. En quelque sorte, on discrétise l'exécution en l'observant à des points de programmes particuliers. Cette démarche est comparable à celle qui consiste à discrétiser un objet dans l'espace dont la forme est trop complexe pour être décrit de façon exhaustive. Nous détaillons en section 2.1 ce parallèle avec la modélisation d'objet dans l'espace pour donner une intuition sur la notion de modèle d'exécution. Par ailleurs, les sémantiques de langages, et notamment les sémantiques dites opérationnelles, sont des spécications formelles de la façon dont s'exécutent les programmes. Ce sont donc des outils privilégiés pour la description formelle des modèles d'exécution. La section 2.2 est ainsi consacrée à la description des diérents types de sémantiques. Pour mettre en uvre ces modèles d'exécution, c'est-à-dire pour en extraire de l'information à chacun des points de programme spéciés par le modèle, il existe plusieurs méthodes. Nous passons en revue en section 2.3 ces diérentes méthodes.

26 22 Extraction 2.1 Préambule sur les modèles d'exécution Que ce soit, par exemple, en mécanique, ou bien en imagerie numérique, pour pouvoir manipuler des objets en trois dimensions, pour raisonner, ou pour faire des simulations, il est nécessaire d'en avoir une description mathématique. La plupart du temps, ces objets ont une forme trop complexe pour être modélisés par des fonctions. On eectue donc une discrétisation qui permet d'obtenir une représentation de l'objet, certes imparfaite, mais nie. Pour eectuer un telle discrétisation, on doit : 1. choisir un pas de discrétisation ; par exemple, 1 mm, 2. dénir un certain nombre d'informations disponibles à chaque point du modèle ; par exemple la couleur, la température, la texture, la luminosité. Cette modélisation, bien que ne décrivant pas de façon exhaustive l'ensemble des caractéristiques d'un objet, n'en reste pas moins utile pour en déduire des propriétés. La nature de ces propriétés va dépendre du grain de la modélisation et du type d'informations disponibles à chaque point du modèle. Par exemple, pour calculer la résistance aux chocs de l'objet, on aura besoin d'un coecient d'élasticité ; pour le visualiser, on aura besoin de sa couleur et de sa texture. De la même façon, pour dénir un modèle d'exécution, nous allons faire une discrétisation de l'exécution en choisissant pour cela : 1. Des points de programmes que nous appelons événements d'exécution ;cepeuvent être, par exemple, les appels et les sorties des fonctions du programme ou de boucles. 2. Pour chaque événement, un certain nombre d'informations relatives à l'état courant de l'exécution. Nous appelons ces informations des attributs de l'événement ; ce peuvent être, par exemple, le nom de la procédure courante, la profondeur de l'exécution, l'instanciation courante des variables sous portée, ou bien la pile d'appels. Nous résumons dans le tableau 2.1 notre parallèle entre modélisation d'objets en trois dimensions et modélisation d'exécutions de programmes. À chaque fois, le type de propriétés de programmes que l'on va être capable de calculer va dépendre de la discrétisation eectuée. En outre, une discrétisation très ne doit permettre d'obtenir une meilleure précision au prix de temps de calculs plus longs. En d'autres termes, il n'y a pas de meilleure discrétisation ; il y a juste des discrétisations adaptées à des analyses particulières. Le choix d'une bonne discrétisation pour une propriété donnée est délicat. Pour cette raison, le choix du modèle doit pouvoir être souple. 2.2 Les sémantiques de langage de programmation Les sémantiques sont des outils très puissants pour dénir les langages et leurs modes d'exécutions. Les sémantiques [Mitchell 1996, Nielson & Nielson 1992] sont dé- nies par des fonctions qui prennent en argument des expressions du programme. Une

27 Les sémantiques de langage de programmation 23 Exécutions Objets 3D Modèle ensemble d'événements ensemble de points Points du modèle événement = tuple d'attributs nom de la procédure, arguments, profondeur,... points = tuple d'informations position dans l'espace, couleur, température, texture,... Choix d'un pas points de programme distance entre les points Index l'ordre chronologique des position des points dans Représentations abstraites du modèle événements trace chronologique, graphes de ot de contrôle, graphes d'appels,... l'espace représentation en 2D ou 3D, en couleur ou en niveau de gris, la couleur donnée en fonction de la position ou de la température,... Figure 2.1 Parallèle entre modèles d'exécution et modèles d'objets 3D propriété importante que l'on cherche à obtenir lorsque l'on dénit une sémantique est la compositionnalité. Dénition 3 (Sémantiques compositionnelles) Une sémantique est dite compositionnelle si la sémantique de toute expression est construite strictement à partir de celle de ses sous-expressions. La propriété de compositionnalité d'une sémantique est fondamentale d'un point de vue pratique. Elle permet d'assurer que la sémantique dénit une relation de congruence entre les éléments de son co-domaine, ce qui permet de faire des preuves locales, donc plus simples à mettre en uvre ; ces preuves sont eectuées par cas sur la structure syntaxique des programmes (induction structurelle). Dénition 4 (Sémantiques déclaratives et sémantiques opérationnelles) Une sémantique est dite déclarative ou intentionnelle si elle décrit le résultat d'une expression à partir de ses arguments d'entrée, sans décrire comment ce résultat est obtenu. Une sémantique est dite opérationnelle ou extensionnelle si, au contraire, elle décrit la façon dont le résultat de l'expression est obtenu. D'un certain point de vue, les sémantiques déclaratives ont un grain moins n que les sémantiques opérationnelles. Quand on dénit une sémantique opérationnelle et une sémantique déclarative, il est de bon ton de vérier qu'elles conduisent au même résultat. Un style de sémantique souvent employé est celui des sémantiques dites axiomatiques. Dénition 5 (Sémantiques axiomatiques) Une sémantique est dite axiomatique si elle est dénie indirectement par des axiomes et des règles spéciant des propriétés du

28 24 Extraction langage. Ces axiomes permettent, entre autre, de déduire le résultat d'un programme. Certains aspects de l'exécution peuvent être ignorés cependant. Les sémantiques axiomatiques sont généralement intentionnelles. Le fait d'être énoncé sous formes d'axiomes relatifs aux propriétés du programmes rend ce type de sémantiques particulièrement adapté aux preuves de corrections de programmes. Ces preuves sont d'autant plus facilitées que ces sémantiques opèrent généralement sur des ensembles récursivement énumérables [Mitchell 1996]. Quand on parle de preuves de programme, on désigne par défaut des preuves de correction partielle ; c'est-à-dire, des preuves de propriétés valables sous l'hypothèse que les programmes terminent. Quand on prend aussi en compte la terminaison, on parle alors de correction totale. Les dénitions précédentes caractérisent la nature des sémantiques. Celles qui suivent sont relatives au style de formalisme utilisé pour dénir les sémantiques. Dénition 6 (Sémantiques par continuations et sémantiques en style direct) Une sémantique par continuations est une sémantique qui prend en argument des continuations, c'est-à-dire, des fonctions qui représentent le sens du reste du programme. Une sémantique en style direct est une sémantique qui n'utilise pas de continuation dans sa dénition. Les continuations ont été inventés par Strachey [Strachey & Wadsworth 2000] 1 pour décrire de façon élégante les sauts (goto). En particulier, les continuations permettent de décrire, de façon concise et élégante, le retour arrière (backtracking) en Prolog, ou les exceptions [de Bruin 1986]. Elles permettent en fait de décrire facilement tout ce qui peut être implanter par des piles. Les piles étant une structure de données utilisées dans tous les compilateurs, il n'est guère surprenant que les continuations soient un formalisme particuliérement adaptées pour décrire les sémantiques, et notamment les sémantiques opérationnelles. Dénition 7 (Sémantiques dénotationnelles) Une sémantique est dite dénotationnelle si elle associe à chaque expression du langage une valeur (sa dénotation) dans un ensemble (partiellement) ordonné et complet 2 et qu'elle manipule des objets innis (fonctions, structures de données innies) comme des objets de première classe, en s'appuyant sur la continuité des opérations et sur le concept de point xe dans un CPO. Les sémantiques dénotationnelles s'opposent souvent aux sémantiques opérationnelles telles que les sémantiques dites structurelles [Plotkin 1981] (SOS) ou les sémantiques naturelles [Kahn 1987]. Ces sémantiques sont données en termes de systèmes de transitions, où chaque transition décrit une étape de calcul. Les sémantiques qui sont à la 1. La date de parution peut surprendre les lecteurs attentifs, Strachey étant mort en Il s'agit en fait d'une réédition, plus accessible que l'article original, parue dans un numéro spécial dédié à Strachey. 2. Un ensemble ordonné est complet lorsque toute suite croissante admet une borne supérieure (complete partial order, ou CPO en anglais).

29 Mise en uvre des modèles d'exécution 25 fois opérationnelles, dénotationnelles et compositionnelles sont dites complètement abstraites (fully abstract semantics). Ces sémantiques sont évidemment très attrayantes car elles permettent de faire des preuves relatives à l'exécution des programmes (car opérationnelles) qui soient locales (car compositionnelles). Nous utilisons d'ailleurs en section 6.2 une sémantique de programmes logiques Prolog [Nicholson & Foo 1989, de Bruin & de Vink 1989] qui est à la fois dénotationnelle, opérationnelle, et par continuation ; dans cette sémantique, les continuations se révèlent particulièrement adaptées pour décrire le comportement de la coupure (`!'). En eet, l'implémentation des coupures est liée à l'utilisation d'une pile : une coupure enlève de la pile de recherche les points de choix de la procédure courante. Discussion à propos de ces dénitions. Pour Nielsson et Nielsson, une sémantique dénotationnelle est nécessairement intentionnelle [Nielson & Nielson 1992]. Il ne nous paraît pas judicieux de restreindre l'utilisation de ces sémantiques à des descriptions purement intentionnelles de l'évaluation d'une expression. La preuve en est qu'il existe des sémantiques qui sont à la fois dénotationnelles et opérationnelle : les sémantiques complètement abstraites. De façon similaire, on trouve parfois dans la littérature que les sémantiques dénotationnelles sont nécessairement compositionnelles [Mitchell 1996, Nielson & Nielson 1992]. Or, la notion de compositionnalité ne dépend pas du style (dénotationnel ou pas) de formalisme utilisé pour décrire une sémantique. Janssen [Janssen 1996] (dans un contexte diérent, mais très proche, de celui du traitement automatique des langues naturelles) va même jusqu'a dire que ce qui n'est pas compositionnel est trop peu ou mal formalisé. Les raisons pour lesquelles les sémantiques dénotationnelles devraient être compositionnelles, et pas les sémantiques opérationelles, sont d'ordre historique. En effet, la plupart des sémantiques qui décrivent le mode d'exécutions des programmes (SOS) ne sont pas compositionnelles, alors que les sémantiques purement intentionnelles données dans un style dénotationnel le sont. La sémantique de Nicholson et Foo [Nicholson & Foo 1989], qui décrit dans un style dénotationnel le mode d'exécution des programmes Prolog, montre bien que cette généralisation (dénotationnel = compositionnel) est malencontrueuse. Un autre example est la sémantique introduite par Le Charlier et al. [Charlier et al. 2001], qui, à l'inverse, est une sémantique compositionnelle donnée sous la forme d'un système de transitions (comme les SOS). La compositionnalité d'une sémantique ne dépend donc bien pas du style employé pour la dénir. 2.3 Mise en uvre des modèles d'exécution Il existe plusieurs façons de mettre en uvre des modèles d'exécution, c'est-à-dire, d'extraire de l'information d'une exécution [Ducassé & Noyé 1994]. On peut instrumenter un interpréteur, le code source, le code intermédiaire, le code objet, le code exécutable, ou bien récupérer des appels systèmes. La plupart des travaux que nous référençons traitent, de façon plus ou moins dissociée, à la fois des phases d'extraction

30 26 Extraction et d'analyse. Nous nous focalisons ici sur la phase d'extraction ; la phase d'analyse est abordée au chapitre suivant. Chaque mode d'extraction est décrit et évalué en fonction des six critères suivants. Un récapitulatif de ces évaluations est donné en gure 2.2 en n de chapitre. 1. Pertinence de la trace générée vis à vis de la sémantique du langage. 2. Indépendance vis à vis du langage à analyser. 3. Indépendance vis à vis de l'architecture sous-jacente (système d'exploitation et type de machine). 4. Facilité de mise en uvre et de maintenance. 5. Performance du programme exécuté sous le contrôle du traceur. 6. Le compilateur et l'analyseur sont deux systèmes distincts. Le sixième critère mérite sans doute une justication. Nous pensons en eet que, à l'instar de Brooks et al. [Brooks et al. 1992], lorqu'il existe un compilateur, le système d'analyse dynamique et le compilateur ne doivent pas former deux systèmes distincts. En eet, certaines erreurs ne se manifestent qu'en présence des optimisations. Certains programmes ne sont exécutables que dans leur version optimisée à cause de contraintes de taille mémoire ou de temps d'exécution. Quand on cherche les goulots d'étranglement dans un programme, c'est vraiment le programme optimisé que l'on veut observer. On est obligé de recompiler les programmes pour les analyser. Parfois, les erreurs proviennent de bogues dans les optimisations elles-mêmes. Même s'il est vrai qu'il est souvent bon que certains détails de l'exécution soient cachés à l'utilisateur, nous pensons qu'il est préférable, dans ce cas, de laisser le soin à l'analyseur de cacher certains détails. Un certain nombre de travaux prometteurs ontété eectués [Adl-Tabatabai & Gross 1993, Adl-Tabatabai & Gross 1996, Brooks et al. 1992, Coutant et al. 1988, Copperman 1994, Tice & Graham 1998, Wismüller 1994] qui visent à rendre transparentes à l'utilisateur les optimisations faites par le compilateur Instrumentation d'un interpréteur Une première méthode pour extraire des informations relatives à l'exécution de programmes consiste à instrumenter un interpréteur. Cette approche est attrayante, car les modèles d'exécution des langages de programmation sont parfois décrits sous forme de sémantiques formelles. De telles sémantiques peuvent aisément être traduites dans un langage de programmation, conduisant ainsi à des interpréteurs [Consel & Khoo 1991]. Ces sémantiques peuvent également être modiées pour dénir des analyseurs d'exécutions qui peuvent, à leur tour, être exécutés ; on obtient ainsi des systèmes d'analyses d'exécutions dénis formellement. Il existe une vaste littérature basant la construction d'analyseur sur des interpréteurs. Nous nous contentons ici de décrire quelques travaux parmis les plus pertinents compte tenu de ce que nous faisons dans la suite.

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours 0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage 3- Organisation du cours Le présent cours constitue une introduction pour situer le langage C++, beaucoup des concepts

Plus en détail

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

G R E C A U Rapport sur le mémoire de thèse de doctorat ENSA de Toulouse, INSA, école doctorale MEGeP, Spécialité Génie Civil, En co-tutelle avec l'université de Laval, Québec, Canada présenté par Catherine

Plus en détail

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation Un peu d'organisation Conception et Programmation par Objets HLIN406 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 Premières semaines Contrôle des connaissances Supports 2015 Sommaire

Plus en détail

Université Laval Faculté des sciences et de génie Département d'informatique et de génie logiciel IFT-3101. Travail pratique #2

Université Laval Faculté des sciences et de génie Département d'informatique et de génie logiciel IFT-3101. Travail pratique #2 Université Laval Faculté des sciences et de génie Département d'informatique et de génie logiciel IFT-3101 Danny Dubé Hiver 2014 Version : 11 avril Questions Travail pratique #2 Traduction orientée-syntaxe

Plus en détail

Évaluation et implémentation des langages

Évaluation et implémentation des langages Évaluation et implémentation des langages Les langages de programmation et le processus de programmation Critères de conception et d évaluation des langages de programmation Les fondations de l implémentation

Plus en détail

Algorithmique et programmation. Cours d'algorithmique illustré par des exemples pour le picbasic

Algorithmique et programmation. Cours d'algorithmique illustré par des exemples pour le picbasic Algorithmique et programmation Cours d'algorithmique illustré par des exemples pour le picbasic Même s'il est possible d'écrire un programme petit à petit par touches successives, le résultat est souvent

Plus en détail

Livret du Stagiaire en Informatique

Livret du Stagiaire en Informatique Université François-Rabelais de Tours Campus de Blois UFR Sciences et Techniques Département Informatique Livret du Stagiaire en Informatique Licence 3ème année Master 2ème année Année 2006-2007 Responsable

Plus en détail

Contexte général de l étude

Contexte général de l étude 1 2 Contexte général de l étude Les entrepôts de données associés à des outils d analyse On Line Analytical Processing (OLAP), représentent une solution effective pour l informatique décisionnelle (Immon,

Plus en détail

MODELE D UN RAPPORT DE STAGE DE BAC PRO ELECTROTECHNIQUE

MODELE D UN RAPPORT DE STAGE DE BAC PRO ELECTROTECHNIQUE MODELE D UN RAPPORT DE STAGE DE BAC PRO ELECTROTECHNIQUE [Prénom Nom] Rapport sur le stage effectué du [date] au [date] Dans la Société : [NOM DE LA SOCIETE : Logo de la société] à [Ville] [Intitulé du

Plus en détail

Le génie logiciel. maintenance de logiciels.

Le génie logiciel. maintenance de logiciels. Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction

Plus en détail

Méthodologies de développement de logiciels de gestion

Méthodologies de développement de logiciels de gestion Méthodologies de développement de logiciels de gestion Chapitre 5 Traits caractéristiques des deux approches de méthodologie Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel http://lgl.isnetne.ch

Plus en détail

Machine de Turing. Informatique II Algorithmique 1

Machine de Turing. Informatique II Algorithmique 1 Machine de Turing Nous avons vu qu un programme peut être considéré comme la décomposition de la tâche à réaliser en une séquence d instructions élémentaires (manipulant des données élémentaires) compréhensibles

Plus en détail

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN Les contenues de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et ne peuvent en aucun cas

Plus en détail

P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S

P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S POUR L ENSEIGNEMENT DE L INFORMATIQUE MPSI première année I. Objectifs de la formation II-1 Développement de compétences et d aptitudes

Plus en détail

Système. Introduction aux systèmes informatiques

Système. Introduction aux systèmes informatiques Introduction aux systèmes informatiques Système Un système est une collection organisée d'objets qui interagissent pour former un tout Objets = composants du système Des interconnexions (liens) entre les

Plus en détail

Compte-rendu de projet de Système de gestion de base de données

Compte-rendu de projet de Système de gestion de base de données Compte-rendu de projet de Système de gestion de base de données Création et utilisation d'un index de jointure LAMBERT VELLER Sylvain M1 STIC Université de Bourgogne 2010-2011 Reponsable : Mr Thierry Grison

Plus en détail

Conception d'un système de gestion de logs -

Conception d'un système de gestion de logs - Conception d'un système de gestion de logs - Dossier d'initialisation Version : 0.2-22/05/2008 Rédiger par : Gassmann Sébastien Lu et revu par : Petit Jean-Marc (23/05/2008) Table des matières 1 Contexte

Plus en détail

WildCAT : un cadre générique pour la construction d'applications sensibles au contexte

WildCAT : un cadre générique pour la construction d'applications sensibles au contexte WildCAT : un cadre générique pour la construction d'applications sensibles au contexte Pierre-Charles David France Télécom, Recherche & Développement Réunion Adapt, Paris 2006-04-06 Plan 1 Introduction

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Conventions communes aux profils UML

Conventions communes aux profils UML Conventions communes aux profils UML Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable 2.1 Date : Juin 2002 * : Les partenaires du

Plus en détail

Chapitre I - Introduction et conseils au lecteur

Chapitre I - Introduction et conseils au lecteur Chapitre I - Introduction et conseils au lecteur Cette partie introductive situe la place de l'algorithmique dans le développement logiciel et fournit au lecteur des conseils : conseils pour bien analyser

Plus en détail

INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES

INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information

Plus en détail

RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS

RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS Université Joseph Fourier Département Licence Sciences & Technologie RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS Laboratoire d'accueil : Verimag

Plus en détail

Le Répertoire National des Certifications Professionnelles (RNCP) Résumé descriptif de la certification

Le Répertoire National des Certifications Professionnelles (RNCP) Résumé descriptif de la certification 1 sur 8 26/09/2013 16:49 Le Répertoire National des Certifications Professionnelles (RNCP) Résumé descriptif de la certification Intitulé Licence : Licence Sciences, technologies, santé mention Informatique

Plus en détail

Automatisation de la certification formelle de systèmes critiques par instrumentation d interpréteurs abstraits

Automatisation de la certification formelle de systèmes critiques par instrumentation d interpréteurs abstraits 1 d Automatisation de la certification formelle de systèmes critiques par instrumentation d sous la direction de Michaël Périn Soutenance de Thèse de Doctorat Université de Grenoble - Laboratoire Verimag

Plus en détail

TER Master 1 (FMIN 200) Cahier des charges: Oracle Lexical

TER Master 1 (FMIN 200) Cahier des charges: Oracle Lexical TER Master 1 (FMIN 200) Cahier des charges: Oracle Lexical VEYSSIER Julien, BISQUERT Pierre PAIVA LIMA DA SILVA Bruno, BELMONTE Remy - Encadrant : Mathieu Lafourcade 6 février 2009 Université Montpellier

Plus en détail

Le chiffre est le signe, le nombre est la valeur.

Le chiffre est le signe, le nombre est la valeur. Extrait de cours de maths de 6e Chapitre 1 : Les nombres et les opérations I) Chiffre et nombre 1.1 La numération décimale En mathématique, un chiffre est un signe utilisé pour l'écriture des nombres.

Plus en détail

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

Plus en détail

Semaine 6 : La notation For

Semaine 6 : La notation For Semaine 6 : La notation For Les fonctions d'ordre supérieur telles que map, atmap ou lter fournissent des constructions puissantes pour manipuler les listes. Mais parfois le niveau d'abstraction requis

Plus en détail

Système Expert pour Smartphones

Système Expert pour Smartphones INSA Rennes Département INFORMATIQUE Système Expert pour Smartphones Rapport de bilan de Planification Olivier Corridor;Romain Boillon;Quentin Decré;Vincent Le Biannic;Germain Lemasson;Nicolas Renaud;Fanny

Plus en détail

Gestion d'un entrepôt

Gestion d'un entrepôt Gestion d'un entrepôt Épreuve pratique d'algorithmique et de programmation Concours commun des écoles normales supérieures Durée de l'épreuve: 3 heures 30 minutes Juin/Juillet 2010 ATTENTION! N oubliez

Plus en détail

Analyse de performance, monitoring

Analyse de performance, monitoring Analyse de performance, monitoring Plan Principes de profilage Projet TPTP dans Eclipse Utilisation des profiling tools de TPTP Philippe Collet Master 1 Informatique 2009-2010 http://deptinfo.unice.fr/twiki/bin/view/minfo/gl

Plus en détail

Note de service n 2012-034 du 6 mars 2012

Note de service n 2012-034 du 6 mars 2012 Note de service n 2012-034 du 6 mars 2012 (modifiée par la note de service n 2012-100 du 29 j uin 2012 et par la note de service n 2012-179 du 20 novembre 2012) (Education nationale : bureau DGESCO A2-1)

Plus en détail

Correction de programmes : Logique de Hoare

Correction de programmes : Logique de Hoare 16 juillet 2009 Logique et informatique Vis-à-vis de l informatique la logique a au moins 2 rôles : 1 Externe et théorique (fondements de l informatique - Électif en S4) : Logique comme méta-informatique

Plus en détail

DECHARGEMENT ET CHARGEMENT MASSIF DES DONNEES

DECHARGEMENT ET CHARGEMENT MASSIF DES DONNEES DECHARGEMENT ET CHARGEMENT MASSIF DES DONNEES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et ne peuvent en aucun cas être

Plus en détail

Tri de cartes et ergonomie web

Tri de cartes et ergonomie web Tri de cartes et ergonomie web Sommaire Introduction 1. La méthode du tri de cartes 1.1. Principe et utilité 1.2. Les règles du jeu 1.3. Matériel pour le tri de cartes physique 1.4. Les données recueillies

Plus en détail

Télécom Nancy Année 2013-2014

Télécom Nancy Année 2013-2014 Télécom Nancy Année 2013-2014 Rapport 1A Ajout du langage C dans la Programmer's Learning Machine GIANNINI Valentin Loria 615, rue du Jardin Botanique 54600, Villers-Lès-Nancy Maître de stage : QUINSON

Plus en détail

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Projet Informatique Philippe Collet Licence 3 Informatique S5 2014-2015 http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Réalisation d'un développement de taille conséquente? r Firefox? Ph.

Plus en détail

RAPPORT DE CONCEPTION UML :

RAPPORT DE CONCEPTION UML : Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang RAPPORT DE CONCEPTION UML : Bamboo Ch@t Projet GM4 Juin 2006 Table des matières 1 Introduction 2 2 Présentation du logiciel 3 2.1 Précisions

Plus en détail

À propos du Programme d évaluation international des compétences des adultes, le PEICA

À propos du Programme d évaluation international des compétences des adultes, le PEICA Automne 2013 À propos du Programme d évaluation international des compétences des adultes, le PEICA Par Giselle Boisvert, conseillère pédagogique, Commission scolaire de Montréal Les données de la troisième

Plus en détail

Présentation du projet:

Présentation du projet: : Le but du projet est de réaliser le fonctionnement d'un jeu d échec valide. Plus spécifiquement, il consiste à implémenter l'organisation générale du jeu, et le suivi des règles du mouvement des pièces.

Plus en détail

E-LECLERC LEVALUATION DU SITE WEB. A. Evaluation «subjective» du site web. 1. Choix du site web. 2. Présentation le site A P I 0 8 1 1 / 0 3 / 2 0 1 4

E-LECLERC LEVALUATION DU SITE WEB. A. Evaluation «subjective» du site web. 1. Choix du site web. 2. Présentation le site A P I 0 8 1 1 / 0 3 / 2 0 1 4 LEVALUATION DU SITE WEB E-LECLERC A P I 0 8 1 1 / 0 3 / 2 0 1 4 A. Evaluation «subjective» du site web 1. Choix du site web J ai choisi de réaliser l évaluation «subjective» sur le site web : www.e-leclerc.com,

Plus en détail

La théorie des mouvements dans les formules Jean-François Nicaud Version initiale de Février 2013 jeanfrancois.nicaud@laposte.net

La théorie des mouvements dans les formules Jean-François Nicaud Version initiale de Février 2013 jeanfrancois.nicaud@laposte.net La théorie des mouvements dans les formules Jean-François Nicaud Version initiale de Février 2013 jeanfrancois.nicaud@laposte.net Article rédigé avec epsilonwriter puis copié dans Word La théorie des mouvements

Plus en détail

Shadow Manager Simulateur de gestion globale d entreprise. Introduction

Shadow Manager Simulateur de gestion globale d entreprise. Introduction Shadow Manager Simulateur de gestion globale d entreprise Introduction Le logiciel de simulation d entreprise Shadow Manager représente le nec plus ultra des outils pédagogiques de simulation de gestion

Plus en détail

OUTILS D'ÉVALUATION DE LOGICIELS ÉDUCATIFS

OUTILS D'ÉVALUATION DE LOGICIELS ÉDUCATIFS 131 OUTILS D' ÉDUCATIFS Philippe DESSUS, Pascal MARQUET MOTS-CLÉS Typologie des logiciels d'eao, Processus d'apprentissage, Mesure des performances didactiques. RÉSUMÉ A travers l'eao, l'informatique tente

Plus en détail

ANALYSE DE LA LECTURE DES FICHIERS XML

ANALYSE DE LA LECTURE DES FICHIERS XML ANALYSE DE LA LECTURE DES FICHIERS XML Jean Marie Epitalon, Mars 2010 CERFACS, Working Notes WN CMGC 10 20 Table des matières 1) Introduction...1 2) Architecture logicielle...1 2.a) La couche sasa_c...2

Plus en détail

Les composantes d'une application et la logique de programmation

Les composantes d'une application et la logique de programmation Chapitre 10 Les composantes d'une application et la logique de programmation Introduction La mise en situation propose d'étudier le principe de fonctionnement d'une application sous forme d'une base de

Plus en détail

Aplicaciones Informâticas en Arqueologia: Teorîas y sistemas. Saint-Germain-en Laye, 1.991. Bilbao

Aplicaciones Informâticas en Arqueologia: Teorîas y sistemas. Saint-Germain-en Laye, 1.991. Bilbao Aplicaciones Informâticas en Arqueologia: Teorîas y sistemas Saint-Germain-en Laye, 1.991 Bilbao L'ARCHEOLOGIE, SYSTEME D'INFORMATION SCIENTIFIQUE Patrick DESFARGES Bruno HELLY Un examen des banques de

Plus en détail

Méthodes de développement

Méthodes de développement 1 / 19 Méthodes de développement Guide de rédaction d'un plan de développement logiciel 1 - OBJET DU GUIDE... 2 2 - OBJECTIF DU PDL... 2 3 - PLAN TYPE DU PDL... 2 4 - TRAVAUX DE PRÉPARATION DU PDL... 2

Plus en détail

1 Exercice 1 Question de cours (4 points)

1 Exercice 1 Question de cours (4 points) Info32B Systèmes d'exploitation année 2013-2014 Examen (1ère session) 16 décembre 2014 N. Sabouret L'épreuve dure 2h30. Tous les documents sont autorisés. Les exercices sont indépendants. 1 Exercice 1

Plus en détail

Pourquoi créer un site Web?

Pourquoi créer un site Web? Créer mon site Web Vous avez une passion, un centre d'intérêt, un "hobbie", et vous souhaitez en parler, partager autour de ce sujet. Vous avez bien pensé à utiliser l'espace web pour faire connaître votre

Plus en détail

Présentation. Logistique. Résumé de la 1e Partie. Mise en place du système

Présentation. Logistique. Résumé de la 1e Partie. Mise en place du système Présentation Diapo01 Je m appelle Michel Canneddu. Je développe avec 4D depuis 1987 et j exerce en tant qu indépendant depuis 1990. Avant de commencer, je tiens à remercier mes parrains Jean-Pierre MILLIET,

Plus en détail

Rapport de projet. Animation de diagrammes d'état - CHAMPION Adrien - ETIENNE Thibaut RIZZI Thibaut 1A - INFO - Groupe EF - G36.

Rapport de projet. Animation de diagrammes d'état - CHAMPION Adrien - ETIENNE Thibaut RIZZI Thibaut 1A - INFO - Groupe EF - G36. Rapport de projet Animation de diagrammes d'état - CHAMPION Adrien - ETIENNE Thibaut RIZZI Thibaut 1A - INFO - Groupe EF - G36 Juin 2008 2 Table des matières 1 Introduction...5 1.1 - Objectif...5 1.2 Choix

Plus en détail

Conduite et Gestion de Projet - Cahier des charges

Conduite et Gestion de Projet - Cahier des charges Conduite et Gestion de Projet - Cahier des charges 1 Introduction Sophie Toulouse LIPN - Université Paris 13 +33.1.49.40.40.73 99 av. Jean-Baptiste Clément toulouse@lipn.univ-paris13.fr 93430 Villetaneuse

Plus en détail

Programmation récursive

Programmation récursive Année 2004-2005 F. Lévy IUT De Villetaneuse Dép t informatique Cours d'algorithmique 2 éme Année Cours 8 Programmation récursive 1. Qu'est-ce que la programmation récursive Définition : la programmation

Plus en détail

Analyse et conception des Systèmes d Information. La démarche Merise : La Production Logicielle

Analyse et conception des Systèmes d Information. La démarche Merise : La Production Logicielle Analyse et conception des Systèmes d Information La démarche Merise : La Production Logicielle La production du logiciel Place, objectifs et principes directeurs Christophe.Nicolle@u-bourgogne.fr Introduction

Plus en détail

Projet Interface de supervision avec RTW et LABVIEW

Projet Interface de supervision avec RTW et LABVIEW Projet Interface de supervision avec RTW et LABVIEW Encadré par M.Belkaem Ould-Bouamama Réalisé par Ilyas Mabrouk Shitao XING Polytech Lille Département Informatique Microélectronique Automatique Le 7

Plus en détail

TD1- Conception d une BDD et Utilisation sous Access et Oracle

TD1- Conception d une BDD et Utilisation sous Access et Oracle TD1- Conception d une BDD et Utilisation sous Access et Oracle Partie 1 - Conception Il s'agit de M. Bushboy, le directeur d'une agence de location de voitures qui vous a appelé (en tant qu'analyste expert)

Plus en détail

Introduction à Windows Workflow Foundation

Introduction à Windows Workflow Foundation Introduction à Windows Workflow Foundation Version 1.1 Auteur : Mathieu HOLLEBECQ Co-auteur : James RAVAILLE http://blogs.dotnet-france.com/jamesr 2 Introduction à Windows Workflow Foundation [07/01/2009]

Plus en détail

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

Projet Equadex techno 2008

Projet Equadex techno 2008 Création d une étape d imprimante Projet Equadex Techno 2008 Jeremy TYRIAUX Sommaire Introduction... 3 Problématique... 4 Trouvée... 4 Contrôle d accès à l imprimante... 8 Archivage des documents imprimés...

Plus en détail

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon Diagrammes UML (2) http://www.rzo.free.fr Pierre PARREND 1 Avril 2005 Sommaire Les Diagrammes UML Diagrammes de Collaboration Diagrammes d'etats-transitions Diagrammes

Plus en détail

Introduction au Makefile

Introduction au Makefile Introduction au Makefile Nicolas Kielbasiewicz 3 mars 2009 Le développement d un programme et plus généralement d un logiciel demande au(x) programmeur(s) de gérer plusieurs fichiers, voire plusieurs langages.

Plus en détail

Utilisation de Mathenpoche en classe de BEPA Vente de produits frais

Utilisation de Mathenpoche en classe de BEPA Vente de produits frais Utilisation de en classe de BEPA Vente de produits frais Professeur de Mathématiques et de Sciences Physiques LEGTA Bel Air Fontenay-le-Comte (85) 1/16 Table des matières 1 Problématique...4 2...5 2.1

Plus en détail

Guide pour la conception d'une application en C

Guide pour la conception d'une application en C Guide pour la conception d'une application en C Ph. Preux DESS IMST, ULCO Novembre 1999 1 Principes généraux Une application informatique, dès qu'elle dépasse une centaine de lignes de code, doit impérativement

Plus en détail

L essai de Psy.D. (18 crédits) Définition et balises

L essai de Psy.D. (18 crédits) Définition et balises L essai de Psy.D. (18 crédits) Définition et balises politique adoptée par le CECS le 6 novembre 2002 Suite à l adoption par le Comité des études de cycles supérieurs en psychologie du projet de modification

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

PLANIFICATION ET SUIVI D'UN PROJET

PLANIFICATION ET SUIVI D'UN PROJET Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Guide méthodologique PLANIFICATION ET SUIVI D'UN PROJET Référence : CNRS/DSI/conduite-projet/developpement/gestion-projet/guide-planfi-suivi-projet

Plus en détail

Résumé du document «Programmes des classes préparatoires aux Grandes Écoles ; Discipline : Informatique ; Première et seconde années - 2013»

Résumé du document «Programmes des classes préparatoires aux Grandes Écoles ; Discipline : Informatique ; Première et seconde années - 2013» Résumé du document «Programmes des classes préparatoires aux Grandes Écoles ; Discipline : Informatique ; Première et seconde années - 2013» I Objectifs Niveau fondamental : «on se fixe pour objectif la

Plus en détail

Mémoire de stage et soutenance

Mémoire de stage et soutenance Mémoire de stage et soutenance Le choix du sujet Le sujet du mémoire est défini avant le commencement du stage ou au début de celui-ci : il résulte d'une concertation entre le stagiaire et le maître de

Plus en détail

L INFORMATION GEOGRAPHIQUE

L INFORMATION GEOGRAPHIQUE Champs sur Marne ENSG/CERSIG Le 19-nove.-02 L INFORMATION GEOGRAPHIQUE Archivage Le Système d information géographique rassemble de l information afin de permettre son utilisation dans des applications

Plus en détail

Environnements de développement (intégrés)

Environnements de développement (intégrés) Environnements de développement (intégrés) JDT (débogage), outils d analyse statique Patrick Labatut labatut@di.ens.fr http://www.di.ens.fr/~labatut/ Département d informatique École normale supérieure

Plus en détail

De Jean-François Dauphin Département de l élaboration et de l examen des politiques

De Jean-François Dauphin Département de l élaboration et de l examen des politiques Bulletin du FMI SURVEILLANCE DES TAUX DE CHANGE Le FMI précise comment il surveillera les politiques économiques De Jean-François Dauphin Département de l élaboration et de l examen des politiques Le 12

Plus en détail

<< Crédit Club Auto >>

<< Crédit Club Auto >> Abbas Ahmad Année 2010/2011 Matin Bayramov Analyse et Modélisation des Systèmes Informatique (AMSI) Projet de Modélisation UML > Professeur encadrant : M. GUILLAUME PAQUETTE Projet

Plus en détail

Types et langages de programmation. Algorithmique et Programmation Unisciel/K.Zampieri

Types et langages de programmation. Algorithmique et Programmation Unisciel/K.Zampieri Types et langages de programmation Algorithmique et Programmation Unisciel/K.Zampieri 1 Généalogie partielle des langages de programmation FORTRAN BASIC PL/1 PROLOG ALGOL60 COBOL C PASCAL ADA MODULA-2

Plus en détail

LES COURS ONLINE. ar des étudiants our des étudiants. Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm

LES COURS ONLINE. ar des étudiants our des étudiants. Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm LES COURS ONLINE P ar des étudiants our des étudiants Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm CAHIER DES CHARGES I - Préface...4 II - Introduction...5 III - Glossaire...6

Plus en détail

Rapport de méthodologie:

Rapport de méthodologie: Rapport de méthodologie: "Laboratoire on chip/lab-on-chip/loc" REMARQUE : La méthode employée est en tout point similaire à celle utilisée en groupe. Contents Rapport de méthodologie:... 1 "Laboratoire

Plus en détail

Evaluation de votre conférence de méthode ou cours-séminaire

Evaluation de votre conférence de méthode ou cours-séminaire Enseignement : INTRODUCTION A LA SOCIOLOGIE 2 : CONCEPTS, METHODES, ET ENJEU ACTUELS Excellent Bon Moyen Insuffisant Comment évaluez-vous la préparation et l'organisation des séances? 6 (30%) 11 (55%)

Plus en détail

Développement du bois énergie : quel impact à terme sur le marché du bois en France?

Développement du bois énergie : quel impact à terme sur le marché du bois en France? Développement du bois énergie : quel impact à terme sur le marché du bois en France? Le développement du bois énergie va se traduire par une situation de concurrence entre les différents acteurs économiques

Plus en détail

Gestion de projet - la phase de définition du projet

Gestion de projet - la phase de définition du projet Gestion de projet - la phase de définition du projet GÉRARD CASANOVA - DENIS ABÉCASSIS Paternité - Pas d'utilisation Commerciale - Pas de Modification : http://creativecommons.org/licenses/by-nc-nd/2.0/fr/

Plus en détail

TD 2 - Modèles de calcul

TD 2 - Modèles de calcul TD 2 - Modèles de calcul Remarques préliminaires Si ou désigne une relation binaire (de dérivation/transition suivant le contexte), on notera ou sa clôture transitive, comprendre la relation obenue en

Plus en détail

Positionnement de UP

Positionnement de UP UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation

Plus en détail

Conclusions et Perspectives

Conclusions et Perspectives 8 Conclusions et Perspectives Ce chapitre conclut la thèse en donnant un bilan du travail effectué et les perspectives envisageables au terme de cette recherche. Nous rappelons tout d abord les principales

Plus en détail

Couples de variables aléatoires discrètes

Couples de variables aléatoires discrètes Couples de variables aléatoires discrètes ECE Lycée Carnot mai Dans ce dernier chapitre de probabilités de l'année, nous allons introduire l'étude de couples de variables aléatoires, c'est-à-dire l'étude

Plus en détail

5.1.1 La procédure pour la description d'une situation-problème

5.1.1 La procédure pour la description d'une situation-problème 5 LE CHOIX DES PARTIES DE COURS : UNE PROGRESSION DES APPRENTISSAGES Éléments du cinquième chapitre 5.1 La description de la situation-problème finale 5.1.1 La procédure pour la description d'une situation-problème

Plus en détail

3 Pseudo-code et algorithmes 26

3 Pseudo-code et algorithmes 26 TABLE DES MATIÈRES 1 Introduction à la programmation 1 1.1 Programme et langage de programmation 2 1.2 Étapes du développement des programmes 2 1.3 Notion d'algorithme 6 2 Notions de base 9 2.1 Constantes

Plus en détail

Table des Matières. Table des Figures 7. Introduction Générale 9. Chapitre 1 - Langages de description d architectures matérielles hybrides 23

Table des Matières. Table des Figures 7. Introduction Générale 9. Chapitre 1 - Langages de description d architectures matérielles hybrides 23 Table des Figures 7 Introduction Générale 9 1. Outils et plate-formes de construction d application 9 2. Intégration de paradigmes de conception dans le cycle de vie 10 2.1. Equilibrage de charge et équilibrage

Plus en détail

Méthode de Test. Pour WIKIROUTE. Rapport concernant les méthodes de tests à mettre en place pour assurer la fiabilité de notre projet annuel.

Méthode de Test. Pour WIKIROUTE. Rapport concernant les méthodes de tests à mettre en place pour assurer la fiabilité de notre projet annuel. Méthode de Test Pour WIKIROUTE Rapport concernant les méthodes de tests à mettre en place pour assurer la fiabilité de notre projet annuel. [Tapez le nom de l'auteur] 10/06/2009 Sommaire I. Introduction...

Plus en détail

Chapitre 2. Classes et objets

Chapitre 2. Classes et objets Chapitre 2: Classes et Objets 1/10 Chapitre 2 Classes et objets Chapitre 2: Classes et Objets 2/10 Approche Orientée Objet Idée de base de A.O.O. repose sur l'observation de la façon dont nous procédons

Plus en détail

PROGRAMME DES ÉPREUVES EXAMEN BTS NOTARIAT

PROGRAMME DES ÉPREUVES EXAMEN BTS NOTARIAT PROGRAMME DES ÉPREUVES EXAMEN BTS NOTARIAT www.imnrennes.fr ÉPREUVE E1 - CULTURE GÉNÉRALE ET EXPRESSION Coefficient 3 L objectif visé est de vérifier l aptitude des candidats à communiquer avec efficacité

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

INTRODUCTION GENERALE

INTRODUCTION GENERALE INTRODUCTION GENERALE Chaque année, les entreprises ont de nombreux challenges à relever; adaptation à des contraintes légales nationales, européennes ou internationales, lancement de nouveaux services

Plus en détail

Le client/serveur repose sur une communication d égal à égal entre les applications.

Le client/serveur repose sur une communication d égal à égal entre les applications. Table des matières LES PRINCIPES DE BASE... 1 Présentation distribuée-revamping...2 Présentation distante...3 Traitements distribués...3 données distantes-rd...4 données distribuées-rda distribué...4 L'ARCHITECTURE

Plus en détail

P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S

P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S MP deuxième années PREAMBULE Sommaire I. Contexte de la réforme de l informatique en C.P.G.E II. Objectifs de la formation III. Moyens

Plus en détail

Règles d affaires. éponse informatique inc. www.reponse.ca. Critères de qualité de toutes spécifications

Règles d affaires. éponse informatique inc. www.reponse.ca. Critères de qualité de toutes spécifications Règles d affaires éponse informatique inc. 1 Critères de qualité de toutes spécifications IEEE830-1998 Recommended Practice for Software Requirements Specifications Une spécification doit être: Correcte,

Plus en détail

MINI-MÉMOIRE DE PPP - S4

MINI-MÉMOIRE DE PPP - S4 MINI-MÉMOIRE DE PPP - S4 Par [OUAZAR ARIS-ARAB] [S4-G2] [AYME OLIVIA] TABLE DES MATIÈRES ANALYSE DE L ENTREPRISE # PRESENTATION DE L ENTREPRISE # LISTE ET DESCRIPTION DES DIFFERENTS METIERS REPRESENTES

Plus en détail

Apprendre la dichotomie avec Colobot

Apprendre la dichotomie avec Colobot Apprendre la dichotomie avec Colobot CHABALIER Nicolas MONCEL Arnaud Année Universitaire 2014 2015 1 Apprendre la dichotomie avec Colobot Présenté par CHABALIER Nicolas et MONCEL Arnaud Tuteur : Jacques

Plus en détail

Encadré par : Mr Philippe Janssen

Encadré par : Mr Philippe Janssen ABADIE Martin BENMOUFFOK Yasmine HEIDMANN Paul UTZEL Sylvain Encadré par : Mr Philippe Janssen 2014-2015

Plus en détail