Définition d'un descripteur primitif d'Analysis Engine

Ce post est en lien avec le post Développer son premier composant UIMA : l'Analysis Engine (AE) 

La dernière étape consister à créer un descripteur indiquant au framework UIMA comment utiliser le composant. En particulier il définit la classe métier de l'Annotator, le Type System manipulé, les Types qui sont utilisés comme input et ceux qui seront des output. C'est aussi ici que sont déclarés les paramètres et les ressources partagées utilisés si il y a lieu.

La création du descripteur du composant est facilitée à travers Eclipse et les plugins installés. Dans le répertoire desc/opinionRecognizer du projet (ou seulement desc si vous n'avez pas packagé votre projet) :

• Créer le fichier descripteur du composant, opinionRecognizerAE.xml en cliquant dessus avec le bouton droit et New - Other - UIMA - Analysis Engine Descriptor File.
• Sur la première page (onglet Overview accessible au bas du cadre) spécifier le nom de la classe qui implémente votre code métier (i.e. opinionRecognizer.OpinionRecognizerAE).
• Sous l'onglet Type System, ajouter (Add) par nom (by name) le type system défini pour votre composant (i.e. desc/opinionRecognizer/opinionRecognizerTS.xml).
• Enfin sous l'onglet Capabilities, spécifiez les types des annotations qui doivent apparaître en sortie (i.e. SentenceAnnotation, TokenAnnotation et Opinion).

Si en cliquant sur ce fichier pour l'ouvrir, vous n'accédez qu'à son contenu XML, alors demandez d'ouvrir avec le Component Descriptor Editor en cliquant sur le fichier avec le bouton droit.

Implémenter le code métier d'un composant Analysis Engine

Ce post est en lien avec le post Développer son premier composant UIMA : l'Analysis Engine (AE) 

La seconde étape correspond au développement du code métier du composant.

Le code métier d'un AE est à minima constitué d'une classe dite Annotator qui étend la classe JCasAnnotator_ImplBase du framework UIMA. En particulier, on trouve le code métier dans une méthode surchargée appelée process qui est automatiquement appelée à l'exécution pour chaque CAS traitée. La méthode process a accès au CAS et via l'API d'UIMA elle peut manipuler l'artifact ou les (index d') annotations qui ont été précédemment ajoutées ou bien en ajouter de nouvelles.

La classe JCasAnnotator_ImplBase est une implémentation par défaut de la classe AnalysisComponent. Cette implémentation par défaut implémente toutes les méthodes exceptée la méthode process. En général on travaille directement à partir de celle-ci quitte à surcharger les méthodes déjà implémentées. 

La classe AnalysisComponent a plusieurs méthodes dont les plus importantes sont initialize, process et collectionProcessComplete. La méthode initialize est appelée une fois par le framework UIMA à la création de la première instance de la classe Annotator ; elle sert par exemple à récupérer la valeur de paramètres ou à charger des ressources qui seront partagées par les différentes instances de la classe. La méthode process est donc appélée une fois par item traité. La méthode collectionProcessComplete est appelée quand l'entière collection a été traitée et sert à produire des résultats relatifs à toute la collection.

Dans cet exercice, vous n'aurez besoin que d'implémenter la méthode process.

Création de la classe Annotator

1. Dans le répertoire src, créer le package opinionRecognizer.
2. Au sein du package, créer la classe OpinionRecognizerAE. Par convention les classes Annotator se termineront par le suffixe AE.
3. Faire étendre la classe de JCasAnnotator_ImplBase
4. et surcharger la méthode process.

Cela doit donner quelque chose comme :

package opinionRecognizer;
import
org.apache.uima.analysis_component.JCasAnnotator_ImplBase;
import org.apache.uima.jcas.JCas;
import opinionRecognizer.types.*;
public class OpinionRecognizerAE extends JCasAnnotator_ImplBase{
    public void process(JCas aJCas)  {
        // Faire quelque chose
    }
}

Création du code métier au sein de la méthode process

La méthode process reçoit en argument une instance de JCas laquelle constitue le document analysé ainsi que toutes les annotations qui y ont été associées lors d'éventuelles précédentes analyses. Le JCas fournit une approche JNI (Java Native Interface) pour la manipulation des objets CAS et de leur propriétés (i.e.~avec des new, des getter/setter, ... Le framework UIMA se charge de passer le CAS d'un composant à un autre.

Pour cet exercice, l'analyseur devra ajouter une nouvelle annotation Opinion délimitée aux offsets (begin et end) de toutes les phrases SentenceAnnotation contenant des mots TokenAnnotation qui sont des verbes (posTag débutant par "vb" égal à "bez") ou dont la forme de surface coveredText est "we" ou "our". On ajoutera aussi le nombre de mots contenu dans l'opinion length.

L'algorithme que je propose d'implémenter est le suivant :

1. récupération d'un index de phrases SentenceAnnotation
2. parcourir l'index de phrases et pour chacune, 
1. récupérer un sous index de mots TokenAnnotation
2. parcourir l'index de mots et pour chaque mot
1. définir un booléen à vrai si un mot a son trait posTag débutant par "vb" égal à "bez"
2. définir un booléen à vrai si un mot a son trait forme de surface coveredText est "we" ou "our".
3. incrémenter un compteur de mots
3. si les deux booléens sont vrais alors
1. créer une nouvelle annotation Opinion aux offsets (begin et end) de la phrase courante
2. initialiser les valeurs begin, end et length de cette annotation

La récupération d'un index de phrases SentenceAnnotation peut se réaliser à l'aide de la méthode getAnnotationIndex appliquée au JCas et qui prend en argument le type d'annotation souhaité. Le parcourir de l'index de phrases peut se réaliser à l'aider d'un Iterator. 

Cela doit donner quelque chose comme :

AnnotationIndex<annotation>  aSentenceAnnotationAnnotationIndex = aJCas.getAnnotationIndex(SentenceAnnotation.type);
Iterator<annotation> aSentenceAnnotationIterator = aSentenceAnnotationAnnotationIndex.iterator(); 
while (aSentenceAnnotationIterator.hasNext()) { 
    SentenceAnnotation aSentenceAnnotation = (SentenceAnnotation) aSentenceAnnotationIterator.next();
    // Faire quelque chose
}

L'ajout du précédent code lève des erreurs de dépendances non importées (AnnotationIndex, Iterator, SentenceAnnotation).  Elles se résolvent très facilement par un left-click sur la petite croix rouge dans la marge de gauche au niveau de chaque erreur détectée et en optant pour le bon import.
Cette action sera à reproduire avec le code à venir.

La récupération d'un index d'annotations couvertes par une autre annotation peut se faire à l'aide de la méthode subiterator qui s'applique sur un index d'annotations et qui prend en argument l'annotation recouvrante.
Elle requiert la création d'un index d'annotations. Pour notre besoin, un index de mots TokenAnnotation peut suffire. Il se construit comme l'index de phrases vu ci-dessus. On décide de récupérer l'index de toutes les annotations pour varier les plaisirs. Il faudra alors ne considérer que les annotations mots qui nous intéressent.
L'instruction suivante réalise cela. On la place au même niveau que la construction d'index de phrases.

AnnotationIndex<annotation> anAnnotationIndex = aJCas.getAnnotationIndex();

A l'intérieur de la boucle, pour chaque phrase on récupère un FSIterator (qui est un iterator un peu spécial sur ce type de structure) sur les annotations couvertes par la phrase courant aSentenceAnnotation.

Cela donne 

FSIterator<annotation> anySubSentenceAnnotationFSIterator = anAnnotationIndex.subiterator(aSentenceAnnotation);
while (anySubSentenceAnnotationFSIterator.hasNext()) {
   Annotation aSubSentenceAnnotation = (Annotation) anySubSentenceAnnotationFSIterator.next();
   // Faire quelque chose
}

Si l'annotation couverte courante aSubSentenceAnnotation est un TokenAnnotation alors on teste si un mot a son trait posTag débutant par "vb" égal à "bez" et si un mot a son trait forme de surface coveredText est "we" ou "our" et l'on compte le mot.
Cela correspond au code ci-dessous

if (aSubSentenceAnnotation.getClass().getName().equalsIgnoreCase("org.apache.uima.TokenAnnotation")) {
    TokenAnnotation aWord = (TokenAnnotation) aSubSentenceAnnotation;
    if (aWord.getPosTag().toLowerCase().startsWith("vb") || aWord.getPosTag().equalsIgnoreCase("bez")) {
        containsAVerb = true;
    }
    if (aWord.getCoveredText().equalsIgnoreCase("our") || aWord.getCoveredText().equalsIgnoreCase("we")) {
        containsAKeyword = true;
    }
    wordCounter++;
}

Pour que ce code fonctionne il faut rajouter quelques déclarations de variables avant la boucle de parcours des annotations couvertes par l'annotation phrase courante.

boolean containsAVerb = false;
boolean containsAKeyword = false;
int wordCounter = 0;

Pour chaque phrase aSentenceAnnotation parcourue on teste si les présences d'un mot clef et d'un verbe sont confirmées. Dans la positive, on créer une nouvelle annotation Opinion. On définit ses traits begin et end en fonction des begin et end de la phrase courante. On définit aussi la longueur length de l'opinion. Et au final on ajoute l'annotation ainsi créée à l'index des annotations à l'aide de la méthode addToIndexes.
Ce qui donne le code suivant :

if ((containsAKeyword) && (containsAVerb)) {    Opinion aOpinion = new Opinion(aJCas);    aOpinion.setBegin(aSentenceAnnotation.getBegin());    aOpinion.setEnd(aSentenceAnnotation.getEnd());    aOpinion.setLength(wordCounter);    aOpinion.addToIndexes();}

Définir les types de données (type system) à manipuler au sein d'un composant UIMA

Ce post est en lien avec le post Développer son premier composant UIMA : l'Analysis Engine (AE) 

La première étape pour développer un composant est de définir les types de données qu'il va manipuler. 

Création du descripteur et des types de données à manipuler 

En lien avec notre exercice, nous allons définir le type d'annotation opinionRecognizer.types.Opinion qui correspondra au type des annotations produites par notre composant d'analyse. On lui ajoutera un trait (feature) length qui indiquera le nombre de mots contenu dans l'annotation Opinion courante. Par simplicité nous ne rappellerons pas par la suite le nom de package (opinionRecognizer.types) qui précède le nom du type.

D'abord créons le fichier descripteur :

Les fichiers descripteurs de systèmes de types et d'AE se placent dans le répertoire desc. Pour s'y retrouver ultérieurement parmi les descripteurs qui seront disponibles dans le CLASSPATH, je vous conseille de créer un sous répertoire portant le nom de votre projet (en respectant les conventions de nommage Java), par exemple ici : opinionRecognizer.

1. Faire un clic-droit sur le répertoire desc (ou sur le sous-répertoire que vous venez de créer si vous avez suivi mon conseil).
2. Choisir le menu 'New'-'Other...'-'UIMA'-'Type System Descriptor File'.
3. A l'écran suivant, donner un nom au fichier descripteur de types par exemple opinionRecognizerTS.xml. Là encore par convention et pour s'y retrouver plus tard je vous conseille d'utiliser le suffixe TS pour vos noms de fichier descripteur de systèmes de types.

Ensuite, une fois le fichier créé, ajoutons le type désiré  opinionRecognizer.types.Opinion : 

1. Dans l'onglet Type System du descripteur, ajouter un type avec le bouton Add Type.
2. Donner lui le nom de opinionRecognizer.types.Opinion
3. Le faire hériter du type uima.tcas.Annotation défini par le framework UIMA et qui permet d'hériter des traits begin, end et coveredText. Le trait coveredText est un trait un peu particulier parce que l'on ne peut y accéder qu'en lecture. Il retourne le texte de l'artifact couvert entre les offsets délimités par les valeurs entières begin et end.

Ajoutons aussi une feature au type :

1. En sélectionnant le type, cliquer sur le bouton Add...
2. Donner lui le nom de length qui indiquera le nombre de mots contenu
3. Faire hériter du type simple Integer.

Puisque nous manipulons aussi les types mot, org.apache.uima.TokenAnnotation, et phrase, org.apache.uima.SentenceAnnotation, qui sont des uima.tcas.Annotation et le trait posTag (String) du type TokenAnnotation dont les annotations auront été produits par les composants de prétraitement, il nous faut aussi ajouter ces types. Le faire.

Génération automatique des l'API JAVA du système de types

Une fois le fichier de descripteur de systèmes de type créé et sauvé, une API java permettant de manipuler les types (et les traits) est automatiquement générée. 

Si jamais vous craignez que cette API ne soit pas générer ou que vous vouliez forcer sa re-génération, cliquer sur le bouton JCasGen présent dans l'éditeur du fichier Système de Type.

Les fichiers Opinion.java et Opinion_Type.java sont générés dans le sous répertoire  opinionRecognizer.types du répertoire src du projet. 

Le fichier  Opinion.java  contient le constructeur de type. Noter la présence d'accesseurs pour modifier la valeur des attributs du type Opinion (par exemple les méthodes getLength() et  setLength(int v)).

Développer son premier composant UIMA : l'Analysis Engine (AE)

Objectifs 
Ce post présente ce qu'est le composant élémentaire de toute chaîne de traitement d'analyse UIMA à savoir l'Analysis Engine (AE). Il explique de quoi il se compose techniquement, et comment développer ses différentes parties.
Il s'agit entre autres de prendre en main l'API et les outils UIMA pour réaliser des opérations classiques : telles que définir des types d'annotation, générer automatiquement l'API pour manipuler les types d'annotations définis, récupérer des annotations posées par d'autres annotateurs, consulter et définir les valeurs de traits d'une annotation, créer une nouvelle annotation, créer un fichier XML descripteur et tester un composant.
Pour illustrer cet exercice de développement on cherchera à développer la fonction de reconnaissance de phrases qui expriment une opinion. On posera l'hypothèse qu'une phrase qui contient des verbes et des mots dont la forme de surface comme "we" ou "our" est une expression d'opinion... On utilisera pour cela quelques AE disponibles dans les Apache Uima Addons. On testera l'AE sur les textes présents dans le répertoire UIMA_HOME/examples/data notamment Apache_UIMA.txt. De fait nous travaillerons sur l'anglais pour cet exercice.


Prérequis

Il est nécessaire d'avoir réaliser les tutoriels suivant :

• Savoir construire une chaîne de traitement sous Eclipse sous la forme d'un Aggregate d'Analysis Engine (AAE)
• Savoir exécuter une chaîne de traitement (sous Eclipse, en ligne de commande ou via le DocumentAnalyzer GUI)

Tel que l'explique ces précédents posts, il faudra avoir au préalable construit et avoir à disposition une chaîne que nous appellerons de pré-traitement et qui sera composée des Apache UIMA addons suivant : 

• WhiteSpaceTokenizer qui découpe en mots, TokenAnnotation, et phrases, SentenceAnnotation, un texte fourni en entrée
• Tagger qui rajoute un trait posTag aux TokenAnnotation

Qu'est ce qu'un composant UIMA de type Analysis Engine et à quoi cela sert ?

Un Analysis Engine (AE) est le composant élémentaire d'une chaîne de traitements UIMA. Il a généralement pour objet une tâche d'analyse (par exemple reconnaître si une phrase est une expression d'une opinion) sur ce que l'on appelle un artifact (par exemple un texte). Il reçoit les résultats d'analyse de précédents composants (par exemple un découpage en phrases, en mots, la reconnaissance des étiquettes grammaticales (nom, verbe, adjectif...)) qui lui servent de base pour ses traitements afin qu'il puisse à son tour associer à l'artifact le résultat d'analyse qu'il produit (par exemple les opinions). On appelle les résultats d'analyse, des meta-données ou des annotations. L'ensemble formé par l'artifact et les méta-données constitue la structure commune d'analyse (CAS ou Common Analysis Structure) et est LA structure de donnée qui transite d'un composant à un autre.

De quoi est constitué un composant UIMA ?

Un composant UIMA est logiquement constitué de trois éléments :

• la définition des types des données que le composant manipule (lit et crée), on appelle cela le système de types (TS ou type system),
• le code métier qui réalise la fonction souhaitée,
• un descripteur indiquant au framework UIMA comment utiliser le composant.

Le système de types et le descripteur du composant sont des fichiers XML que l'on peut éditer avec des interfaces graphiques via les plugins Eclipse de UIMA. La définition du système de type entraîne la génération automatique d'une API pour manipuler les types de données définis au sein du code métier.

L'ensemble de ces éléments doit se trouver accessible via le CLASSPATH de l'application qui exécute. En général, on encapsule ces éléments au sein d'une même archive Jar.

Préparer un projet Java sous Eclipse pour accueillir le développement de votre composant

Il vous faut un projet Java sous Eclipse pour accueillir le développement de votre composant. Différentes options : 

• vous pouvez utiliser celui précédemment créé pour la chaîne de prétraitement 
• ou bien vous créez un nouveau projet comme indiquer ici mais il vous faudra alors déclarer une dépendance vers soit le projet qui contient votre chaîne de prétraitement soit vers le jar que vous aurez exporté à partir de celle-ci. Pour déclarer la dépendance au projet, Click droit sur le projet, Build path, Configure build path, Onglet Projects, Add les projets, Ok, OK...

Les étapes du développement

1. Définition des types de données (type system) à manipuler au sein d'un composant UIMA
2. Implémentation du code métier d'un composant Analysis Engine
3. Définition d'un descripteur primitif d'Analysis Engine 

Exécuter votre AE au sein d'un Aggregate

Au sein du répertoire desc/opinionRecognizer créer un descripteur aggregate qui ajoute en pipeline le descripteur de pretraitement et le descripteur de votre AE. N'oubliez pas de changer les capabilities.
Et exécutez le.

Pour aller plus loin

• la création et la récupération de vues,
• la définition des paramètres au sein du descripteur et leur accès au sein du code, 
• la déclaration et la manipulation de ressources partagées par plusieurs instances d'un même AE,
• le parcours d'index d'annotations à l'aide de contraintes

Remerciement

Le contenu décrit sur cette page s'inspire, adapte, étend le support créé pour le tutoriel qui a eu lieu à UIMA@RMLL'09 ainsi que le tutoriel Getting started de la documentation d'Apache UIMA.

Je vous invite à consulter ces différentes sources pour des informations complémentaires

Ajouter un dépot (repository) Maven à votre forge Google Code grâce à Subversion

Discutés aux deux adresses ci-dessous mais l'alternative d'utiliser un dépot public est conseillée

1. http://stackoverflow.com/questions/1280470/maven-repository-for-google-code-project
2. http://www.thewebsemantic.com/2009/04/11/your-very-own-google-code-maven-repo/

Mesurer le nombre de visites sur votre projet hébergé sous Google Code grâce à Google Analytics

Ce post décrit la procédure pour "track visits to Google code projects in Google Analytics".

1. Anyone may sign up for a free Google Analytics account. Once you have an account
2. Add a profile for a new domain and specify URL http://code.google.com/
3. Edit the profile that you just created to change its Website URL to http://code.google.com/p/votre-nom-de-projet/ 
4. Paste your Google Analytics profile's Web Property ID below and save changes. 
5. About 24 hours after you add your Web Property ID, your profile should begin to indicate that it is receiving data.

Publier une Javadoc sous forge Google Code

La procédure est la suivante

1. Récupérez la racine du projet
• svn checkout https://votre-nom-de-projet.googlecode.com/svn/ votre-nom-de-projet --username votre.username
• cd votre-nom-de-projet
2. Ajoutez un répertoire javadoc au versionning
• svn mkdir javadoc 
3. Réalisez l'export de la javadoc via Eclipse se sera plus simple
4. Ajoutez les fichiers javadoc au versionning
• svn add javadoc/*
5. Ajoutez les propriétés adéquates pour que svn interprète les fichiers de la javadoc  avec le bon type mime
• find  javadoc -name "*.html" -exec svn propset svn:mime-type text/html  {} + ;
• find  javadoc -name "*.css" -exec svn propset svn:mime-type text/css  {} + ;
• find  javadoc -name "*.jpeg" -exec svn propset svn:mime-type image/jpeg  {} + ;
6. Commitez vos ajouts
• svn commit javadoc/ -m "ajout de la javadoc"
7. Votre javadoc devrait être désormais accessible via l'url http://votre-nom-de-projet.googlecode.com/svn/javadoc/index.html ; ajoutez ce lien dans la section de links de Administer > Project Summary

Publier sur le Web et partager les droits d'édition à tous d'un Google document

Dans la quête de la recherche d'outils facilitant le travail collaboratif je tente d'utiliser un Google Document qui désormais offrent des fonctionnalités de partage des droits d'édition à tous (sans nécessité de posséder un compte) ainsi que de publication Web.

La procédure ci-dessous est légèrement différente de celle trouvée sur des réponses officielles (publication de vos documents et publication sur le web). Peut être est ce dû à un retard de mise à jour de la documentation ?

La procédure a été testée avec un Google Document, mais reste valable a priori pour tout type de documents (document, feuille de calcul, présentation...). Ici vous trouverez un exemple de Google Document publié et ouvert à l'édition (il s'agit d'un site sérieux merci de ne pas le modifier à moins que vous souhaitiez y contribuer).

Les deux actions, partage de la visibilité et publication sur le web, supposent que vous venez d'ouvrir ou de créer votre Google Document.

Pour partager la visibilité (notamment en édition) 

1. Cliquer sur l'icone "Share". Une fenêtre de configuration intitulée "Share settings" apparaît.
2. Cliquer sur "Change"  au niveau de la première ligne du tableau "Who has access" (par défaut l'accès est limité : "Private - Only the people listed below can access"). Une fenêtre intitulée "Visibility options" apparaît
3. Sélectionner  "Public on the web. Anyone on the Internet can find and access. No sign-in required."
4. Et enfin changer l'accès de "Can view" à "Can edit" au niveau de la ligne "Access:Anyone (no sign-in required)" qui a dû apparaître.

Pour publier sur le Web un Google document

1. Dans le menu File, cliquer sur "Publish to the Web". Une fenêtre "Control publishing" s'affiche.
2. Laisser coché "Automatically republish when changes are made".
3. Cliquer sur "Start publishing" et confirmer. Vous obtiendrez un lien vers le document publié
4. Par ailleurs, le lien par lequel vous éditiez votre document est désormais public. Vous pouvez le faire circuler.

Remarques

• Attention, il est important de noter que la publication sur le Web et sa visibilité sont deux concepts indépendants. 
• Les contributeurs du Web n'auront pas accès aux options de partage mais pourront intervenir sur la publication.
• Ils n'auront pas non plus accès à l'historique des modifications ("File > Revision history")
• Ils pourront télécharger le document dans divers formats (notamment PDF)
• Ils ne pourront pas changer les notifications qui sont propres à un compte à moins qu'ils ne soient connectés.

Rédaction d'un rapport de stage

Mise à jour le 23 mars 2011
Ce document doit encore être modifié notamment pour indiquer les livrables attendues à chaque étape du déroulement d'un projet.

A l'attention de mes étudiants, une compilation de conseils que j'ai glanés ces dernières années (merci à mes collègues).

Conseils de rédaction

• Faites des phrases courtes ou des listes plutôt que des longues phrases.
• Pour chaque phrase ou paragraphe, réfléchissez à l'effet que vous voulez produire sur le lecteur. Mettez vous à sa place et demandez vous si ce que vous avez écrit lui permet de comprendre le message que vous souhaitez lui faire passer.
• Faites suivre systématiquement la première apparition d'un terme spécifique à votre domaine d'une définition et d'un exemple illustrant ce qui tombe sous votre définition et ce qui n'est pas couvert par votre définition
• Expliquez toujours un acronyme lors de sa première occurrence
• Des schémas sont toujours bon car ils permettent souvent de comprendre plus rapidement.
• Pensez à faire des schémas assez légers. Les gros schémas peuvent toujours être simplifiés en regroupant des parties qui sont explicitées/détaillées ailleurs.
• Vous pouvez être amené à décrire le travail réalisé par quelqu'un d'autre que vous. Il faut que cela soit clairement dit. Vous avez le droit de faire des citations et le devoir de citer les sources dans une bibliographie en fin de votre document.
• La compréhension de votre rapport principal ne doit pas nécessiter de se reporter constamment aux annexes.
• N'hésitez pas à mettre quelques notes de bas de page. Ceux-ci ne doivent pas contenir des informations nécessaires à la compréhension seulement des complémentaires.
• Chaque figure doit avoir un titre (éventuellement une légende explicative), un numéro, et être référencée dans le texte. Une figure non citée par la suite fait perdre la piste de lecture.
• Préférez une numérotation des titres avec des chiffres plutôt que farfelue qui mélange lettres, chiffres et numération romaine
• Ayez un style sobre, aéré et consistant (choisissez vous une norme dès le départ, par exemple : ligne de code en "Courier New" ou "DejaVu sans mono" taille 10 aligné à gauche, texte normal en "arial" taille 10 ou 11 justifié, etc.).
• Numérotez vos pages.
• en tête et pied de page bien venu avec nom du projet (éventuellement abrégé) et noms des étudiants
• Pensez à faire une table des matières (éventuellement deux : une sommaire au début et complète à la fin)
• Faites un glossaire si nécessaire
• Ne recopiez pas introduction, résumé en français et en anglais, présentation de l'entreprise, conclusion d'anciens rapports de stage. Le plus souvent, ce sont de très mauvais textes qui sont recopiés !
• N'écrivez pas des choses que vous ne comprenez pas.

Contenu d'un rapport
Pour mes étudiants en DUT 2eme année, 30 pages environ.

Page de garde

• titre de votre projet
• date de réalisation (éventuellement numéro de version)
• noms des étudiants et leur groupe
• nom de l'encadrant
• logo des entités encadrantes ou commanditaires

Introduction 
Globalement 1 page avec un paragraphe par item.

• contexte du projet
• présentation du sujet qui doit être compréhensible pour quelqu'un qui n'est pas du domaine
• annonce du plan du rapport

Environnement

1-2 pages

• Situation de l'établissement où vous avez fait votre stage, au sein de l'entreprise
• Fonctionnalités de cet établissement (production, administration, etc.)
• Situation du service où vous avez fait votre stage, au sein de l'établissement de l'entreprise où vous avez fait votre stage
• Environnement matériel et logiciel dans lequel vous avez travaillé

Expression du besoin

Autour de 5 pages (essentiellement sur le détail de l'expression du besoin)

• Contexte détaillé : problèmes ayant amenés le client à proposer ce sujet, enjeux qui pourraient être solutionnés par votre travail
• Présentation de l'existant et de ses limites
• Situation de ce que vous avez réalisé au sein des applications existantes dans la solution utilisée auparavant par l'entreprise
• Brève description de ce qui vous a été fourni : documents ? ressources logicielles ? 
• L'expression des besoins qui vous a été fournie. Si celle-ci vous a été donnée sous forme écrite, la fournir entre guillemets. 
• L'environnement matériel et logiciel que vous deviez utiliser

Spécification (documents d'analyse)
10-12 pages

• Choix d'orientation : ce que vous avez décidé de faire/ne pas faire dans le projet, et la justification (faisabilité, temps, coût, complexité,...)
• Couche/package de votre architecture en dissociant les aspects métiers, IHM et interaction avec la base de donnée
• Modèle des données 
• Modèle des objets : 
• 1 ou + diagrammes de classe (découpage en package). Les attributs et rôles en français, les invariants en français. Si certaines relations d'héritage nécessitent des commentaires, vous pouvez les insérer dans le document
• Prototypage de l'interface homme machine
• Cas d'utilisation : 1 ou + diagrammes de cas d'utilisation
• Scénarios d'utilisation : diagrammes de séquence (scénario normal, avec alternatives et avec erreurs). Tests d'acceptation (suite d'opérations et résultats attendus dans une situation donnée)
• Diagramme d'états pour modéliser le comportement de chaque algo important

Conception
5-7 pages

• Choix d'implantation : 
• comment se traduit la spécification formelle en terme de langage objet ; pour chaque élément de l'analyse (classe, opération, relations), décrivez comment il sera réalisé (attribut de classe, méthode d'objet, méthode statique, instance de classe existante, nouvelle classe, etc.)
• chaque classe de l'analyse doit être identifiée avec soit une nouvelle classe, soit une classe existante
• chaque opération doit être associée à une classe pour en faire une méthode
• de même pour la mise en oeuvre au niveau de la base de donnée
• et de la conception de l'IHM
• Structure de fichiers du projet, les fichiers les plus importants
• Diagrammes d'interaction : pour chaque cas d'utilisation, donner 1 ou + diagrammes de séquence en utilisant les classes et méthodes définies dans les choix d'implantation.
• Description des opérations : pour chaque méthode critique, décrire son fonctionnement en pseudo-code ou en utilisant une machine à états.
• Description des cycles de vie : pour chaque classe qui le nécessite (dès l'instant que le cycle de vie n'est pas trivial), décrire le cycle de vie de ses objets par une machine à états.
• Tests unitaires : pour chaque classe, donner un jeu de test unitaire et de tests d'intégration. Préciser aussi l'ordre d'intégration des classes

Test de votre logiciel
0-4 pages

• Test boîte blanche vs test boîte noire, stratégie de test. Comment ont été constitués les jeux de test. Qui les a constitué ? Résultat des tests.
• Tests unitaires : trace d'exécution (ne doivent apparaître que les erreurs) + commentaires
• Tests de scénarios de l'analyse : mise à jour et complément éventuels des scénarios + résultats des tests + commentaires
• Synthèse : analyse de l'ensemble des tests, comparaison des résultats avec ce qui était prévu dans l'analyse et la conception

Démarche que vous avez suivie

2-4 pages

• La démarche de travail que vous avez suivi entre vous et avec votre encadrant
• Répartition formelle : qui est sensé faire quoi dans le groupe de projet, description précise du découpage des tâches pour la phase en cours
• Répartition effective : qui a fait quoi et quand (soit de manière hebdomadaire soit en découpant en 4 périodes : "avant le début officiel du projet en janvier au retour des vacances de noël", "depuis début Janvier et avant la semaine dédiée au projet et les vacances d'Hiver", "durant la semaine de projet", "après la semaine de projet et avant le rendu du rapport" . Si vous travaillez séparément, désignez un coordinateur.
• Compte rendu sur l'activité d'analyse, de conception, de codage et de test
• notamment les difficultés rencontrées : problèmes qui vous ont particulièrement gêné pendant l'analyse, la conception, la réalisation et les tests, autres
• Compte rendu sur le travail général

Conclusion
1 à 3 pages

• bilan de ce qui a été réalisé en regard de l'existant et de ce qui était attendu
• analyse et conception réalisée
• développement produit 
• test réalisé
• efforts pour la communication et la réutilisation
• commentaire du code
• packaging
• documentation produite (javadoc, guide utilisateur, ...)
• site web mise en place
• vidéo démo (sous ubuntu réalisable simplement à l'aide de recordmydesktop)
• perspectives pour poursuivre

Annexes

• Eventuellement le cahier des charges
• Manuel Utilisateur
• Description des procédures pour réaliser 
• l'installation,
• la configuration
• et l'utilisation de l'application 
• les aspects généraux de(s) l'interface(s) ou bien intégration des copies d'écran
• les différentes opérations disponibles dans l'application et comment les exécuter
• Description des problèmes courants
• Mini foire aux questions
• Paquetage des fichiers sources

Livrables
une archive contenant

• les sources du code src, 
• javadoc (documentez avec la syntaxe JAVADOC chaque classe, attribut, méthode ou exception. Générez la doc HTML et empaquetez le tout (doc + classes squelettes))
• doc/userGuide (binaire et source)
• doc/rapport (binaire et source)

tar zcf -`date +%Y%m%d`-`date +%H%M`.tgz projet/  

Alimenter son LinkedIn, Twitter, Dokuwiki... avec un flux RSS

Dernière mise à jour : vendredi 22 octobre 2010


En tant que chercheur il est important de communiquer sur ses activités aux différentes communautés auxquelles on appartient.

Le propre du Web 2.0 est de facilement diffuser du contenu et d'en construire de nouveaux à partir d'existants (ainsi que d'en modifier aisément leur forme). C'est le principe de base des réseaux sociaux. LinkedIn, Twitter et Dokuwiki font parties de ces vecteurs de communication du moment.

Néanmoins on ne peut passer son temps à alimenter ces vecteurs, a fortiori quand il s'agit de diffuser la même information sur chacun d'eux !

La solution que j'ai choisie pour communiquer et éviter de perdre du temps dans la recopie des informations que je souhaite communiquer est de tenir ce blog et d'offrir un accès à son contenu à l'aide d'une syndication RSS que j'inscris aux différents réseaux sociaux que j'utilise. 

Une seule entrée et autant de sorties que les applications le permettent. Une bonne application web 2.0 doit pouvoir se nourrir de flux RSS (éventuellement filtrés par le biais des tags) ainsi que pouvoir alimenter d'autres applications.

• Pour LinkedIn : au moins deux moyens
• soit avec l'application blog link
• soit  en créant un groupe, et par le menu "Manage News Feeds" ajouter le flux RSS que vous souhaitez "manger" 
• Pour twitter http://twitterfeed.com/
• Pour Dokuwiki, il suffit d'insérer le code suivant {{rss>http://enicolashernandez.blogspot.com/feeds/posts/default 8 author date 1h }}

Ici 6 raisons qui font de votre blog votre meilleur outil social  et là quelques passerelles entre d'autres outils sociaux

Gestion du temps - lois et degrés de priorité

D'après les commentaires et l'adaptation de Pierre STOUFF d'un document qu'il a reçu lors d'une formation sur la gestion du temps

LOIS
Loi de Carlson ou loi des séquences homogènes de travail

" Tout travail interrompu sera moins efficace et prendra plus de temps que s'il était effectué de manière continue"

Loi de Parkinson ou loi de la tendance à l'auto-inflation du temps dépensé

"Le temps investi dans un travail en fonction du temps disponible"

LOI D'ILLITCH ou loi de la contre-productivité du temps investi au-delà d'un certain seuil

"Au delà d'un certain seuil horaire, la productivité du temps investi décroit puis devient négative"

UNE ACTIVITE EST URGENTE SI

"Une activité est urgente si... sa non réalisation immédiate entraîne (avec une forte probabilité) des conséquences nuisibles, irréversibles, irrémédiables. L'urgence est souvent provoquée par l'extérieur."

UNE ACTIVITE EST IMPORTANTE SI

"Une activité est importante si... elle contribue à la réalisation des objectifs de la fonction"

ORGANISER C'EST

"Organiser, c'est remettre régulièrement en cause ce qui existe pour l'améliorer."

LES DEGRES DE PRIORITE

Se concentrer sur un nombre limité de priorités (3 à 5 dans la plupart des cas), privilégier l'importance (contributions, résultats) par rapport à ce qui est urgent (délai, échéance).

1. = IMPORTANT ET URGENT (doit être fait cette semaine)
2. = IMPORTANT (peut attendre à la semaine suivante)
3. = URGENT (à faire prochainement)

Créer un projet sous GoogleCode

Dernière mise à jour : 1 mars 2011

La page "A quick guide to getting started with project hosting on Google Code" explique comment contribuer à ou créer un projet sous GoogleCode (par exemple comment choisir la licence d'un nouveau projet).

En quelques cliques...

1. Créer un projet en cliquant sur Create Project et remplir le formulaire
   
• nom, résumé et description du projet, mais aussi des choix comme (ici avec des valeurs exemples que j'utilise en général) 
• Project name: si votre nom est composé alors séparer chaque mot par un tiret (e.g. votre-nom-de-projet)
• Version control system: Subversion
• Source code license: Apache License v2.0
2. Configurer le projet (à l'aide de l'onglet Administer de la barre de menu horizontale. Le fait de cliquer dessus fait apparaître un sous menu.)
   
1. Définir les membres en cliquant sur Project Members (les owners ont tous les droits, les committers peuvent travailler sur le projet mais ne peuvent pas le configurer.)
2. (Optionnel) Sous l'onglet Project Summary, spécifier la notification des modifications de la forge en déclarant le nom de votre liste de discussion ou google groupe (qui servira aussi d'alias dans nos échanges mails) dans la section Activity notifications de Administer puis Issue Tracking. (Pour créer un google groupe se rendre sur http://groups.google.fr/groups/create)
3. (Optionnel) Sous l'onglet Project Summary, spécifier le Web Property ID de Google Analytics afin de pouvoir obtenir des statistiques de visistes via Google Analytics (la note Learn more, rappelé plus bas, vous indique la démarche).
3. Services à disposition et menu de gestion du projet
• La barre d'onglets horizontale offre différents services : Project Home, Downloads, Wiki, Issues, Source, Administer
1. Downloads permet de uploader des fichiers avec le lien New download
   
2. Wiki permet de rédiger des pages avec le lien New page
3. Issues permet de signaler des observations sur le projet pour aider à son bon développement.  Elles émanent des utilisateurs comme des développeurs.
   
1. Cela se fait avec New issue et en spécifiant entre autres le Type de l'issue -Defect (défaut du logiciel), -Enhancement (amélioration demandée sur quelque chose qui existe), -Task (quelque chose de nouveau à développer)... et sa priorité
2. Par la suite, les développeurs consultent les issues et agissent en conséquence. Une issue peut recevoir plusieurs commentaires de différentes personnes. Suivant leurs traitements, les développeurs changeront leur Status (Accepté (le problème est confirmé), Fixed (defect réparée), Invalid (issue invalide), Done (task effectuée)...
4. Source indique les commandes à taper pour récupérer avec un client subversion (svn) depuis un poste linux les sources du projets afin de contribuer ou seulement de les consulter.
• si vous vous trouvez derrière un proxy, alors éditer le fichier ~/.subversion/servers et à la fin, décommenter les lignes suivantes en indiquant les bonnes valeurs
• # http-proxy-host = defaultproxy.whatever.com
  # http-proxy-port = 7000
4. Utiliser le dépot svn
• Votre dépot svn est accessible à une adresse similaire à celle-ci https://votre-nom-de-projet.googlecode.com/svn ; où par défaut 3 sous répertoires sont disponibles : trunk (version principale en cours de développement), tags (précédentes versions stables), branches (évolutions différentes du tronc ou corrections de bugs).
• L'onglet source vous indique comment récupérer le trunk...
• Pour commencer à travailler, faites un checkout pour commencer à travailler sur votre projet. Bien entendu la première version récupérée sera vide mais s'accompagne de fichiers qui permettront de synchroniser votre copie locale avec le référentiel subversion. 
5. Publier une Javadoc sous forge Google Code
6. Mesurer le nombre de visites sur votre projet hébergé sous Google Code grâce à Google Analytics
7. Ajouter un dépot (repository) Maven à votre forge Google Code grâce à Subversion

TODO Liens vers mon cours de svn, notamment pour faire des tags... Choisir sa licence...