Liste des projets 2008-2009


M2 I2L

CoreBoot : Etude et mise en oeuvre de la version 3 - Peter Stuge

Etudiants : Cédric Rivera

Résumé

Coreboot (anciennement LinuxBIOS) est un projet de logiciel libre approuvé par la Fondation pour le logiciel libre dans le but de remplacer les BIOS propriétaires que l'on peut trouver dans la plupart des ordinateurs qui sont des BIOS simples conçus uniquement pour ne proposer que le minimum de tâches suffisantes pour charger un système d'exploitation moderne de 32 bits. Le projet coreboot a été crée en 1999, il est sous licence publique générale GNU. Le 6 mars 2007, un développeur nommé Alan Carvalho de Assis, a franchi une étape avec l'élaboration d'un BIOS contenant un noyau Linux, un interprète de commandes, un serveur graphique, un gestionnaire de fenêtres et un terminal sur une puce de seulement 2 Mo.

Coreboot équipe notamment les ordinateurs fournis par l'association One Laptop per Child (un portable par enfant).

Le but de ce projet M2/I2L est de fournir le support de la version v3 de Coreboot sur des cartes mères ATX de qualité et produite en masse.

Authentification et autorisation sur postes clients - Loïc Dayot - Mairie de Pierrefitte

Etudiants : Romain Berthaud

Mots-clés : EPNadmin, MySQL, PHP, Linux, Windows, MacOS, OpenLDAP, système, pam, Samba

Contexte

EPNadmin est une application web libre (Licence GPL), ayant pour but d'administrer un EPN (Espace Public Numérique). Au cours de notre veille, nous avons relevé les fonctionnalités manquantes d'EPNadmin pour facilité son utilisation dans un EPN. Depuis la base utilisateurs d'EPNadmin, on peut s'authentifier pour l'application et les systèmes GNU/Linux et Windows. Nous souhaitons compléter cette interaction vers d'autre système et surtout ajouter un meilleur échange de données entre EPNadmin et les postes clients.

Objectifs

  • Remonté des informations début de session et fin de session sur les postes clients vers la base de données
  • Gestion des droits (ACL) sur les postes clients pour les différents types d'utilisateurs: Usager, Animateur, Directeur et Administrateur
  • Authentification sur les systèmes MacOS

Références

Développement pour Redmine - Paul Rivier - Demotera

Etudiants : Jonathan Druart

Contexte

Redmine est un outil de gestion de projet, spécialisé dans les projets informatiques. Il s'agit d'une application Web, conçue avec Ruby On Rails, donc multi-plateformes et multi-environnements. Le code source est libre et disponible selon les termes de la GPL V2. Parmi les applications web de gestion de projet, il s'agit du projet le plus dynamique. Redmine est respectueux des standards, utilise pleinement l'architecture MVC et les concepts de développement du framework Rails. Il est possible de consulter la liste complète des fonctionnalités, ainsi qu'une démonstration, sur le site www.redmine.org.

Demotera est une jeune entreprise dynamique qui propose une expertise en systèmes d'information aux entreprises du secteur de l'énergie et de l'environnement. Pour apporter à ces entreprises les moyens de conduire des projets sur le long terme, Demotera a mis au point une offre de service de gestion de projets, clefs en main. Cette offre se nomme Atik Team, et repose exclusivement sur des composants libres. Redmine est le composant « application web de gestion de projets ». Demotera facture la mise à disposition d'un accès à Atik Team, ainsi qu'une haute sécurité des données. Les développements de Demotera qui ont eu lieu sur Redmine pour l'améliorer globalement ont été renvoyés sur la branche officielle de développement, et intégrés. Ainsi, Demotera est actuellement l'un des développeurs actifs de Redmine. L'essentiel de ce développement a pour objectif de généraliser l'utilisabilité de Redmine dans des projets de tous types, et non uniquement informatiques. Vous pouvez obtenir plus d'information sur le site web de Demotera : www.demotera.com.

Objectifs

Les utilisateurs de Redmine et de Atik Team manipulent des ressources pour organiser les projets. Parmi ces ressources se trouvent des pages wiki de documentation, des tickets, des jalons, des annonces, des messages de forums et bien d'autres. Une syntaxe wiki est fournie pour faire des liens entre les ressources. Pour le moment, l'utilisateur est forcé d'utiliser 2 ou 3 fenêtres/onglets de navigateur pour faire son lien. La première est la fenêtre utilisée pour rédiger le document qui comporte un lien. La seconde est utilisée pour naviguer dans l'application afin de trouver l'identifiant correspondant sur la page. Enfin, une 3ième est généralement nécessaire pour se souvenir de la syntaxe à utiliser selon le type de ressource. Ce fonctionnement est pour le moins peu pratique, et est même considéré comme inutilisable par les utilisateurs débutants.

Une excellente réponse à cette limitation serait de proposer une vue navigable des ressources que l'utilisateur peut lier, directement depuis la fenêtre d'édition du document. Afin de ne pas submerger l'affichage, il faudrait que la navigation soit dynamique et incrémentale, ainsi l'utilisateur pourra naviguer simplement jusqu'à sa ressource. Les informations affichées doivent permettre d'identifier rapidement la ressource recherchée. Ensuite, un lien est généré à partir du type de ressource et de son identifiant. Plone (www.plone.org) propose ce type de dispositif, qui se révèle très efficace.

Modalités

L'implémentation devra s'intégrer proprement à la version de développement de Redmine. Les concepts de MVC, et plus globalement d'architecture Rails devront être respectés, ainsi que les dispositifs de sécurité et de permissions utilisés par Redmine. Le recours à AJAX est à prévoir. Il faut compter au moins 30 heures pour se familiariser avec le code de Redmine, et la même chose pour proposer un développement propre, avec une bonne qualité de finition. Dans le cas où l'étudiant disposerait de temps supplémentaire, il pourra travailler sur des fonctionnalités mineures liées, ou sur des corrections de bugs. L'étudiant devra apprendre à utiliser les fonctions avancées d'un gestionnaire de versions décentralisé, de préférence Git ou Mercurial. Tous les outils de travail utilisés doivent être libres et fonctionner sur au moins un environnement totalement libre (de préférence GNU/Linux ou *BSD). Enfin, l'étudiant devra adapter son développement aux retours de la communauté, avec laquelle il communiquera en Anglais uniquement.

Firebird : tests Assurance Qualité - Philippe Makowski et Pavel Cisar - IBPhoenix

Etudiants : Gaëtan Pagnerre et Nicolas Cocquerel

Mots-clés : Firebird, test qualité, python, SGBD et Subversion

Contexte

Le projet Firebird (SGBD libre sous licence IDPL) en plus du travail de relecture et audit du code utilise qmtest pour effectuer une batterie de tests avant la livraison de toute nouvelle version

Objectifs

Travailler avec la Q/A team de Firebird afin de créer des nouveaux tests, vérifier les bugs fermés par les developpeurs, ajouter des nouveaux tests, améliorer les outils Python utilisés par la Q/A team.

Langages et technologies

  • Python,
  • qmtest
  • Firebird
  • Subversion

Références

Firebird : Pilote Python pour Firebird - Philippe Makowski et Pavel Cisar - IBPhoenix

Etudiants : ??

Mots-clés : Firebird, python, SGBD et Subversion

Contexte

Le projet Firebird (SGBD libre sous licence IDPL) maintient le pilote kinterbasdb initialement écrit pour Interbase et Firebird. Le projet souhaite modifier ce pilote et le rendre plus efficace

Objectifs

Travailler Pavel Cisar responsable du pilote Python de Firebird afin de réécrire ce pilote en pur Python en s'appuyant sur le protocole réseaux de Firebird, à l'image du pilote JDBC Jaybird.

Langages et technologies

  • Python,Java
  • Firebird
  • Subversion

Références

Infrastructure de tests automatisés pour IPSec - Yvan Vanhullebus - FreeBSD

Etudiants : ??

Mots-clés : Virtualisation, sécurité, réseau, IPSec, scripting

Objectif

Mettre en place une infrastructure de tests automatisés pour le projet opensource ipsec-tools et les piles IPSec qui l'utilisent (au moins Linux 2.6+, FreeBSD et NetBSD).

Parmi les objectifs de l'infrastructure, on peut citer:

  • utilisation massive de machines virtuelles pour les tests
  • niveau d'abstraction pour décrire les tests
  • outils de génération des machines virtuelles et des configurations à partir des descriptions de tests
  • tests de cas fonctionnels (non-régression)
  • tests de cas anormaux (fuzzing, attaques connues, etc...)
  • génération automatique d'un rapport de tests
  • possibilite d'exécuter un seul test, une liste de tests, ou l'ensemble des tests
  • possibilite d'exécuter des tests sur une combinaison précise (OS+version précise, version précise d'ipsec-tools) ou sur un ensemble de combinaisons de versions.

Cette infrastructure pourra se baser sur un éventuel projet opensource existant, ou être une implémentation "from scratch", qui sera alors ultérieurement publiée sous licence BSD en tant qu'outil du projet ipsec-tools.

La mise en place de toutes les fonctionnalités avancées est optionnelle dans le cadre de ce projet (mais les choix effectués devront faciliter l'implémentation ultérieure de ces fonctionnalités).

La rédaction des tests eux-mêmes est également optionnelle dans le cadre de ce projet (mais au moins un ou deux tests triviaux devront être créés pour valider le bon fonctionnement du système).

Outil de migration SPIP vers Drupal - Pierre-Yves Gosset - Framasoft.net

Etudiants : Thibault MARTIN

Mots-clés : cms, php, mysql, module, drupal, spip, import, export

Description

Ce projet consiste en la conception, le développement et la documentation d'un outil (ou ensemble d'outils) de migration du CMS SPIP vers le CMS/Framework Drupal. Idéalement, ce projet se concrétisera par la réalisation d'un module Drupal, qui s'interfacera à une base de données MySQL SPIP, identifiera les données à importer, et importera ces dernières au sein de la base de données Drupal, dans un "content type" Drupal spécifique.

Contexte

SPIP est un CMS aux nombreuses qualités, et très largement utilisé en France par tous types d'institutions (associations, entreprises, écoles/universités). Cependant, de nouveaux CMS sont apparus sur le marché, de structure plus robuste et extensible. Drupal fait parti de ceux-là. Sachant que SPIP (même avec une version 2 dans les starting blocks) est un CMS vieillissant, nous anticipont une forte demande pour un outil permettant de faire la transition entre ces deux outils (à commencer par le site Framasoft.net). Il serait bien entendu possible de se contenter de simple scripts d'imports/exports, mais la structure du code de Drupal en fait un framework suffisamment puissant pour que l'étudiant en charge du projet développe un module SPIP=>Drupal qui lui permettra d'appréhender la conception de modules Drupal, tout en se confrontant aux problématiques de gestion de données pour les applications web (backup, stockage, encodage, schémas, importation, vérification, traitement des erreurs, etc)

Contraintes

Les cas pouvant être extrêmement divers, l'étudiant pourra concentrer ses efforts sur le développement d'un module permettant l'import/export entre 2 versions "standard" des CMS en question (SPIP 1.9 "out of box" et Drupal 6 + module CCK) afin de proposer un module générique.

Gestionnaire de contenus pour Windows - Pierre-Yves Gosset - Framasoft.net

Etudiants :

Mots-clés : package, windows, python, synaptic, aptitude, catalogue, framakey

Description

Ce projet consiste dans le développement d'un outil permettant de gérer localement des contenus libres sous système Windows par le biais d'un portail/catalogue en ligne. Il s'agit donc d'un Synaptic (ou d'un Aptitude) pour Windows. L'utilisateur télécharge l'application, qui ne contient alors aucune application libre. Le logiciel lui propose d'ajouter des logiciels libres qui iront s'ajouter dans l'arborescence de l'application. Ces logiciels sont en réalité des logiciels portables (= capable de fonctionner en vase clos au sein de leur dossier, sans installation, et en laissant un minimum de traces sur la machine hôte). Ces logiciels portables répondent à une certaine « norme », notamment l'adjonction d'un fichier décrivant les caractéristiques de l'application (nom, description, etc). Ils sont compréssés au format .zip et diffusés via un « dépôt d'applications portables » auquel l'application peut se connecter pour ajouter de nouveaux logiciels. L'application se charge de leur téléchargement, décompression, puis de les afficher au sein d'une interface conviviale.

Contexte

Selon notre expérience, les principales raisons de la faible diffusion des logiciels libres auprès du grand public sont :

  • manque de « publicité » (au sens noble du terme),
  • difficulté de téléchargement (ex: utilisation de la zone Download de sourceforge.net, rédhibitoire pour certains utilisateurs),
  • orientation « produits » et non « besoins » (ex : « Audacity » et non « Manipulation de fichiers audio »)

Une telle application permettrait de pallier de façon cohérente et simultanée à ces trois problèmes, élargissant ainsi très sensiblement la base d'utilisateurs de logiciels libres, donc accroissant mécaniquement à terme le nombre de développeurs de ces logiciels.

La démonstration d'un tel logiciel peut être trouvée dans la vidéo suivante : http://www.framablog.org/index.php/post/2008/09/03/la-framakey-se-fait-plus-belle-pour-la-rentree (disponible au format Xvid) Une version alpha peut être téléchargée sur le site http://www.framakey.org

Contraintes

Il s'agit d'un logiciel dédié aux systèmes Windows. Par conséquent, on sort peut être du cadre "utiliser exclusivement des outils libres" du projet étudiant I2L. Cependant, rien n'empêche de développer le projet dans un langage/framework multiplateforme, tel que Python. En effet, peu importe que les logiciels téléchargés par l'application ne s'executent pas sous Linux, l'essentiel est que l'application arrive à se connecter au catalogue, et soit apte à télécharger le .zip du logiciel et à le décompresser.

L'étudiant pourrait choisir soit d'améliorer la version alpha existante, ou repartir "from scratch". Python me paraitrait être le meilleur langage pour développer tout ou partie de l'application. Un (ancien) cahier des charges peut être trouvé à cette adresse : http://www.framakey.org/Winaptic/Index

Développer une boutique en ligne (e-commerce) pour le CMS iKaaro - Sylvain Taverne - Itaapy

Etudiants : Thomas Nouret et Benoît Parmentier

Mots-clés : Web, CMS, e-commerce, Python, itools

Contexte

Le CMS ikaaro, écrit en Python, dispose de plusieurs modules de haut niveau, tel un Wiki ou un Tracker.

Un projet de développement d'une boutique en ligne pour iKaaro a été amorcée l'année derniére par Sylvain Taverne, ancien étudiant de M2 I2l (Promotion 2008-2009) aujourd'hui salarié chez itaapy. La communauté de ikaaro souhaite améliorer la boutique et sa surface fonctionnelle.

Objectifs

Développer une boutique en ligne (Shop), pour commerce électronique, dans le paquet ikaaro.

  • Prendre en main le CMS iKaaro
  • Prendre en main le module de boutique en ligne
  • Ajout/améliorations de fonctionnalités (Gestion stock, gestion des commandes, des paiements ...)
  • Ajout de modules de paiements (paypal, paybox ...)

De nouveaux besoins seront définis en fonction de l'avancement des étudiants.

Utiliser GMainLoop de GLib pour le serveur web d'itools - J. David Ibanez - Itaapy

Etudiants : ??

Mots-clés : C, Python, GLib, itools, serveur web

Contexte

La librairie itools (écrite en Python) inclut un serveur Web. Ce serveur dispose d'une boucle principale (main loop) qui attend de nouvelles requêtes HTTP des clients (typiquement un navigateur) et les traite de manière asynchrone.

Pour ce faire, aujourd'hui le serveur web utilise soit la fonction "poll" soit la fonction "select" (si "poll" n'est pas disponible). Cette façon de faire n'est pas optimale du point de vue performance, puisque les systèmes d'exploitation offrent souvent d'autres fonctions plus performantes. Elle pose également des problèmes de portabilité, si aucune des deux fonctions n'est disponible.

Objectifs

A la place de faire nous même cette opération l'idée est de faire confiance à une autre librairie, et en particulier la GLib, puisque itools en dépend déjà et que la GLib fournit cette fonctionnalité à travers la structure GMainLoop.

Le but est donc de réécrire le code concerné en utilisant la structure GMainLoop de GLib.

Pour mener à terme cette tâche il faudra soit utiliser un "wrapper" Python pour la GLib, soit écrire le bout de code nécessaire en C, soit utiliser le module ctypes. A voir.

Il faudra aussi tester et mesurer les performances de la nouvelle version sur différentes plateformes.

Références

Migrer ikaaro à Python 2.6 et 3.0 - J. David Ibanez - Itaapy

Etudiants : Aurélien Ansel et Guillaume Romanczyk

Mots-clés : Python, itools, ikaaro

Contexte

La librairie itools et le CMS ikaaro sont écrits dans le langage Python. En particulier ils requièrent la version 2.5 (2.5.2 pour être plus précis).

Or les versions 2.6 et 3.0 sont attendues pour le mois d'Octobre. Python 2.6 est censé être une version de transition vers 3.0

Objectifs

Cette tâche va se diviser en plusieurs phases différentes et clairement distinctes:

  • D'abord il faudra tester itools et ikaaro avec Python 2.6, et apporter les correctifs nécessaires, sans abandonner le support de la version 2.5. Ces correctifs pourront être appliqués aussitôt.
  • Ensuite on abandonnera le support de Python 2.5, en utilisant des fonctionnalités spécifiques à 2.6, tel que les imports relatifs.
  • Enfin la mis à jour à Python 3.0 démarrera, même si des difficultés diverses rendront la tâche difficile à finir, notamment à cause des dépendances des paquets tiers dont itools et ikaaro ont besoin (tel reportlab et PIL).

Références

Ikaaro ACL avec LDAP - Nicolas Deram - Itaapy

Etudiants : ??

Mots-clés : Python, LDAP, ikaaro, ACL

Contexte

Le CMS ikaaro inclut une base d'utilisateurs stockée dans sa base de données fichier sous la forme de fichiers XML. Les ACL sont également stockés dans des fichiers XML.

Objectifs

Connecter le CMS ikaaro à un annuaire LDAP.

Références

Développer une algèbre d'opérations pour un système de fichiers transactionnel - David Versmisse - Itaapy

Etudiants : ??

Mots-clés : Python, itools, algèbre, database

Contexte

La librarie itools inclut un système de base de données qui ajoute une couche transactionnelle au système de fichiers.

Une séquence d'opérations (comme créer un nouveau fichier, effacer un autre, ajouter quelques informations à un troisième, etc.) est réalisée de façon atomique : tout ou rien.

Or l'implémentation actuelle n'est pas optimale dans certains cas. Par exemple aujourd'hui l'opération pour changer un fichier de répertoire est traduite en deux opérations : copier le fichier, puis effacer l'original ; cela qui n'est évidement pas performant.

Objectifs

Pour bien optimiser les accès au disque et garder la sémantique d'une séquence d'opérations donnée, il faudra (a) supporter plus d'opérations à bas niveau et (2) disposer d'un algorithme pour réordonner les opérations de façon optimale.

Pour ce faire une "algèbre" sera formalisée :

  • D'abord il faudra définir l'ensemble des opérations qui vont être supportés.
  • Puis définir les règles qui lient ces opérations. Par exemple, si (1) on modifie le fichier "A", puis (2) on l'efface, ces deux opérations se réduisent à une seule : effacer le fichier.
  • Un algorithme sera défini pour transformer une séquence donnée en une autre qui est optimale dans le sens où les accès au disque sont minimisés, et qui donne le même résultat (garde la même sémantique).
  • Cet algorithme sera implémenté en remplacement du code actuel (dans itools.handlers.database).
  • Des tests unitaires seront fournis pour vérifier la validité des résultats.

Cette tâche demande, en plus de compétences en programmation, des capacités à formaliser.

Références

Boutique en ligne pour le CMS libre Drupal - Arnaud Lewandowski

Etudiants : Clément Reynoudt et Pascal Tiebot

Description

L'objectif est de concevoir et de développer une boutique en ligne (e-commerce) sous forme de module(s) intégrable(s) au CMS libre Drupal. La boutique devra notamment gérer :

  • catalogue de produits
  • panier
  • paiement en ligne

Le projet consistera :

  • à définir de manière précise le cahier des charges fonctionnel en étudiant les solutions existantes ;
  • à définir l'architecture de la solution en fonction de l'API de Drupal ;
  • enfin, à développer la solution.

Par ailleurs, il est bien entendu que l'étudiant devra participer de manière active au développement/déboguage des modules de Drupal dont il va se servir.

SAC: Secure Access Checker - Sebastien Tricaud - INL

Etudiants : Cédric Fabianski et Matthieu Schneider

Remarque : Nous avons besoin pour ce projet de deux personnes.

Mots-clés

  • Intrusion
  • Sécurité
  • Protocoles
  • Réseau
  • Python

Contexte

INL soutient et développe des logiciels libres de sécurité informatique. Le logiciel phare étant Nufw, un pare-feu authentifiant.

Le besoin de sécurité dans les entreprises étant nécessaire et la négligence de la véritable sécurité des installations apparait.

Certains services offrent des accès dits sécurisés, tandis que d'autres ne le sont pas. Le point commun entre les deux est généralement le mot de passe qui reste le plus souvent identique. Cela rend caduque les accès sécurisés.

Objectifs

Répondre au besoin de sécurité des entreprises en s'assurant que les accès qui ne sont pas sécurisés n'aient pas les mêmes types d'authentification que ceux qui le sont.

Cela s'intégrera à de la détection d'intrusion et offrira un mécanisme de corrélation pour offrir à d'autres composants une meilleure connaissances des vulnérabilités exploitables d'un réseau.

Le but du projet sera d'arriver à utiliser les outils existants afin de permettre de détecter et prévenir les intrusions sur le réseau à cause de mots de passe pouvant facilement être récupérés.

Langage : Python

Technologies : Linux, Windows, Reseau, Ethereal

Références

Plate-forme Web pour la gestion des plans d'expériences de VLE et Mexico - Eric Ramat - INRA/LIL/ULCO

Etudiants : Danièle Vanbaelinghem et Grégory Wisniewski

Mots-clés

  • développement Web
  • exécution sur cluster

Présentation du projet

VLE est aujourd'hui disponible sous forme d'un exécutable modulaire pour la simulation de modèles à base d'événements discrets. Il s'accompagne aussi d'outils d'interface comme gvle ou eov pour la construction de modèles, l'exécution d'expériences simples et de visualisation temps-réel des simulations. Ces outils sont plutôt orientés mono-postes mais si la visualisation temps-réel peut être déportée par rapport au noeud d'exécution de la simulation.

Dans ce projet, on se propose de construire, à partir d'un cluster de 8 serveurs SUN V20Z bi-processeurs et d'un serveur bi-processeur, un "petit" serveur de démonstration de vle en mode cluster. Ce serveur doit aussi embarquer un dépôt de modèles vle et des interfaces de gestion des expériences.

Objectif

L'objectif est de proposer une interface Web pour la définition et l'exécution de plans d'expériences. Il se découpe en plusieurs sous-projets :

  • le cluster :
    • recherche d'une distribution adéquate pour le clustering et installation sur le cluster
    • installation du noeud root et déploiement de l'architecture Web
  • les plans d'expériences :
    • étude de la solution de développement Web (Python) :
      • pour le framework Web : Pylons (le livre)
      • pour la persistance : SQLAchemy et SQLite (un livre)
      • pour les templates : Mako
      • pour l'AJAX : jQuery (communauté française)
      • pour l'URL dispatching : Routes
      • les paquets debian : python2.5, python-pylons, python-authkit, python-sqlalchemy, sqlite3, python-mako, libjs-jquery et python-routes (plusieurs paquets s'installent lors de l'installation du paquet python-pylons)
    • développement des scripts de définition d'un plan d'expériences simple (au sens VLE)
    • développement de scripts de définition de plan d'expériences complexes (au sens Mexico)
  • l'interface utilisateur :
    • gestion des accès (voir AuthKit de Pylons)
    • gestion des plans (archivage)
    • gestion des modèles (dépôt de modèles VLE - ssh via des comptes sur le serveur)
  • l'exécution sur le cluster :
    • exécution des plans sur le cluster
    • visualisation de la progression de l'exécution des plans
    • reporting d'exécution des plans
  • tracé de courbes de résultats avec matplotlib et SciPy à partir des sorties de simulations
    • courbes 2D (sortie, temps)
    • grilles (avec choix de la date de l'état à visualiser)
    • possibilité d'animation ???

Langages et technologies

  • Python - Pylons
  • Linux/clustering
  • bases de données

Scolaritenet - Eric Ramat - INRA/LIL/ULCO

Etudiants : Frédéric Glasset et Hervé Poulain

Mots-clés

  • Application Web, Python/Ajax, aspect communautaire

Environnement de travail

Linux/Debian, git, vim (pour les puristes) ou emacs.

Contexte

Depuis six ans, nous développons une application de gestion d'une scolarité d'une université. Cette application est développée autour d’un serveur Web et d’une base de données SQL (MySQL, par exemple). Les sources sont disponibles via un serveur CVS (gestion des versions) sur http://adullact.net/projects/scolaritenet/, une version de démonstration est disponible sur http://scolaritenet.free.fr et vos emplois du temps sont réalisés grâce à cet outil.

Les fonctions assurées par la dernière version sont les suivantes :

  • Gestion sécurisée des accès via des sessions
  • Différents modes de travail (administrateur, gestionnaire, professeur, étudiant …)
  • Gestion des utilisateurs, des enseignants, des étudiants, des promotions, des groupes, des enseignements, des calendriers de vacances et jours fériés …
  • Planification des enseignements (différents modes) et gestion des modifications
  • Consultation des emplois du temps via Internet
  • Construction automatique de documents administratifs pour les enseignants
  • ...

Objectifs

L'objectif principal du projet est de migrer l'application sous le framework Web Pylons :

  • pour le framework Web : Pylons (le livre)
  • pour la persistance : SQLAchemy et SQLite (un livre)
  • pour les templates : Mako
  • pour l'AJAX : jQuery (communauté française)
  • pour l'URL dispatching : Routes
  • les paquets debian : python2.5, python-pylons, python-authkit, python-sqlalchemy, sqlite3, python-mako, libjs-jquery et python-routes (plusieurs paquets s'installent lors de l'installation du paquet python-pylons)

Il reste aussi quelques fonctionnalités :

  • installation : créér une procédure d'installation. Certains éléments doivent être paramétrable.
  • groupe virtuel : je pense qu'il faut gére les groupes virtuels comme des dépendances entre les diplômes ou options ou groupes. La table dépendance indiquerait que si quelque chose est planifié pour un groupe alors les groupes dépendants de ce dernier doivent subir la même chose. Je pense que ça simplifie les choses.
  • affichage des emplois du temps : les infos affichées dans les créneaux horaires devraient être spécialisée ... à revoir en fonction du type de login.
  • réécriture du script de placement des enseignements dans la semaine à l'aide de Ajax.
  • intégration de feuilles de styles
  • refonte le site de démonstration et créer un site communautaire

Langages et technologies

  • HTML, JavaScript, Python et SQL

M2 ISIDIS

Implémentation d'un Système à base de connaissances pour l'analyse d'impacts des modifications - Henri Basson

Etudiants : ??

Description

L'évolution des applications distribuées de composants constituants, de leurs instances, est un processus difficile à mener pour la pérennité de Systèmes d'Information évolutifs.

Dans ce cadre, l’analyse de l'impact des modifications d’un composant sur le reste de l’application est une activité critique pour une bonne gestion de l’évolution. Pour y parvenir plusieurs approches ont été élaborées. Celle qui semble être la moins lourde à réaliser s’appuie sur une approche intégrée de modélisation des applications distribuées. Elle consiste ensuite à appliquer une approche à base des règles permettant d’inférer les chemins de propagation des modifications et d’aider au contrôle de l’évolution.

Les données représentatives de l’application constituent une base des faits sur laquelle s’appuie un moteur d’inférence constitué des règles Drools et dont le finalité est d’aboutir à une analyse précise et exhaustive de l’impact de modifications envisagées.

Ce travail est déjà partiellement exploré.

Langage d’implémentation : Java, JESS, Plateforme Eclipse

Développement pour Eolis (société de production d'énergie éolienne) - Henri Basson

Etudiants : Hassan Soueidan et Dany Trabolsy

Description

Le service informatique de la société Eolis a déjà commencé un projet en java/J2EE avec un étudiant en stage l'année dernière et souhaite continuer la deuxième partie du projet avec l'étudiant en question après l'accord de l'université. Le projet consistait à développer un site intranet qui permet d'importer des rapports de données reçus automatiquement par les différentes machines de nos différents parcs éoliens concernant l'étude de vent. Cette partie a été finie avec l'objectif atteint par le stagiaire.

La deuxième partie du projet consiste à rajouter au site en question les différents éléments nécessaires pour réaliser les calculs dont nous avons besoin sur les rapports importés(Calcul des pertes, Statistiques et réalisation des rapports mensuels à fournir à la direction de l'entreprise).

Une réunion hebdomadaire sera organisée pendant l'année scolaire afin d'atteindre les objectifs souhaités.

Génération des composants Java à partir de la spécification des architectures logicielles en AADL - Henri Basson

Etudiants : ??

Description

La gestion de l’évolution des applications distribuées est une activité complexe et critique. Elle nécessite l'utilisation d’outils d'assistance aux développeurs chargés de l'évolution à décrire, comprendre et analyser les applications. Ces outils doivent être dotés d’une représentation complète et précise des composants et des liens précis entre ses composants.

Les diagrammes de conception semi-graphiques tels que ceux introduits par UML, etc. permettent d'avoir une vision peu précise sur l'architecture des applications et les liens entre différents types de composants. Ceci explique l’apparition de plusieurs langages de conception et de description précise des architectures logicielles pour assister l’ensemble des processus du développement et d’évolution des applications distribuées, des styles architecturaux et des ADLs (Architecture Description Language).

Ce projet consiste, après familiarisation avec la notion d'architecture logicielle et la conception architecturale d’application écrite en AADL (Avionics Architecture Description Language), de partir des fichiers de conception sauvegardés en format XML, pour en générer l’implémentation des composants en java ou C# .

Langages de programmation : Java ou C#, Plateforme Eclipse ou .NET (Visual studio 2008)

Développement pour l'outil de géolocalisation MapInfo - Valère Fagot - CCI Calais

Etudiant : Anthony Courquin et Florian Renaut

Résumé

  • Mise en place d'une interface de mise en relation de notre outil de géolocalisation mapinfo avec E-Racine, en vue d’une mise à jour hebdomadaire automatisée de notre observatoire du commerce.
  • Définition de toutes les pistes d’exploitation de l’observatoire : statistiques, cartographie, photographies, prospection…

Refonte d'un outil de chat sous Eclipse - Grégory Bourguin et Arnaud Lewandowski

Etudiants : ??

Objectif

Dans le cadre du projet CooLDev, nous avons créé un outil de chat sous forme de plugin Eclipse permettant aux utilisateurs d’échanger de manière synchrone. Ce chat a été réalisé en se fondant sur la technologie JSDT de Sun. Malheureusement, JSDT possède des limites qui posent problème dans l’utilisation de notre outil en situation réelle. Le but de ce projet est donc d’opérer une refonte du plugin de chat existant en changeant principalement sa couche réseau.

Etapes :

  • Découverte de l’environnement de création de plugins Eclipse
  • Etude des problèmes liés au plugin de chat existant
  • Sélection d’un protocole réseau adéquat
  • Refonte du plugin

Développement d’un site web : Semiotics of Law - Anne Wagner et Arnaud Lewandowski

Etudiants : Christopher Deboom

Contexte

Depuis 20 ans, la sémiotique juridique s’est développée dans le monde et nous souhaitons rendre nos travaux de recherche, nos bases de données, nos références bibliographiques visible sur le Net à tous ainsi que de créer un forum de discussion et des accès sécurisés pour nos membres afin de présenter des travaux en cours.

Objectif

L'objectif est de proposer une solution web assurant les fonction suivantes :

  • Présentation dynamique du site avec des informations sources et clefs pour tout public sur nos différents axes de recherche.
  • Gestion sécurisée des accès via des sessions
  • Différents modes de travail (administrateur, comité scientifique, membres)
  • Planification des différentes conférences et gestion des modifications
  • Mise en place d’une base de données de nos membres et mise à jour automatique
  • Mise en place des CV du comité scientifique avec possibilité de remise à jour
  • Construction automatique de références bibliographiques et gestion des modifications par l’administrateur.
  • Mise en place d’un intranet avec forum de discussion sécurisé

Qualification d’une Suite de BI (Business Intelligence) - Mourad Bouneffa

Etudiants : Mokrane Brahim et Kherbouche Mohammed Oussama

Objectif

Le BI ou Business Intelligence fait partie de ce qui est communément appelé l’informatique décisionnelle. Le but de la BI est d’extraire de la connaissance à partir d’informations brutes. La connaissance peut être schématisée par des tableaux d’analyse, des cubes, ou même des règles, etc. Une suite de BI est généralement formée de plusieurs outils incluant :

  • des outils d’extraction de données à partir des systèmes opérationnels
  • des outils de consolidation et d’agrégation des données dans un entrepôts de données ou datawarehouse
  • des outils d’explorations des données agrégées (reporting, etc.)
  • des outils d’extraction de connaissances (datamining, etc.)

Pendant de nombreuses années, les suites de ce type étaient réservées aux grands comptes et coûtaient très chers. On assiste actuellement à l’émergence de suites de BI libres dont les plus connues sont Talend et penTahao

Ce sujet de projet s’appelle « Qualification d’une Suite de BI » car on veut y suivre l’approche qu’adoptent les entreprises d’ingénierie informatiques afin de sélectionner une technologie pour la proposer à leurs clients. Le choix initial du projet se porte sur la suite pentaho.

Il s’agit donc de

  • l’apprentissage basique de cette suite. Cet apprentissage doit se solder par un rapport de type manuel d’utilisation.
  • La définition d’une application Pilote
  • L’implémentation de cette application en utilisant la suite Pentaho.

Parallélisation d'un simulateur de "Tetris" sur carte Nvidia 8800 - Amine Boumaza et Denis Robilliard

Etudiants : ??

Objectif

Paralléliser sur GPU (cartes graphiques à haute puissance de calcul) un simulateur de jeu de Tetris. Ce projet s'inscrit dans le cadre d'une compétition sur le meilleur joueur artificiel de Tetris (voir sur YouTube), avec pour objectif d'améliorer le programme vainqueur en titre actuellement. Les GPUs cibles seront des Nvidia série 8000 et au-delà, programmés en langage CUDA.

Plan de réalisation

  • prise en main de la version actuelle (en C)
  • découverte du langage CUDA, extension du C à la programmation parallèle sur GPU Nvidia
  • parallélisation du code
  • tests de performance

Site de vente en ligne - Mourad Bouneffa

Etudiants : Luca Antonini

Description

Il s'agit de la réalisation d'un site de vente en ligne pour la SARL L'HOER Ameublement à Boulogne-sur-mer.

Evolution perfective d'un progiciel intégré de gestion: MiErp - David Leporcq et Mourad Bouneffa - Maîtrise Informatique/LIL/ULCO

Etudiants : ??

Description

L'entreprise Maîtrise Informatique a développé un Progiciel Intégré de Gestion full Web appelé MiErp. Ce logiciel, entièrement développé en Php/Mysql, intègre les modules principaux de la gestion d'une entreprise telle que la gestion commerciale, la comptabilité, la gestion des stocks, etc.

MiErp a été conçu de manière à pouvoir être enrichi et évouler d'une façon aisée. En effet, tous les modules sont constitués de composants (classes) facilement réutilisables et extensibles.

Le but de ce projet est de partciper à l'évolution de MiErp et cela en intégrant les évolutions suivantes :

  • L'intégration de capacités de Workflow pour une meilleure adaptabilité et une meilleure reconfiguration de MiErp. En effet, MiErp est constitué de modules qu'il serait préférable d'adapter aux procédures de chaque entreprise.
  • La participation à l'évolution des différents modules de MiErp et plus particulièrement du module de gestion des stocks.

Dans le cadre du projet Workflow, les étudiants devront d'abord se documenter sur les différents concepts, méthodes et outils de ce domaine. Cela va permettre de sélectionner des outils existant ou d'opter pour un développement ad hoc dont les capacités seront moins riches qu'un outil existant mais qui serait éventuellement plus adaptés à MiErp.

Modifications/améliorations du logiciel Marsouin - Cyril Fonlupt et Denis Robilliard

Etudiants : ??

Description

Le logiciel Marsouin est un logiciel développé au sein du Laboratoire d'Informatique du Littoral utilisé par l'IFREMER (Institut Français de Recherche et d'Exploitation de la Mer) qui permet de reconnaître de manière automatique des tourbillons dans les océans à partir de cartes de courants provenant de différentes sources (satellites, simulations hydrodynamiques, ...).

Les tourbillons sont automatiquement numérotés, leurs surfaces sont évaluées ainsi que diverses informations utiles pour les chercheurs de l'IFREMER (sens du courant, centre du tourbillon, ...)

Fichier:Marsouin1.jpg

Les fichiers fournis en entrée sont codés au format NetCDF qui est un format très utilisé par la communauté travaillant sur les sciences de la terre.

Le format de sauvegarde généré est actuellement textuel et graphique.

But du projet

Les objectifs du projet sont multiples :

  • il s'agit dans un premier temps de se familiariser avec logiciel entièrement écrit en JAVA et de permettre la sauvegarde des données directement au format NetCDF ;
  • il faudra ensuite améliorer la prise en charge 3D qui a débuté mais n'est pas terminé (cf image ci-dessous)

Fichier:Marsouin2.jpg


Un web-bot agrégateur de votes pour le site trictrac.net - Denis Robilliard, Cyril Fonlupt et Mourad Bouneffa

Etudiants : Julien Cadart et Marina Herbaut

Objectif :

Le site trictrac.net est dédié aux jeux de réflexion (jeux de plateau, jeux de cartes, jeux de stratégie,...). Il offre notamment la possibilité, aux joueurs qui s'enregistrent, de noter les jeux sur une échelle de 1 à 5. On dispose donc d'une base de données de "votes" ou "d'opinions" que l'on pourrait utiliser pour orienter le choix d'une personne souhaitent acquérir un nouveau jeu (le même principe peut être utilisé pour d'autres applications : choix d'un film à voir, ou d'un album musical à acheter en fonction d'une liste de critiques, etc...).

Public ciblé : M1 ou M2 ; nécessite des connaissances en web et en base de données (php, mysql).

Description du projet

On appellera "joueur" une personne ayant enregistré un vote sur le site tric-trac. Les joueurs peuvent être identifiés par leur pseudonyme enregistrés en même temps que leur vote. L'application parcourra automatiquement le site trictrac pour charger dans sa propre base les données (jeux, joueur, votes) disponibles sur trictrac. On pourra faire des mises à jour de la base en fonction de l'évolution du site (apparition de nouveaux jeux ou joueurs,...).

On appellera "client" la personne qui souhaite recevoir un avis construit par l'aggrégateur de votes. Pour donner un avis pertinent, l'application doit "connaître" le client. Pour cela on demandera au client de saisir et de noter les jeux qu'il possède déjà (la saisie sera facilitée par une recherche/complétion automatique dans la base). Ces renseignements seront stockés dans la base et pourront être édités à la demande du client.

Le logiciel recherchera dans sa base les joueurs qui ont voté pour au moins un des jeux renseignés par le client. Chacun de ces joueurs se verra attribuer une "confiance" basée d'une part sur le nombre de jeux qu'il a noté et qui sont renseignés par le client (le plus est le mieux), d'autre part sur la similitude entre les notes qu'il a accordées et celles du client pour ces mêmes jeux (plus il ressemble au client, plus son vote est fiable).

L'application construira ensuite la liste des jeux non possédés par le client pour lesquels ces joueurs ont voté. On construira une synthèse des opinions sur chacun de ces jeux en pondérant les votes par la confiance. Puis on affichera les "meilleurs jeux" par ordre décroissant des votes (un peu à la manière de Google). On pourra afficher aussi sur une requête portant sur un jeu donné, quelle est sa note moyenne (issue directement des données trictrac) et quelle est sa note "corrigée" (sythèse des notes des joueurs ressemblants).

Plan de réalisation

Le projet s'organisera autour des phases suivantes :

  • extraction de données
  • définition d'une API et construction d'une l'interface web
  • calcul des indices de confiance et des listes de jeux
  • calcul des synthèses des votes

Un joueur artificiel pour "San Juan" - Denis Robilliard et Cyril Fonlupt

Etudiants : ??

Objectif : Réaliser un joueur artificiel pour le jeu de cartes "San Juan".

Liens externes

Public ciblé : constitue une bonne introduction (L3, M1) ou approfondissement (M2) à l'intelligence artificielle pour tout étudiant motivé par cette thématique.

Matériel : 110 cartes "bâtiment" mélangées et organisées en une pile "pioche" et une pile "défausse", 5 tuiles "cours du marché", 5 cartes "rôle".

Description du jeu

  • nombre de joueur : de 2 à 4.
  • Début du jeu : chaque joueur reçoit une main de 4 cartes et un bâtiment "teinturerie d'indigo" posé devant lui. L'un des joueurs est nommé "gouverneur" pour ce tour. Les tuiles des cours du marché (voir plus bas) sont mélangées.
  • Déroulement d'un tour : chaque joueur en commençant par le gouverneur choisit un parmi les 5 rôles disponibles non encore utilisé ce tour. Tous les joueurs effectuent l'action indiquée par le rôle, le joueur qui a choisit le rôle bénéficie en plus du privilège associé au rôle. Lorsque tous les joueurs ont choisit un rôle, le joueur suivant devient gouverneur et chaque joueur ne peut conserver que au maximum 7 cartes dans sa main.
  • Description des rôles :
    • Bâtisseur : chacun peut construire un bâtiment (le poser devant soi) en payant son coût (défausser autant de cartes de sa main que le coût du bâtiment), privilège : coût réduit de 1.
    • Conseiller : chacun peut piocher 2 cartes et en conserver 1 dans sa main et défausse l'autre, privilège : piocher 5 cartes au lieu de 2 et en défausser 4.
    • Chercheur d'or : ne rien faire, privilège : piocher une carte et l'ajouter à sa main.
    • Producteur : chacun peut produire 1 marchandise sur une carte bâtiment de production vide de son choix (on pioche une carte que l'on pose sur le bâtiment), privilège : produire 1 marchandise de plus.
    • Marchand : chacun peut vendre 1 des marchandises disponibles sur un bâtiment de production, privilège : vendre 1 marchandise de plus. Le cours des marchandises est déterminée par les cours du marché (voir plus bas), le joueur reçoit autant de cartes de la pioche que le cours de(s) la marchandise(s) vendue(s).
  • Cours du marché : il y a 5 tuiles donnant les cours du marché, respectivement de l'indigo, du sucre, du tabac, du café et de l'argent, avec les valeurs (1,1,1,2,2), (1,1,2,2,2), (1,1,2,2,3), (1,2,2,2,3), (1,2,2,3,3). les 5 tuiles sont mélangées puis empilée une fois en début de partie, puis on retourne la tuile du dessus à chaque fois que le rôle du marchand est choisi. Une fois les ventes effectuées, la tuile est replacée sous la pile.
  • Fin de partie : la partie se termine après la phase de construction où l'un des joueur pose son 12ème bâtiment. Le joueur ayant le plus de points de victoire (PV) associés à ses bâtiments construits est le gagnant. En cas d'ex-aequo ajouter aux PV le nombre de cartes de sa main et le nombre de marchandises produites disponibles.

Plan de réalisation

On adoptera une approche par "fonction cible" :

  • On déterminera des caractéristiques importantes du jeu que l'on exprimera sous forme de fonctions à valeur numérique (par exemple : nombre de cartes dans la main, nombre de PV de la main, coût minimum de construction de la main, nombre de bâtiment de productions, nombre de points de victoire déjà accumulés,..);
  • On associera une évaluation à la situation actuelle du joueur en faisant une somme pondérée des fonctions caractéristiques;
  • On fera apprendre à la machine les bonnes pondérations par un algorithme de renforcement simple, en faisant joueur la machine contre elle-même et contre un joueur humain.
  • On réalisera une interface minimale, qui sera améliorée en fonction de l'avancement du projet.

Description des cartes

Les bâtiments sont divisés en 2 catégories : bâtiments de production (5 types uniquement) qui peuvent être construits en nombre quelconque, et bâtiments administratifs qui ne peuvent être construits à plus d'un exemplaire par chaque joueur.

Fichier:Description des batiments SanJuan.gif

M1 I2L

Site Web communautaire pour la traduction de Mandriva Linux - Cyril Fonlupt

Etudiants : Aurélien Werner et Gaëtan Duwiquet

Description

Il s'agit de faire un site Web communautaire facilitant la traduction de la distribution Mandriva Linux.

A l'heure actuelle, les fichiers de langue PO sont transmis de mails en mails aux traducteurs, les traducteurs modifient les fichiers ro et les renvoient à Mandriva. Ce n'est pas très pratique, et cela limite le nombre de traducteurs.

Le principe du site Web est de faire en sorte que les fichiers PO ou autre soient importés simplement grâce à un formulaire, voire automatiquement. Il y aura 3 classes d'utilisateurs :

  • Les modérateurs/administrateurs
  • Les traducteurs de "confiance"
  • Les membres de bases.

Les paquets ou les fichiers de doc cooker à traduire seront classés par langue et par importance. Les membres de base peuvent poster une traduction via l'interface Web de fichiers PO. Plusieurs membres de base peuvent proposer leur version de traduction. Les modérateurs/administrateurs n'ont plus qu'à valider la meilleure traduction proposée. Au bout de x traductions sans erreurs, un administrateur peut faire passer l'auteur de ces traductions en traducteur de "confiance". Lorsqu'un traducteur de confiance est nommé, il peut directement valider ses propres traductions. Une fois qu'un paquet est complètement traduit, le fichier "PO ou autre" est généré automatiquement. Il n'a plus qu'a être intégré à la distribution.

Développement pour Framasoft - Cyril Fonlupt

Etudiants : ??

Le sujet est en cours de finalisation en collaboration avec l'équipe du site Framasoft.net

Distribution Debian GNU/Linux Live - Cyril Fonlupt

Etudiants : BIZIKI Zoser, SCHMITT Valentin

Mots-clés : GNU/Linux, Debian, Live USB, bootloader, initramfs, chroot, système de fichier, cryptage, personnalisation.

Contexte

Le projet Debian Live (voir références) se propose de développer un système "Live" pour la distribution Debian. Ce système est un sous-projet officiel supporté par Debian, ne contenant que des paquets officiels et offrant tous les avantages d'un système Debian. Ce projet est basé sur l'outil live-helper, ensemble de scripts pour construire l'image d'un système Debian Live.

Notre but est de mettre en place une distribution Debian GNU/Linux Live USB personnalisée, afin d'avoir son système personnel et ses données "dans la poche", le tout disponible pour une utilisation sur différentes machines (incluant des machines diskless par exemple), sans modifier les données du propriétaire de la machine Un autre intérêt peut être le dépannage d'une machine en panne (particulièrement si la panne à lieu au niveau du système d'exploitation ou du disque dur).

Objectifs

  • Comprendre la construction d'une distribution Live.
  • Choisir un ensemble d'outils logiciels cohérent en respectant des contraintes d'espace disque (<1Go pour clef USB, si <700Mo CD aussi envisageable).
  • Étudier le fonctionnement du démarrage (boot, chargement en mémoire, listage et utilisation des périphériques, ...) d'un système GNU/Linux.
  • Étudier les problèmes de compatibilité.
  • Proposer un mode "persistant" assurant la sauvegarde des données (en parallèle au mode "lecture-seule").
  • proposer une option de cryptage des données.
  • proposer l'installation sur la machine.
  • proposer de lancer un test de la mémoire vive.
  • contribuer (dans la mesure du possible) au projet Debian Live.
  • ajouter un bootsplash.

Références :

Création d’un outil de suivi des heures d’enseignements dans les technologies du Web - Grégory Bourguin

Etudiants : ?? (4 étudiants)

Objectif

Chaque année, les enseignants doivent effectuer un suivi de l’ensemble des heures de Cours/TD/ TP qu’ils ont effectuées. Ce suivi doit être effectué pour chaque formation et pour chaque matière enseignée. Une « application » a déjà été créée sous forme de tableaux Excel accompagnés de macros en Visual Basic Application. Le but de ce projet est de transposer cette « application » dans une nouvelle écrite en PHP, MySQL, (D)HTML, AJAX, ou toute autre technologie qui réponde aux objectifs fixés.

Etapes :

  • appréhension du sujet (etude de l’application existante)
  • choix technologiques
  • réalisation

Création d’un outil de suivi des heures d’enseignements en Java - Grégory Bourguin

Etudiants : Rémi Tylski

Objectif

Chaque année, les enseignants doivent effectuer un suivi de l’ensemble des heures de Cours/TD/ TP qu’ils ont effectuées. Ce suivi doit être effectué pour chaque formation et pour chaque matière enseignée. Une « application » a déjà été créée sous forme de tableaux Excel accompagnés de macros en Visual Basic Application. Le but de ce projet est de transposer cette « application » dans une nouvelle écrite en Java (interfacé avec une base de données ou avec génération de fichiers type XML).

Etapes :

  • appréhension du sujet (etude de l’application existante)
  • choix technologiques
  • réalisation

Refonte d'un outil de chat sous Eclipse - Grégory Bourguin et Arnaud Lewandowski

Etudiants : ??

Objectif

Dans le cadre du projet CooLDev, nous avons créé un outil de chat sous forme de plugin Eclipse permettant aux utilisateurs d’échanger de manière synchrone. Ce chat a été réalisé en se fondant sur la technologie JSDT de Sun. Malheureusement, JSDT possède des limites qui posent problème dans l’utilisation de notre outil en situation réelle. Le but de ce projet est donc d’opérer une refonte du plugin de chat existant en changeant principalement sa couche réseau.

Etapes :

  • Découverte de l’environnement de création de plugins Eclipse
  • Etude des problèmes liés au plugin de chat existant
  • Sélection d’un protocole réseau adéquat
  • Refonte du plugin

Mise en œuvre d’une approche objet/composant en Flash - Grégory Bourguin

Etudiants : Matthieu Maillard et Nicolas Ghier

Objectif

Le but de ce projet est de rendre plus génériques certains éléments constituant le site www.lamesoeur.fr. En particulier, une des animation de ce site propose une « ronde de photos » fonctionnant selon un algorithme assez complexe, actuellement fonctionnel, mais peu générique.

Etapes :

  • familiarisation à l’environnement Flash
  • compréhension de l’approche de développement de composants paramétrables sous flash
  • Mise en œuvre de cette approche pour la création d’un composant « ronde de photos » aisément paramétrable (en adaptant l’algorithme existant).

RML2 - Henry Obein - Itaapy

Etudiants : Sébastien Dumont

Mots-clés : Python, XML, HTML, CSS, ReportLab, PDF

Contexte

Actuellement la librairie itools inclut une implémentation de RML ainsi qu'une implémentation de RML2.

RML2 est un language XML ayant pour but de permettre à quiconque connaissant l'HTML ainsi que les CSS de pouvoir écrire un template en XML qui sera ensuite parsé pour générer un document PDF.

Objectifs

Le projet portera sur l'amélioration de l'actuelle version de RML2. Parmi les améliorations demandées: un meilleur support des balises HTML div, parfaire le parseur CSS (parti sur l'héritage), parfaire l'utilisation de la dernière version stable de ReportLab (version 2.2). Ce dernier point est important, car le développement de RML2 était basé sur la version snapshot de ReportLab (actuellement version stable 2.2). Or certains changements dans la dernière version font que des fonctionnalités de RML2 sont maintenant cassées.

Références

Wrapper Python pour bibliothèques d'extraction - Hervé Cauwelier - Itaapy

Etudiants : ??

Mots-clés : C, Python, GED

Contexte

Une bonne GED (gestion électronique de documents) n'est rien sans un système d'indexation plein texte des documents qu'on y importe.

Les technologies actuelles copient le fichier de bureautique à indexer dans un répertoire temporaire, appellent un exécutable dans un sous-processus, puis lisent la sortie standard ou un fichier de sortie.

Ces opérations sont lourdes et les exécutables sont en voie de disparition au profit de bibliothèques réutilisables. Par exemple, wvText pour convertir un fichier Word en texte, n'existe plus avec la version 2 de la bibliothèque wvWare. Mais il n'existe pas de wrapper Python pour cette bibliothèque.

Objectifs

  • Se documenter sur le fonctionnement et l'API des bibliothèques utilisées par les exécutables en question : wvText, pdftotext, xlhtml, ppthtml et unrtf.
  • Alternativement, on peut retenir une meilleure bibliothèque, maintenant qu'on ne dépend plus d'un exécutable l'utilisant. Non, OpenOffice.org n'est pas une bibliothèque !
  • Écrire un wrapper Python, c'est-à-dire un programme en C utilisant l'API CPython, qui prend un chemin de fichier en paramètre et qui retourne un objet unicode contenant tous les mots du document séparés par des espaces blancs.

Ces wrappers seront compilés avec distutils (fichier setup.py) et liés à leurs bibliothèques respectives.

Un programme d'exemple en Python doit prendre un chemin en paramètre, importer le wrapper et écrire sur la sortie standard les mots du document correspondant.

Au moins deux wrappers sont demandés pour atteindre l'objectif. Il est conseillé de commencer par la bibliothèque derrière pdftotext, poppler, car elle est potentiellement la mieux documentée et toujours maintenue. Le code source des différents exécutables est un bon exemple de départ.

Le wrapper sera écrit avec l'API CPython de Python 2.5. Il sera migré à Python 3 dans un autre projet.

Références

Améliorer le système de cache de itools.handlers - J. David Ibanez - Itaapy

Etudiants : Romain Gauthier

Mots-clés : Python, itools, database

Contexte

Le système de base de données inclus dans la librairie itools dispose d'un cache très gourmand en mémoire. En fait, les objets (appelés handlers) sont stockés au fur et à mesure du besoin, mais ne sont pas libérés. Autrement dit les besoins en mémoire croissent avec le temps d'exécution.

Objectifs

L'objectif est donc de libérer la mémoire lorsque certaines limites sont atteintes. Deux versions seront développées.

La première version utilisera une heuristique simple. On pourra définir le nombre maximale d'objets à stocker, et lorsque cette limite est atteinte les objets les plus "anciens" seront supprimés du cache. Où l'âge d'un objet est définit par la date et heure du dernier accès à cet objet.

Le problème de cette première version est qu'elle ne fait pas la différence entre les petits et les grands objets.

La deuxième version devra donc définir la limite du cache non pas en nombre d'objets, mais en taille réelle. Et choisir les objets à supprimer du cache en fonction de leur âge et de leur taille. La difficulté la plus notable pour réaliser cette deuxième version sera de connaître la taille d'un handler ; une nouvelle méthode sera rajoutée dans chaque handler qui nous donnera cette information : "handler.get_sizeof".

D'autres améliorations seront envisagées si le temps le permet.

Références

Tester et corriger ikaaro sur la plate-forme Windows - Sylvain Taverne - Itaapy

Etudiants : ??

Mots-clés : Python, Windows, ikaaro

Contexte

La plateforme principale utilisée pour développer et tester le CMS ikaaro est GNU/Linux. Son fonctionnement sous Windows est loin d'être satisfaisant.

Objectifs

Le but est donc de tester le CMS ikaaro sur Windows et corriger les problèmes rencontrés. Il faudra en faire autant pour la librairie itools (sur laquelle repose ikaaro).

De plus, il faudra travailler sur la chaîne qui permet de construire un paquet itools (un installateur) pour Windows. Puisque itools contient du code C, l'installateur généré doit être compilé. Aujourd'hui ceci est fait depuis une machine Linux avec une procédure décrite dans la documentation (voir références). Les tests donc devront suivre la même procédure :

  • construire le paquet depuis Linux (avec Wine)
  • puis le tester sur un vrai Windows

Références

Parallélisation d'un simulateur de "Tetris" sur carte Nvidia 8800 - Amine Boumaza et Denis Robilliard

Etudiants : ??

Objectif

Paralléliser sur GPU (cartes graphiques à haute puissance de calcul) un simulateur de jeu de Tetris. Ce projet s'inscrit dans le cadre d'une compétition sur le meilleur joueur artificiel de Tetris (voir sur YouTube), avec pour objectif d'améliorer le programme vainqueur en titre actuellement. Les GPUs cibles seront des Nvidia série 8000 et au-delà, programmés en langage CUDA.

Plan de réalisation

  • prise en main de la version actuelle (en C)
  • découverte du langage CUDA, extension du C à la programmation parallèle sur GPU Nvidia
  • parallélisation du code
  • tests de performance

Boutique en ligne pour le CMS libre Drupal - Arnaud Lewandowski

Etudiants : ??

Description

L'objectif est de concevoir et de développer une boutique en ligne (e-commerce) sous forme de module(s) intégrable(s) au CMS libre Drupal. La boutique devra notamment gérer :

  • catalogue de produits
  • panier
  • paiement en ligne

Le projet consistera :

  • à définir de manière précise le cahier des charges fonctionnel en étudiant les solutions existantes ;
  • à définir l'architecture de la solution en fonction de l'API de Drupal ;
  • enfin, à développer la solution.

Module de gestion d'événements scientifiques pour le CMS libre Drupal - Arnaud Lewandowski

Etudiants : ??

Description

L'organisation de manifestations scientifiques (conférences, colloques) est une charge lourde qui exige la collaboration d'un certains nombre d'acteurs souvent répartis géographiquement. Cette activité consiste notamment à :

  • annoncer la conférence longtemps à l'avance,
  • collecter les articles soumis par les chercheurs,
  • répartir ces articles aux différents relecteurs chargés de leur évaluation,
  • collecter leurs avis,
  • décider quels articles seront acceptés, et notifier leurs auteurs
  • organiser ensuite le planning de la conférence en regroupant les articles sélectionnés par thématiques
  • gérer l'inscription des chercheurs à la conférence
  • etc.

L'objectif est de concevoir et de développer un outil permettant de supporter ce processus d'organisation, sous forme de module intégrable au CMS libre Drupal.

Le projet consistera :

  • à définir de manière précise le cahier des charges fonctionnel en étudiant les solutions similaires, et en collaboration avec le responsable du projet ;
  • à définir l'architecture de la solution en fonction de l'API de Drupal ;
  • enfin, à développer la solution.

Modifications/améliorations du logiciel Marsouin - Cyril Fonlupt et Denis Robilliard

Etudiants : ??

Description

Le logiciel Marsouin est un logiciel développé au sein du Laboratoire d'Informatique du Littoral utilisé par l'IFREMER (Institut Français de Recherche et d'Exploitation de la Mer) qui permet de reconnaître de manière automatique des tourbillons dans les océans à partir de cartes de courants provenant de différentes sources (satellites, simulations hydrodynamiques, ...).

Les tourbillons sont automatiquement numérotés, leurs surfaces sont évaluées ainsi que diverses informations utiles pour les chercheurs de l'IFREMER (sens du courant, centre du tourbillon, ...)

Fichier:Marsouin1.jpg

Les fichiers fournis en entrée sont codés au format NetCDF qui est un format très utilisé par la communauté travaillant sur les sciences de la terre.

Le format de sauvegarde généré est actuellement textuel et graphique.

But du projet

Les objectifs du projet sont multiples :

  • il s'agit dans un premier temps de se familiariser avec logiciel entièrement écrit en JAVA et de permettre la sauvegarde des données directement au format NetCDF ;
  • il faudra ensuite améliorer la prise en charge 3D qui a débuté mais n'est pas terminé (cf image ci-dessous)

Fichier:Marsouin2.jpg

Implémentation d'une API permettant de jouer au jeu SAMURAI - Cyril Fonlupt et Denis Robilliard

Etudiants : ??

Description

SAMURAI est un jeu de stratégie très simple pouvant être joué de 2 à 4 personnes. Il simule le contrôle des îles du Japon par différentes faction. Les règles sont rappelées ci-dessous mais peuvent être consultées à l'adresse suivante : http://www.trictrac.net/index.php3?id=jeux&rub=detail&inf=detail&jeu=200.

Le but de ce projet est de développer une interface permettant de simuler le placement des différents pions du jeu et de vérifier que les pions posés respectent les règles et de résoudre les différents types de combat. Il ne s'agit pas de développer une intelligence artificielle pour le jeu, il s'agit de développer une API la plus documentée possible en JAVA permettant de simuler le plateau de jeu pour deux à quatre joueurs.

Cette API devra être construite de manière à être appelé le plus simplement possible à partir d'autres classes en JAVA.

Ce jeu a déjà fait l'objet d'un logiciel non libre et qui n'est plus suivi maintenant dont vous pourrez vous inspirer pour réaliser l'interface graphique : http://www.klear.com/new/games/samurai/

Principales règles de Samurai

  • Le matériel de jeu
    • Les puissances politiques : 39 statuettes divisées en trois groupes : 13 casques représentant la noblesse, 13 bouddhas pour les prêtres et 13 rizières pour les paysans.
    • Vos forces : 20 tuiles par joueur (5 samouraïs, 3 navires, 1 rônin, 3 bouddhas, 3 rizières, et 3 casques, 1 tuile permettant d'interchanger 2 statuettes du plateau, et 1 autre tuile permettant d'interchanger 2 tuiles du plateau). Certaines tuiles sont décorées d'un idéogramme japonais.
    • 1 paravent par joueur qui fait office de mémo.
    • 1 plateau de jeu en 4 parties.
  • Le placement des puissances politiques
    • Suivant le nombre de joueur vous utiliserez 2, 3 ou les 4 parties du plateau de jeu.
    • Chacun des joueurs choisit 5 tuiles secrètement et les disposent derrière son paravent. Ses 15 autres tuiles sont déposés face cachée sur la table et constituent votre pioche.
    • Chaque joueur à tour de rôle va devoir placer une statuette d'abord dans chaque ville (qui peuvent contenir 2 statuettes différentes) ensuite dans chaque village (1 statuette maxi par village). Une fois toutes les statuettes posées le jeu peut enfin commencer.
  • Le positionnement de vos forces
    • À tour de rôle, chaque joueur doit poser une tuile sur les hexagones libres du plateau. Il peut s'il le désire jouer jusqu'à 4 tuiles supplémentaires mais elles doivent être pourvues d'un idéogramme japonais. À la fin de son tour le joueur récupère dans sa pioche autant de tuiles qu'il a jouées.
  • À moi les forces politiques du Japon !
    • Dès qu'une case contenant une statuette est entièrement encerclée de tuiles, le joueur obtenant le total le plus élevé (des tuiles entourant la statuette bien sûr) capture la statuette.
  • Comment gagner ou l'art d'être un bon Samouraï.
    • Dès que la dernière statuette est capturée, la partie est finie et le vainqueur est désigné. Oui, mais comment ? Bah c'est tout simple : le joueur possédant la majorité des statuettes dans au moins deux forces politiques a gagné. Si ce cas n'arrive pas, alors le joueur désigné vainqueur doit avoir une majorité dans une force politique et plus de statuettes que ses adversaires ayant eux aussi une majorité dans une autre force politique (relisez une seconde fois c'est plus clair).


Placement automatique de noeuds dans un graphe - Gauthier Quesnel et Eric Ramat - INRA/LIL/ULCO

Etudiants : ???

Mots-clés

  • Manipulation de graphes
  • Placement automatiques
  • Interface graphique

Présentation du projet

L'interface graphique GVLE, dont une partie est représentée sur les captures d'écrans suivantes, permet de représenter des graphes de modèles. Ces modèles sont de deux types : les modèles atomiques (les feuilles de l'arbre) et les modèles couplés (les noeuds de l'arbre). GVLE représente la hiérarchie de modèles couplés dans une fenêtre (image de gauche), et les modèles couplés avec seulement un niveau de sous-modèles (image de droite). Nous nous intéressons dans ce projet, uniquement à la représentation graphique d'un modèle couplé et non de sa hiérarchie.

Le placement des modèles d'un modèle couplé est aujourd'hui défini par l'utilisateur et avec des moyens très limités (de simples déplacements de boîte). Ainsi, comme le présente la figure de droite, les connexions entre les modèles se croisent et peuvent être difficiles à placer lorsque le modèle couplé possède beaucoup de sous-modèles.

GVLE : représentation de la hiérarchie de modèles couplés et de atomiques. (2 KB)

L'objectif de ce stage est de proposer un ensemble d'algorithmes, à introduire dans la bibliothèque vlegraph, afin de proposer un placement automatique de modèles d'un modèle couplé sur une zone de dessin CairoSurface le tout en proposant une nouvelle visualisation des objets, de simple cercles pour les modèles atomiques ou couplé, et des flèches pour les connexions entre modèles.

GVLE : Représentation du contenu d'un modèle couplé. Les boîtes vertes représentent les modèles couplés, les boîtes noires, les modèles atomiques. (3 KB)

Ce projet est susceptible d'être suivi d'un stage rémunéré au sein de l'INRA. Le stage pourra être effectué à Toulouse ou à Calais sous les encadrements de Éric Ramat, Gauthier Quesnel et Patrick Chabrier avec pour sujet le développement de GVLE.

Objectif

  • Comprendre le fonctionnement des 5 classes de la bibliothèque vlegraph.
  • Implémenter une méthode de placement automatique : par ex. les algorithmes à ressorts.
  • Implémenter une représentation graphique Cairo d'un modèle couplé.
  • Rendre interactive la représentation graphique de modèles couplés (les modèles et les connexions doivent pouvoir être créées, modifiées et/ou supprimées).
  • Remplacer la vue de la GVLE par celle nouvellement développée.

Langages et technologies

Plate-forme de tests unitaires pour VLE - Gauthier Quesnel et Eric Ramat - INRA/LIL/ULCO

Etudiants : ???

Mots-clés

  • Tests unitaires
  • Virtualisation

Présentation du projet

Les tests unitaires sont très importants dans le développement de logiciel informatique et plus particulièrement avec les méthode agiles. La plate-forme VLE dispose de tests unitaires mais ces tests ne sont exécutés que sur les machines des développeurs, bien souvent, du x86 sous Debian GNU/Linux ou Microsoft Windows XP. Les programmes CMake (générateurs de Makefiles) et CDash (analyseur de résultats de tests unitaires) permettent de mettre en place un outil efficace pour la gestion de tests unitaires depuis de multiples OS, compilateurs, saveurs de noyaux etc. Par exemple, la page suivantes est un exemple d'analyses des sorties de CDash depuis les tests unitaires de CMake.

Pour ce projet nous nous proposons de développer un ensemble de scripts, programmes et autres infrastructures logicielles afin de pouvoir lancer les tests unitaires de VLE depuis plusieurs sources (OS, compilateurs etc.). Pour cela, un ensemble de machines virtuelles lancées pour exécutées les tests unitaires doit être mis en place.

Ce projet est susceptible d'être suivi d'un stage rémunéré au sein de l'INRA. Le stage pourra être effectué à Toulouse ou à Calais sous les encadrements de Éric Ramat, Gauthier Quesnel et Patrick Chabrier avec pour sujet le développement de GVLE.

Objectif

  • Étudier les logiciels CMake et CDash.
  • Ajouter les scripts CMake à VLE pour prendre en compte les tests unitaires.
  • Utiliser des outils de virtualisation, de chroot etc. pour mettre en place un ensemble d'OS de tests :
    • Dans un premier temps : Debian GNU/Linux x86, Freebsd x86 et Windows XP.
    • Dans un second temps : Linux sur : x86-64, PPC etc.
  • Proposer un structure pour intégrer ces tests pour n'importe quel type de logiciel.

Langages et technologies

M1 ISIDIS

Ajout de Plugins de communications avec l'extérieur à l'application Generic@ RAD - Cyril Fonlupt

Etudiants : Guillaume Magnier et Jérôme Vasseur

Présentation

L'entreprise Map Conseil souhaite améliorer sa plateforme de développement et de déploiement Generic@ RAD grâce à l'ajout d'outils de communication et d'automatisation. Dans un premier temps, la réalisation d'un serveur de réception de données issues de GPS/GPRS l'affichage en temps réel de la position d'un engin équipé sur l'application Generic. Dans un second temps des plugins permettant la réception de courriels et de SMS serviront à l'utilisateur afin de pouvoir rapprocher et lier tout ces documents au sein de la même application. Puis ensuite, il faudra ajouter la possibilité de pouvoir créer des tâches permettant l'envoi de mails ou de SMS automatiquement selon certains critères à définir par l'utilisateur.

Plan de réalisation

  • Mise en place d'un serveur UDP de réception des données des GPS.
  • Stockage des données collectées automatiquement et affichage des données en temps réels en cartographie (dans Generic@).
  • Mise en place d'un serveur de mails pour pouvoir recevoir des mails sur l'application Generic@ et permettre leur stockage en base de données.
  • Mise en place d'une interface permettant de gérer les mails (suivi).
  • Mise en place de la réception et stockage de SMS avec un système de paramétrage.
  • Permettre l'envoi de mails et de SMS automatiquement.
  • Couplage avec un serveur vocal

Création d’un outil de suivi des heures d’enseignements dans les technologies du Web - Grégory Bourguin

Etudiants : ?? (4 étudiants)

Objectif

Chaque année, les enseignants doivent effectuer un suivi de l’ensemble des heures de Cours/TD/ TP qu’ils ont effectuées. Ce suivi doit être effectué pour chaque formation et pour chaque matière enseignée. Une « application » a déjà été créée sous forme de tableaux Excel accompagnés de macros en Visual Basic Application. Le but de ce projet est de transposer cette « application » dans une nouvelle écrite en PHP, MySQL, (D)HTML, AJAX, ou toute autre technologie qui réponde aux objectifs fixés.

Etapes :

  • appréhension du sujet (etude de l’application existante)
  • choix technologiques
  • réalisation

Création d’un outil de suivi des heures d’enseignements en Java - Grégory Bourguin

Etudiants : ?? (4 étudiants)

Objectif

Chaque année, les enseignants doivent effectuer un suivi de l’ensemble des heures de Cours/TD/ TP qu’ils ont effectuées. Ce suivi doit être effectué pour chaque formation et pour chaque matière enseignée. Une « application » a déjà été créée sous forme de tableaux Excel accompagnés de macros en Visual Basic Application. Le but de ce projet est de transposer cette « application » dans une nouvelle écrite en Java (interfacé avec une base de données ou avec génération de fichiers type XML).

Etapes :

  • appréhension du sujet (etude de l’application existante)
  • choix technologiques
  • réalisation

Refonte d'un outil de chat sous Eclipse - Grégory Bourguin et Arnaud Lewandowski

Etudiants : ??

Objectif

Dans le cadre du projet CooLDev, nous avons créé un outil de chat sous forme de plugin Eclipse permettant aux utilisateurs d’échanger de manière synchrone. Ce chat a été réalisé en se fondant sur la technologie JSDT de Sun. Malheureusement, JSDT possède des limites qui posent problème dans l’utilisation de notre outil en situation réelle. Le but de ce projet est donc d’opérer une refonte du plugin de chat existant en changeant principalement sa couche réseau.

Etapes :

  • Découverte de l’environnement de création de plugins Eclipse
  • Etude des problèmes liés au plugin de chat existant
  • Sélection d’un protocole réseau adéquat
  • Refonte du plugin

Mise en œuvre d’une approche objet/composant en Flash - Grégory Bourguin

Etudiants : ??

Objectif

Le but de ce projet est de rendre plus génériques certains éléments constituant le site www.lamesoeur.fr. En particulier, une des animation de ce site propose une « ronde de photos » fonctionnant selon un algorithme assez complexe, actuellement fonctionnel, mais peu générique.

Etapes :

  • familiarisation à l’environnement Flash
  • compréhension de l’approche de développement de composants paramétrables sous flash
  • Mise en œuvre de cette approche pour la création d’un composant « ronde de photos » aisément paramétrable (en adaptant l’algorithme existant).

Développement d’un site web : Semiotics of Law - Anne Wagner et Arnaud Lewandowski

Etudiants : ??

Contexte

Depuis 20 ans, la sémiotique juridique s’est développée dans le monde et nous souhaitons rendre nos travaux de recherche, nos bases de données, nos références bibliographiques visible sur le Net à tous ainsi que de créer un forum de discussion et des accès sécurisés pour nos membres afin de présenter des travaux en cours.

Objectif

L'objectif est de proposer une solution web (basée par exemple sur Joomla, ou Drupal) assurant les fonction suivantes :

  • Présentation dynamique du site avec des informations sources et clefs pour tout public sur nos différents axes de recherche.
  • Gestion sécurisée des accès via des sessions
  • Différents modes de travail (administrateur, comité scientifique, membres)
  • Planification des différentes conférences et gestion des modifications
  • Mise en place d’une base de données de nos membres et mise à jour automatique
  • Mise en place des CV du comité scientifique avec possibilité de remise à jour
  • Construction automatique de références bibliographiques et gestion des modifications par l’administrateur.
  • Mise en place d’un intranet avec forum de discussion sécurisé

Création d'une plateforme de paris/pronostics en ligne - Cyril Fonlupt

Etudiants : Deroo Nicolas, Devulder Max

Objectif

Réaliser une plateforme de paris en ligne légale. Contrairement à ce qui existe sur la toile (site de paris sportif/PMU), l'idée est de laisser libre choix à l'internaute de créer ses propres paris. Par exemple il sera possible de parier ceci "Je te paris que le barack Obama remportera les élections présidentielles ". Bien sur il faudra automatiser la gestion des litiges et restreindre les paris uniquement à ceux facilement vérifiables.

Plan de réalisation

  • Études MCD
  • Légalités / Contraintes
  • Choix plateforme ( CMS Joomla + Templates / Partir de zéro )
  • Système de pari, points
  • Litiges automatisés
  • Boutique cadeau
  • Recharge points via Cb/ Paypal. (non prioritaire).
  • Parrainages

Parallélisation d'un simulateur de "Tetris" sur carte Nvidia 8800 - Amine Boumaza et Denis Robilliard

Etudiants : ??

Objectif

Paralléliser sur GPU (cartes graphiques à haute puissance de calcul) un simulateur de jeu de Tetris. Ce projet s'inscrit dans le cadre d'une compétition sur le meilleur joueur artificiel de Tetris (voir sur YouTube), avec pour objectif d'améliorer le programme vainqueur en titre actuellement. Les GPUs cibles seront des Nvidia série 8000 et au-delà, programmés en langage CUDA.

Plan de réalisation

  • prise en main de la version actuelle (en C)
  • découverte du langage CUDA, extension du C à la programmation parallèle sur GPU Nvidia
  • parallélisation du code
  • tests de performance

Génération de la géométrie d'arbres 3D - Christophe Renaud

Etudiants : Jean-Claude Soret et Ulrich Duvent

Description

Le squelette d'arbres 3D est généré par un logiciel écrit en C++, avec une interface wxWidgets. L'objectif du projet est de générer la géométrie des arbres à partir des squelettes disponibles : tronc, branches, feuilles, ... afin de pouvoir disposer d'arbres réalistes. Un seconde phase du projet consistera à permettre l'exportation de cette géométrie dans quelques formats 3D portables (obj, lwo, ...).

Le projet sera à réaliser en C++, à l'aide de la bibliothèque wxWidgets et de l'API OpenGL.

Boutique en ligne pour le CMS libre Drupal - Arnaud Lewandowski

Etudiants : ??

Description

L'objectif est de concevoir et de développer une boutique en ligne (e-commerce) sous forme de module(s) intégrable(s) au CMS libre Drupal. La boutique devra notamment gérer :

  • catalogue de produits
  • panier
  • paiement en ligne

Le projet consistera :

  • à définir de manière précise le cahier des charges fonctionnel en étudiant les solutions existantes ;
  • à définir l'architecture de la solution en fonction de l'API de Drupal ;
  • enfin, à développer la solution.

Module de gestion d'événements scientifiques pour le CMS libre Drupal - Arnaud Lewandowski

Etudiants : ??

Description

L'organisation de manifestations scientifiques (conférences, colloques) est une charge lourde qui exige la collaboration d'un certains nombre d'acteurs souvent répartis géographiquement. Cette activité consiste notamment à :

  • annoncer la conférence longtemps à l'avance,
  • collecter les articles soumis par les chercheurs,
  • répartir ces articles aux différents relecteurs chargés de leur évaluation,
  • collecter leurs avis,
  • décider quels articles seront acceptés, et notifier leurs auteurs
  • organiser ensuite le planning de la conférence en regroupant les articles sélectionnés par thématiques
  • gérer l'inscription des chercheurs à la conférence
  • etc.

L'objectif est de concevoir et de développer un outil permettant de supporter ce processus d'organisation, sous forme de module intégrable au CMS libre Drupal.

Le projet consistera :

  • à définir de manière précise le cahier des charges fonctionnel en étudiant les solutions similaires, et en collaboration avec le responsable du projet ;
  • à définir l'architecture de la solution en fonction de l'API de Drupal ;
  • enfin, à développer la solution.

Modifications/améliorations du logiciel Marsouin - Cyril Fonlupt et Denis Robilliard

Etudiants : ??

Description

Le logiciel Marsouin est un logiciel développé au sein du Laboratoire d'Informatique du Littoral utilisé par l'IFREMER (Institut Français de Recherche et d'Exploitation de la Mer) qui permet de reconnaître de manière automatique des tourbillons dans les océans à partir de cartes de courants provenant de différentes sources (satellites, simulations hydrodynamiques, ...).

Les tourbillons sont automatiquement numérotés, leurs surfaces sont évaluées ainsi que diverses informations utiles pour les chercheurs de l'IFREMER (sens du courant, centre du tourbillon, ...)

Fichier:Marsouin1.jpg

Les fichiers fournis en entrée sont codés au format NetCDF qui est un format très utilisé par la communauté travaillant sur les sciences de la terre.

Le format de sauvegarde généré est actuellement textuel et graphique.

But du projet

Les objectifs du projet sont multiples :

  • il s'agit dans un premier temps de se familiariser avec logiciel entièrement écrit en JAVA et de permettre la sauvegarde des données directement au format NetCDF ;
  • il faudra ensuite améliorer la prise en charge 3D qui a débuté mais n'est pas terminé (cf image ci-dessous)

Fichier:Marsouin2.jpg


Implémentation d'une API permettant de jouer au jeu SAMURAI - Cyril Fonlupt et Denis Robilliard

Etudiants : ??

Description

SAMURAI est un jeu de stratégie très simple pouvant être joué de 2 à 4 personnes. Il simule le contrôle des îles du Japon par différentes faction. Les règles sont rappelées ci-dessous mais peuvent être consultées à l'adresse suivante : http://www.trictrac.net/index.php3?id=jeux&rub=detail&inf=detail&jeu=200.

Le but de ce projet est de développer une interface permettant de simuler le placement des différents pions du jeu et de vérifier que les pions posés respectent les règles et de résoudre les différents types de combat. Il ne s'agit pas de développer une intelligence artificielle pour le jeu, il s'agit de développer une API la plus documentée possible en JAVA permettant de simuler le plateau de jeu pour deux à quatre joueurs.

Cette API devra être construite de manière à être appelé le plus simplement possible à partir d'autres classes en JAVA.

Ce jeu a déjà fait l'objet d'un logiciel non libre et qui n'est plus suivi maintenant dont vous pourrez vous inspirer pour réaliser l'interface graphique : http://www.klear.com/new/games/samurai/

Principales règles de Samurai

  • Le matériel de jeu
    • Les puissances politiques : 39 statuettes divisées en trois groupes : 13 casques représentant la noblesse, 13 bouddhas pour les prêtres et 13 rizières pour les paysans.
    • Vos forces : 20 tuiles par joueur (5 samouraïs, 3 navires, 1 rônin, 3 bouddhas, 3 rizières, et 3 casques, 1 tuile permettant d'interchanger 2 statuettes du plateau, et 1 autre tuile permettant d'interchanger 2 tuiles du plateau). Certaines tuiles sont décorées d'un idéogramme japonais.
    • 1 paravent par joueur qui fait office de mémo.
    • 1 plateau de jeu en 4 parties.
  • Le placement des puissances politiques
    • Suivant le nombre de joueur vous utiliserez 2, 3 ou les 4 parties du plateau de jeu.
    • Chacun des joueurs choisit 5 tuiles secrètement et les disposent derrière son paravent. Ses 15 autres tuiles sont déposés face cachée sur la table et constituent votre pioche.
    • Chaque joueur à tour de rôle va devoir placer une statuette d'abord dans chaque ville (qui peuvent contenir 2 statuettes différentes) ensuite dans chaque village (1 statuette maxi par village). Une fois toutes les statuettes posées le jeu peut enfin commencer.
  • Le positionnement de vos forces
    • À tour de rôle, chaque joueur doit poser une tuile sur les hexagones libres du plateau. Il peut s'il le désire jouer jusqu'à 4 tuiles supplémentaires mais elles doivent être pourvues d'un idéogramme japonais. À la fin de son tour le joueur récupère dans sa pioche autant de tuiles qu'il a jouées.
  • À moi les forces politiques du Japon !
    • Dès qu'une case contenant une statuette est entièrement encerclée de tuiles, le joueur obtenant le total le plus élevé (des tuiles entourant la statuette bien sûr) capture la statuette.
  • Comment gagner ou l'art d'être un bon Samouraï.
    • Dès que la dernière statuette est capturée, la partie est finie et le vainqueur est désigné. Oui, mais comment ? Bah c'est tout simple : le joueur possédant la majorité des statuettes dans au moins deux forces politiques a gagné. Si ce cas n'arrive pas, alors le joueur désigné vainqueur doit avoir une majorité dans une force politique et plus de statuettes que ses adversaires ayant eux aussi une majorité dans une autre force politique (relisez une seconde fois c'est plus clair).

Un web-bot agrégateur de votes pour le site trictrac.net - Denis Robilliard, Cyril Fonlupt et Mourad Bouneffa

Etudiants : ??

Objectif :

Le site trictrac.net est dédié aux jeux de réflexion (jeux de plateau, jeux de cartes, jeux de stratégie,...). Il offre notamment la possibilité, aux joueurs qui s'enregistrent, de noter les jeux sur une échelle de 1 à 5. On dispose donc d'une base de données de "votes" ou "d'opinions" que l'on pourrait utiliser pour orienter le choix d'une personne souhaitent acquérir un nouveau jeu (le même principe peut être utilisé pour d'autres applications : choix d'un film à voir, ou d'un album musical à acheter en fonction d'une liste de critiques, etc...).

Public ciblé : M1 ou M2 ; nécessite des connaissances en web et en base de données (php, mysql).

Description du projet

On appellera "joueur" une personne ayant enregistré un vote sur le site tric-trac. Les joueurs peuvent être identifiés par leur pseudonyme enregistrés en même temps que leur vote. L'application parcourra automatiquement le site trictrac pour charger dans sa propre base les données (jeux, joueur, votes) disponibles sur trictrac. On pourra faire des mises à jour de la base en fonction de l'évolution du site (apparition de nouveaux jeux ou joueurs,...).

On appellera "client" la personne qui souhaite recevoir un avis construit par l'aggrégateur de votes. Pour donner un avis pertinent, l'application doit "connaître" le client. Pour cela on demandera au client de saisir et de noter les jeux qu'il possède déjà (la saisie sera facilitée par une recherche/complétion automatique dans la base). Ces renseignements seront stockés dans la base et pourront être édités à la demande du client.

Le logiciel recherchera dans sa base les joueurs qui ont voté pour au moins un des jeux renseignés par le client. Chacun de ces joueurs se verra attribuer une "confiance" basée d'une part sur le nombre de jeux qu'il a noté et qui sont renseignés par le client (le plus est le mieux), d'autre part sur la similitude entre les notes qu'il a accordées et celles du client pour ces mêmes jeux (plus il ressemble au client, plus son vote est fiable).

L'application construira ensuite la liste des jeux non possédés par le client pour lesquels ces joueurs ont voté. On construira une synthèse des opinions sur chacun de ces jeux en pondérant les votes par la confiance. Puis on affichera les "meilleurs jeux" par ordre décroissant des votes (un peu à la manière de Google). On pourra afficher aussi sur une requête portant sur un jeu donné, quelle est sa note moyenne (issue directement des données trictrac) et quelle est sa note "corrigée" (sythèse des notes des joueurs ressemblants).

Plan de réalisation

Le projet s'organisera autour des phases suivantes :

  • extraction de données
  • définition d'une API et construction d'une l'interface web
  • calcul des indices de confiance et des listes de jeux
  • calcul des synthèses des votes

Un joueur artificiel pour "San Juan" - Denis Robilliard et Cyril Fonlupt

Etudiants : ??

Objectif : Réaliser un joueur artificiel pour le jeu de cartes "San Juan".

Liens externes

Public ciblé : constitue une bonne introduction (L3, M1) ou approfondissement (M2) à l'intelligence artificielle pour tout étudiant motivé par cette thématique.

Matériel : 110 cartes "bâtiment" mélangées et organisées en une pile "pioche" et une pile "défausse", 5 tuiles "cours du marché", 5 cartes "rôle".

Description du jeu

  • nombre de joueur : de 2 à 4.
  • Début du jeu : chaque joueur reçoit une main de 4 cartes et un bâtiment "teinturerie d'indigo" posé devant lui. L'un des joueurs est nommé "gouverneur" pour ce tour. Les tuiles des cours du marché (voir plus bas) sont mélangées.
  • Déroulement d'un tour : chaque joueur en commençant par le gouverneur choisit un parmi les 5 rôles disponibles non encore utilisé ce tour. Tous les joueurs effectuent l'action indiquée par le rôle, le joueur qui a choisit le rôle bénéficie en plus du privilège associé au rôle. Lorsque tous les joueurs ont choisit un rôle, le joueur suivant devient gouverneur et chaque joueur ne peut conserver que au maximum 7 cartes dans sa main.
  • Description des rôles :
    • Bâtisseur : chacun peut construire un bâtiment (le poser devant soi) en payant son coût (défausser autant de cartes de sa main que le coût du bâtiment), privilège : coût réduit de 1.
    • Conseiller : chacun peut piocher 2 cartes et en conserver 1 dans sa main et défausse l'autre, privilège : piocher 5 cartes au lieu de 2 et en défausser 4.
    • Chercheur d'or : ne rien faire, privilège : piocher une carte et l'ajouter à sa main.
    • Producteur : chacun peut produire 1 marchandise sur une carte bâtiment de production vide de son choix (on pioche une carte que l'on pose sur le bâtiment), privilège : produire 1 marchandise de plus.
    • Marchand : chacun peut vendre 1 des marchandises disponibles sur un bâtiment de production, privilège : vendre 1 marchandise de plus. Le cours des marchandises est déterminée par les cours du marché (voir plus bas), le joueur reçoit autant de cartes de la pioche que le cours de(s) la marchandise(s) vendue(s).
  • Cours du marché : il y a 5 tuiles donnant les cours du marché, respectivement de l'indigo, du sucre, du tabac, du café et de l'argent, avec les valeurs (1,1,1,2,2), (1,1,2,2,2), (1,1,2,2,3), (1,2,2,2,3), (1,2,2,3,3). les 5 tuiles sont mélangées puis empilée une fois en début de partie, puis on retourne la tuile du dessus à chaque fois que le rôle du marchand est choisi. Une fois les ventes effectuées, la tuile est replacée sous la pile.
  • Fin de partie : la partie se termine après la phase de construction où l'un des joueur pose son 12ème bâtiment. Le joueur ayant le plus de points de victoire (PV) associés à ses bâtiments construits est le gagnant. En cas d'ex-aequo ajouter aux PV le nombre de cartes de sa main et le nombre de marchandises produites disponibles.

Plan de réalisation

On adoptera une approche par "fonction cible" :

  • On déterminera des caractéristiques importantes du jeu que l'on exprimera sous forme de fonctions à valeur numérique (par exemple : nombre de cartes dans la main, nombre de PV de la main, coût minimum de construction de la main, nombre de bâtiment de productions, nombre de points de victoire déjà accumulés,..);
  • On associera une évaluation à la situation actuelle du joueur en faisant une somme pondérée des fonctions caractéristiques;
  • On fera apprendre à la machine les bonnes pondérations par un algorithme de renforcement simple, en faisant joueur la machine contre elle-même et contre un joueur humain.
  • On réalisera une interface minimale, qui sera améliorée en fonction de l'avancement du projet.

Description des cartes

Les bâtiments sont divisés en 2 catégories : bâtiments de production (5 types uniquement) qui peuvent être construits en nombre quelconque, et bâtiments administratifs qui ne peuvent être construits à plus d'un exemplaire par chaque joueur.

Fichier:Description des batiments SanJuan.gif

Intégration de tests unitaires dans une interface graphique - Gauthier Quesnel et Eric Ramat - INRA/LIL/ULCO

Etudiant : Guillaume Ansel

Information importante : ce projet est suivi obligatoirement d'un stage rénuméré à l'INRA pour l'étudiant

Mots-clés

  • Tests unitaires
  • Interfaces graphiques

Présentation du projet

Le projet VLE (Virtual Laboratory Environment) est une plate-forme de modélisation et de simulation développée à l'INRA de Toulouse, au Cirad et à l'université du Littoral. Cette plate-forme s'est dotée, depuis la fin d'un précédent stage de M1-I2L, d'une interface graphique qui permet aux modélisateurs et utilisateurs d'utiliser VLE de manière plus souple : gvle.

Depuis le début du développement de VLE, nous employons des méthodes agiles où l'emploi de tests unitaires est très important pour assurer une fonctionnalité maximale de la plate-forme. Cependant, l'interface graphique gvle, nouvellement développée, ne bénéficie d'aucun test unitaire. Dans ce projet, nous nous proposons d'ajouter un ensemble de tests unitaires de l'interface graphiques à l'aide d'outils spécifiques.

Ce projet est susceptible d'être suivi d'un stage rémunéré au sein de l'INRA. Le stage pourra être effectué à Toulouse ou à Calais sous les encadrements de Éric Ramat, Gauthier Quesnel et Patrick Chabrier avec pour sujet le développement de GVLE.

Objectif

L'objectif de ce projet est de proposer un ensemble de test unitaires afin de tester les possibilités de l'interface graphiques.

  • Rechercher un programme qui permet de tester les interfaces graphiques sous GNU/Linux et/ou Windows.
  • Intégrer ce programme au sein des outils de tests unitaires déjà employés : CMake.
  • Montrer la viabilité du système en découvrant des bogues et autres failles.

Langages et technologies

Plate-forme Web pour la gestion des plans d'expériences de VLE et Mexico - Eric Ramat - INRA/LIL/ULCO

Etudiants : Cyril Marcq et Daniel Salomé

Information importante : ce projet est suivi obligatoirement d'un stage rémunéré à l'INRA pour le binôme

Mots-clés

  • développement Web
  • exécution sur cluster

Présentation du projet

VLE est aujourd'hui disponible sous forme d'un exécutable modulaire pour la simulation de modèles à base d'événements discrets. Il s'accompagne aussi d'outils d'interface comme gvle ou eov pour la construction de modèles, l'exécution d'expériences simples et de visualisation temps-réel des simulations. Ces outils sont plutôt orientés mono-postes même si la visualisation temps-réel peut être déportée par rapport au noeud d'exécution de la simulation.

Dans ce projet, on se propose de construire, à partir d'un cluster de 8 serveurs SUN V20Z bi-processeurs et d'un serveur bi-processeur, un "petit" serveur de démonstration de vle en mode cluster. Ce serveur doit aussi embarquer un dépôt de modèles vle et des interfaces de gestion des expériences.

Objectif

L'objectif est de proposer une interface Web pour la définition et l'exécution de plans d'expériences. Il se découpe en plusieurs sous-projets :

  • le cluster :
    • recherche d'une distribution adéquate pour le clustering et installation sur le cluster
    • installation du noeud root et déploiement de l'architecture Web
  • les plans d'expériences :
    • étude de la solution de développement Web (Python) :
      • pour le framework Web : Pylons (le livre)
      • pour la persistance : SQLAchemy et SQLite (un livre)
      • pour les templates : Mako
      • pour l'AJAX : jQuery (communauté française)
      • pour l'URL dispatching : Routes
      • les paquets debian : python2.5, python-pylons, python-authkit, python-sqlalchemy, sqlite3, python-mako, libjs-jquery et python-routes (plusieurs paquets s'installent lors de l'installation du paquet python-pylons)
    • développement des scripts de définition d'un plan d'expériences simple (au sens VLE)
    • développement de scripts de définition de plan d'expériences complexes (au sens Mexico)
  • l'interface utilisateur :
    • gestion des accès (voir AuthKit de Pylons)
    • gestion des plans (archivage)
    • gestion des modèles (dépôt de modèles VLE - ssh via des comptes sur le serveur)
  • l'exécution sur le cluster :
    • exécution des plans sur le cluster
    • visualisation de la progression de l'exécution des plans
    • reporting d'exécution des plans
  • tracé de courbes de résultats avec matplotlib et SciPy à partir des sorties de simulations
    • courbes 2D (sortie, temps)
    • grilles (avec choix de la date de l'état à visualiser)
    • possibilité d'animation ???

Langages et technologies

  • Python - Pylons
  • Linux/clustering
  • bases de données

L3 info

Gestionnaire de liens web - David Duvivier

Etudiants : Rémy Debienne, Julie Bocquelet, et Loïk Hameaux

Objectif

Il s'agit de développer un outil permettant la gestion de liens internet (signets), présentés actuellement sous forme d'une liste sur une page web simple, les liens étant regroupés par thématique. L'objectif est de fournir une gestion plus avancée de ces liens (au travers d'une base de données), et d'intégrer un système de vote, permettant aux internautes de noter leurs liens préférés.

Parallélisation d'algorithme sur carte Nvidia 8800 - Denis Robilliard et Virginie Marion-Poty

Etudiants : Alexis Huet et Denis Jean

Objectif

Paralléliser sur GPU (cartes graphiques à haute puissance de calcul) l'algorithme d'optimisation CMA-ES. Le code source de l'algorithme est écrit en C, et devra être porté dans le langage CUDA, dérivé du C, pour être utilisé sur les cartes de la famille Nvidia série 8000.

Plan de réalisation :

  • documentation sur le principe de l'algorithme CMA-ES
  • prise en main de la version actuelle (en C)
  • documentation sur le langage CUDA, extension du C à la programmation parallèle sur GPU Nvidia
  • sélection des parties de code devant être parallélisées
  • ré-écriture en CUDA avec parallélisation
  • tests de performance

Base de données pour le calcul des services des enseignants - Christophe Renaud

Etudiants : Louise Heneman, Maxime Grare, Aurélien Delrue, et Jean-Charles Vernier

Description

Le calcul des services des enseignants du département informatique st actuellement effectué via une feuille de calcul excel. L'objectif de ce projet est, après analyse approfondie des besoins, de proposer une solution de type base de données (PHP, MySQL) permettant une gestion plus simple de ces services.

Résolution de grilles de sudoku - Christophe Renaud

Etudiants : Stéphane Bollengier et Kevin Gandolfi

Description

Ce projet a pour but de développer une (ou plusieurs) méthodes permettant, dans un premier temps, de résoudre des grilles de sudoku. Une seconde partie du projet consistera à développer une interface graphique permettant le chargement et la visualisation des grilles à résoudre.

Site web pour l'école du Sacré Coeur (Gravelines) - Grégory Bourguin

Etudiants : Kévin Zodros et Alexandre Leboucher

Description à venir

Un gestionnaire de références bibliographiques en PHP - Grégory Bourguin

Etudiants : Guillaume Radenne, Tatiana Pruvost, Gwendal Lerat, et Cyrille Lefaire (4 étudiants)

Sujet

Une bonne partie du travail des chercheurs étant de rédiger des articles s'appuyant sur les travaux existants dans leur domaine, les citations sous forme de référence bibliographiques ont une grande importance dans toute publication. Les mêmes références peuvent être citées dans plusieurs papiers et elles doivent souvent être mises en forme dans des styles qui diffèrent d'un éditeur à l'autre.

Le sujet de ce projet est de créer un gestionnaire de références, sous forme de BD MySQL avec une interface de type formulaire PHP. L'outil pourra entre autres permettre de stocker/éditer/supprimer des références, de retrouver des références sur divers critères et de mettre en forme le résultat d'une recherche en fonction d'un style particulier (et éventuellement d'un format de fichier).

Un outil Visual Basic Application de Mise en forme de références bibliographiques - Grégory Bourguin

Etudiants : ??

Sujet

Une bonne partie du travail des chercheurs étant de rédiger des articles s'appuyant sur les travaux existants dans leur domaine, les citations sous forme de références bibliographiques ont une grande importance dans toute publication. Si les mêmes références peuvent être citées dans plusieurs papiers, elles doivent souvent être mises en forme dans des styles qui diffèrent d'un éditeur à l'autre.

Le sujet de ce projet est donc de créer un outil en VBA qui permettra, à partir d'une liste de références non mises en forme sous Excel, de générer un format particulier à destination de Word.

Création d’un outil de suivi des heures d’enseignements dans les technologies du Web - Grégory Bourguin

Etudiants : Olivier Kowalski, Maxime Fiba, Mathieu Sgard, Valentin Henon, et Nicolas Duquesne (4 étudiants)

Objectif

Chaque année, les enseignants doivent effectuer un suivi de l’ensemble des heures de Cours/TD/ TP qu’ils ont effectuées. Ce suivi doit être effectué pour chaque formation et pour chaque matière enseignée. Une « application » a déjà été créée sous forme de tableaux Excel accompagnés de macros en Visual Basic Application. Le but de ce projet est de transposer cette « application » dans une nouvelle écrite en PHP, MySQL, (D)HTML, AJAX, ou toute autre technologie qui réponde aux objectifs fixés.

Etapes :

  • appréhension du sujet (etude de l’application existante)
  • choix technologiques
  • réalisation

Création d’un outil de suivi des heures d’enseignements en Java - Grégory Bourguin

Etudiants : Fabien Geldhof, Thibaut Beasse, Cyril Leroy, et Kévin Prevost (4 étudiants)

Objectif

Chaque année, les enseignants doivent effectuer un suivi de l’ensemble des heures de Cours/TD/ TP qu’ils ont effectuées. Ce suivi doit être effectué pour chaque formation et pour chaque matière enseignée. Une « application » a déjà été créée sous forme de tableaux Excel accompagnés de macros en Visual Basic Application. Le but de ce projet est de transposer cette « application » dans une nouvelle écrite en Java (interfacé avec une base de données ou avec génération de fichiers type XML).

Etapes :

  • appréhension du sujet (etude de l’application existante)
  • choix technologiques
  • réalisation

Mise en œuvre d’une approche objet/composant en Flash - Grégory Bourguin

Etudiants : Bertrand Devos

Objectif

Le but de ce projet est de rendre plus génériques certains éléments constituant le site www.lamesoeur.fr. En particulier, une des animation de ce site propose une « ronde de photos » fonctionnant selon un algorithme assez complexe, actuellement fonctionnel, mais peu générique.

Etapes :

  • familiarisation à l’environnement Flash
  • compréhension de l’approche de développement de composants paramétrables sous flash
  • Mise en œuvre de cette approche pour la création d’un composant « ronde de photos » aisément paramétrable (en adaptant l’algorithme existant).

Traduction d'un script pour Excel écrit en Visual Basic au format OpenOffice OOoBASIC - Cyril Fonlupt

Etudiants : ??

mots-clés : Excel, OpenOffice, Visual Basic, OOoBASIC

Présentation du projet

Il s'agit de traduire un scipt Excel écrit en Visual BASIC gérant un jeu de stratégie appelé Puerto Rico. Il s'agit de traduire ce script intégralement en OOoBASIC et de faire un mini manuel de référence sur les principales instructions du langage OooBASIC.

Résumé :

  • lecture et documentation sur le langage OOoBASIC ;
  • traduction du script ;
  • écriture d'un manuel de référence des principales instructions du langage OOoBASIC.

Un joueur artificiel pour le jeu "Hansa" - Denis Robilliard

Etudiants : Benoït Biernacki, Rémy Desrivieres, David Sauvage, et Benjamin Chaudet

Objectif : réaliser une interface et un joueur artificiel (2 binômes) pour le jeu de plateau "Hansa" (illustré ci-dessous).

Fichier:Plateau hansa.jpg

Documents

Liens externes

Plan de réalisation

  • documentation et compréhension des règles du jeu
  • définition d'une API adaptée à la simulation des différentes phases de jeu
  • Binôme "interface" :
    • choix d'un langage/environnement graphique
    • réalisation de l'interface graphique
  • Binôme "joueur artificiel" :
    • conception d'une fonction d'évaluation du prochain coup
    • recherche et implantation des algorithmes classiques "minimax" et "alpha-béta" (voir wikipedia)
  • tests et corrections

Un joueur artificiel pour "San Juan" - Denis Robilliard et Cyril Fonlupt

Etudiants : ??

Objectif : Réaliser un joueur artificiel pour le jeu de cartes "San Juan".

Liens externes

Public ciblé : constitue une bonne introduction (L3, M1) ou approfondissement (M2) à l'intelligence artificielle pour tout étudiant motivé par cette thématique.

Matériel : 110 cartes "bâtiment" mélangées et organisées en une pile "pioche" et une pile "défausse", 5 tuiles "cours du marché", 5 cartes "rôle".

Description du jeu

  • nombre de joueur : de 2 à 4.
  • Début du jeu : chaque joueur reçoit une main de 4 cartes et un bâtiment "teinturerie d'indigo" posé devant lui. L'un des joueurs est nommé "gouverneur" pour ce tour. Les tuiles des cours du marché (voir plus bas) sont mélangées.
  • Déroulement d'un tour : chaque joueur en commençant par le gouverneur choisit un parmi les 5 rôles disponibles non encore utilisé ce tour. Tous les joueurs effectuent l'action indiquée par le rôle, le joueur qui a choisit le rôle bénéficie en plus du privilège associé au rôle. Lorsque tous les joueurs ont choisit un rôle, le joueur suivant devient gouverneur et chaque joueur ne peut conserver que au maximum 7 cartes dans sa main.
  • Description des rôles :
    • Bâtisseur : chacun peut construire un bâtiment (le poser devant soi) en payant son coût (défausser autant de cartes de sa main que le coût du bâtiment), privilège : coût réduit de 1.
    • Conseiller : chacun peut piocher 2 cartes et en conserver 1 dans sa main et défausse l'autre, privilège : piocher 5 cartes au lieu de 2 et en défausser 4.
    • Chercheur d'or : ne rien faire, privilège : piocher une carte et l'ajouter à sa main.
    • Producteur : chacun peut produire 1 marchandise sur une carte bâtiment de production vide de son choix (on pioche une carte que l'on pose sur le bâtiment), privilège : produire 1 marchandise de plus.
    • Marchand : chacun peut vendre 1 des marchandises disponibles sur un bâtiment de production, privilège : vendre 1 marchandise de plus. Le cours des marchandises est déterminée par les cours du marché (voir plus bas), le joueur reçoit autant de cartes de la pioche que le cours de(s) la marchandise(s) vendue(s).
  • Cours du marché : il y a 5 tuiles donnant les cours du marché, respectivement de l'indigo, du sucre, du tabac, du café et de l'argent, avec les valeurs (1,1,1,2,2), (1,1,2,2,2), (1,1,2,2,3), (1,2,2,2,3), (1,2,2,3,3). les 5 tuiles sont mélangées puis empilée une fois en début de partie, puis on retourne la tuile du dessus à chaque fois que le rôle du marchand est choisi. Une fois les ventes effectuées, la tuile est replacée sous la pile.
  • Fin de partie : la partie se termine après la phase de construction où l'un des joueur pose son 12ème bâtiment. Le joueur ayant le plus de points de victoire (PV) associés à ses bâtiments construits est le gagnant. En cas d'ex-aequo ajouter aux PV le nombre de cartes de sa main et le nombre de marchandises produites disponibles.

Plan de réalisation

On adoptera une approche par "fonction cible" :

  • On déterminera des caractéristiques importantes du jeu que l'on exprimera sous forme de fonctions à valeur numérique (par exemple : nombre de cartes dans la main, nombre de PV de la main, coût minimum de construction de la main, nombre de bâtiment de productions, nombre de points de victoire déjà accumulés,..);
  • On associera une évaluation à la situation actuelle du joueur en faisant une somme pondérée des fonctions caractéristiques;
  • On fera apprendre à la machine les bonnes pondérations par un algorithme de renforcement simple, en faisant joueur la machine contre elle-même et contre un joueur humain.
  • On réalisera une interface minimale, qui sera améliorée en fonction de l'avancement du projet.

Description des cartes

Les bâtiments sont divisés en 2 catégories : bâtiments de production (5 types uniquement) qui peuvent être construits en nombre quelconque, et bâtiments administratifs qui ne peuvent être construits à plus d'un exemplaire par chaque joueur.

Fichier:Description des batiments SanJuan.gif

Développement d’un site web : Semiotics of Law - Anne Wagner et Arnaud Lewandowski

Etudiants : Grégory Lengagne, Adrien Kutak, Déborah Soots, et Yann Lawuy (4 étudiants)

Contexte

Depuis 20 ans, la sémiotique juridique s’est développée dans le monde et nous souhaitons rendre nos travaux de recherche, nos bases de données, nos références bibliographiques visible sur le Net à tous ainsi que de créer un forum de discussion et des accès sécurisés pour nos membres afin de présenter des travaux en cours.

Objectif

L'objectif est de proposer une solution web (php, mysql) assurant les fonction suivantes :

  • Présentation dynamique du site avec des informations sources et clefs pour tout public sur nos différents axes de recherche.
  • Gestion sécurisée des accès via des sessions
  • Différents modes de travail (administrateur, comité scientifique, membres)
  • Planification des différentes conférences et gestion des modifications
  • Mise en place d’une base de données de nos membres et mise à jour automatique
  • Mise en place des CV du comité scientifique avec possibilité de remise à jour
  • Construction automatique de références bibliographiques et gestion des modifications par l’administrateur.
  • Mise en place d’un forum de discussion sécurisé

Module de gestion des projets étudiants - Arnaud Lewandowski

Etudiants : Vincent Sajot et Vincent Prieur et Abdel Ali Massaki

Description du projet

Il s'agit de développer une application permettant de faciliter la gestion des projets étudiants. L'application devra notamment permettre de gérer:

  • la proposition de sujets par les enseignants (description du projet, filière concernée, illustrations, liens, etc)
  • l'affectation des sujets aux étudiants
  • la génération de fiches pré-remplies (format pdf) pour faciliter l'évaluation des soutenances
  • etc.

Langages et Technologies : php, mysql, javascript

Développement d'un gestionnaire d'enchères pour eBay en Java/Swing - Arnaud Lewandowski

Etudiants : Marie-Laure Rochoy et Min Cheng

Description du projet

Le but du projet est, dans un premier temps, d'analyser et de se familiariser avec l'API développée et proposée par eBay pour la gestion des enchères, eBay étant un site Web de ventes aux enchères mondialement utilisé.

Dans un deuxième temps, il s'agit de réaliser un gestionnaire d'enchères en Java/Swing qui soit donc multi plate-formes. Le client développé devra notamment permettre de mettre en vente de nouveaux objets, d'assurer le suivi des objets déjà en vente ainsi que des objets (in)vendus.

Liens

Gestion des bibliothèques Gtk avec CMake - Gauthier Quesnel - INRA

Etudiants : ???

Mots-clés

  • Scripts CMake
  • Détection de bibliothèques multi-plateforme

Présentation du projet

Le projet VLE a fait le choix en 2007 d'abandonner les autotools du projet GNU pour le programme CMake pour la gestion de la compilation. Ce changement a été énormément profitable à l'ensemble du projet pour simplifier la génération des versions Windows de VLE ainsi que d'augmenter la rapidité de compilation.

VLE utilise les normes de codage des projets GNU et plus particulièrement les scripts pkgconfig qui permettent de simplifier énormément la gestion des dépendances entre bibliothèques et de fournir à l'utilisateur la liste des paramètres de compilation. Par exemple :

homer@brulle ~ $ pkg-config --cflags gtk+-2.0
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1
homer@brulle ~ $ pkg-config --libs gtk+-2.0
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0
-lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0  

L'utilisateur, pour compiler un fichier peut ainsi simplifier ses lignes de compilation :

$ gcc -c fichier.c `pkg-config --cflags gtk+-2.0`
$ gcc -o exe fichier.o `pkg-config --libs gtk+-2.0`

Le fichier fournissant ces informations et les liens de dépendances est :

homer@brulle ~ $ cat /usr/lib/pkgconfig/gtk+-2.0.pc 
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
target=x11

gtk_binary_version=2.10.0
gtk_host=i486-pc-linux-gnu

Name: GTK+
Description: GIMP Tool Kit (${target} target)
Version: 2.12.9
Requires: gdk-${target}-2.0 atk cairo
Libs: -L${libdir} -lgtk-${target}-2.0 
Cflags: -I${includedir}/gtk-2.0 

Le projet CMake fournit également un script d'utilisation du programme pkgconfig (/usr/share/cmake-2.6/Modules/FindPkgConfig.cmake). Cependant, celui-ci n'est pas suffisant pour une gestion correcte de la norme de CMake 2.6 et est très difficile à utiliser sous Windows.

Pour ce projet, nous proposons d'écrire un ensemble de scripts CMake pour les différentes bibliothèques utilisées par VLE : Gtkmm, libxml++ et Cairomm. Ces scripts doivent suivre la ligne de conduite de CMake et être multi-plateforme.

Objectif

  • Comprendre le fonctionnement des scripts CMake
  • Implémenter le script de détection de la libxml++ en ce basant sur le script FindLibXml2.cmake et de la même façon, un script pour chaque bibliothèques C puis C++ :
    • Glib, Gobject, GIO, Pango, ATK, GdkPuixbuf, GDK, GTK et Cairo
    • Glibmm, Gdkmm, Gtkmm et Cairomm
  • Tester l'ensemble de ces scripts sur différentes distributions Linux et Windows.
  • Proposer l'ensemble des scripts aux administrateurs du projet [1].
  • Création d'un script FindVLE.cmake

Langages et technologies

Gestion de la documentation du projet VLE avec Doxygen - Gauthier Quesnel et Eric Ramat - INRA/LIL/ULCO

Etudiants : Aurélie Blot

Mots-clés

  • génération automatique de documentations
  • multiformats

Présentation du projet

Le projet VLE (Virtual Laboratory Environment) est une plate-forme de modélisation et de simulation développée à l'INRA de Toulouse, au Cirad et à l'université du Littoral. Dans le cadre de ce projet, nous avons mis en place une stratégie de documentation du code basée sur Doxygen. Aujourd'hui, nous en avons une utilisation classique : génération d'une documentation de l'API C++ de VLE sous forme de pages Web. Cette documentation est générée automatiquement toutes les nuits. On aimerait maintenant aller plus loin et intégrer dans la documentation des tutoriels, des exemples, ... afin de générer diverses formes de documentation (de type Reference guide, de type Getting Started, de type livre, ...) et sous divers formats (html, latex, ...).

Objectif

  • étude des possibilités de doxygen
  • rédaction des directives de rédaction de la documentation
  • création des templates pour les différentes formes de documentation
  • mise en place de la génération automatique

Langages et technologies

Modélisation de la demande en eau dans le cadre de modélisation proposé par RECORD - Application à une région du Sud-Ouest de la France - Hélène Raynal et Eric Ramat - INRA/LIL/ULCO

Etudiants : Carole Lemort et Emilie Martinot

Information importante : ce projet est suivi obligatoirement d'un stage rémunéré à l'INRA pour un étudiant du binôme

Mots-clés

  • modélisation et simulation
  • modèles à événements discrets de climats et de plantes

Présentation du projet

L'irrigation est un moyen en agriculture d 'intensifier les rendements, mais pose le problème de la gestion de l'eau. En effet, on constate que dans les régions où on pratique l'irrigation, jusqu'à 90% de l'eau consommée concerne l'agriculture. Cette eau est pompée dans les rivières ou les nappes phréatiques. Cela entraîne donc des conflits d'intérêt entre l'approvisionnement en eau potable, l'irrigation agricole et le maintient d' un débit minimal dans les cours d'eau. Ceci est d'autant plus exacerbé que l'on se trouve dans une région qui connait la sécheresse estivale, comme la zone du Sud-Ouest (entre Toulouse et Tarbes) pour laquelle nous disposons de nombreuses données. Les gestionnaires d'eau (l'agence qui gère tout un bassin versant par exemple) sont donc amenés à estimer quelle sera la demande et en particulier celle concernant l'agriculture. C'est à ce niveau qu'intervient le travail de modélisation effectué par les chercheurs agronomes.

Dans un 1er temps, nous nous intéresserons à déterminer les dates de semis du maïs, qui est une culture très gourmande en eau, bien représentée dans le Sud-Ouest. La date de semis est un élément important dans la détermination du pic de demande en eau de cette culture. Plus on sème tôt, plus le pic de demande en eau interviendra avant la période d'étiage des cours d'eau. Mais si on sème trop tôt, le froid et l'humidité risque de pénaliser la culture.

Objectif

­* Se familiariser avec VLE qui est la plate-forme de modélisation et simulation en programmant quelques modèles simples.

  • ­ Programmer dans cet environnement un modèle de culture existant. Il décrit quotidiennement l'évolution de la plante en fonction de la météo du jour. Ce modèle est couplé à un modèle de décision qui modélise le comportement de l'agriculteur (il décide de semer, d'arroser tel jour ...etc). On obtient un simulateur.
  • ­ Organisation des données pour tester différents scénarios: je dispose pour la région Toulouse-Tarbes de beaucoup de données climatiques, sol, type d'exploitations. Il faudra réfléchir à leur organisation en BDD ou dans un SIG car certaines d'entre-elles sont spatialisées (on dispose de leurs coordonnées Lambert). Ce système d'information servira à paramétrer le simulateur. A ce niveau du travail, il faudra proposer un couplage approprié entre la plate-forme VLE et le SGBD ou le SIG. (passer par les packages R, modèle DEVS ...?). Pour le SIG, nous souhaitons rester dans le domainde du libre, on pense donc à GRASS. Pour le SGBD, idem donc MySQL ou autre.
  • ­ Simulations : faire tourner le simulateur sur les différents points de la BDD ou SIG définis précédemment, en utilisant différentes années climatiques.

­* Analyse des simulations :

    • comparer les résultats à ceux obtenus avec d'autres modèles qui ont été programmés cet été. Ceci se fera en utilisant les techniques statistiques de comparaison de modèles.
    • analyse de l'impact du changement climatique sur les résultats. On dispose pour cela de données prévisionnelles fournies par Météo France.

­* Si on a le temps, pourquoi pas essayer :

    • de changer de modèle de décision en utilisant réseau de Petri ;
    • de faire de la méta-modélisation, dans le sens : simplifier le modèle.

Langages et technologies

  • C/C++ pour l'écriture des modèles
  • cmake pour la génération des Makefiles
  • boost comme API C++
  • git pour le versioning du code
  • Mysql ou PostGreSQL pour les bases de données
  • GRASS pour le SIG