\documentclass[a4paper]{book}

\usepackage[latin1]{inputenc} % entr\'ee 8 bits ISO-Latin1 (accents)
\usepackage{url}
\usepackage{a4}
\usepackage{ecltree}
\usepackage{epic}
\usepackage{eepic}
\usepackage[french]{babel}

\selectlanguage{french}

\usepackage{epsfig}

\usepackage{graphicx}

% \usepackage{url}
% \urlstyle{rm}

\usepackage{amsfonts}

\def\Z{{\mathbb Z}}


% Macro pour inclure du PDF

\newif\ifpdf
 \ifx\pdfoutput\undefined
     \pdffalse
 \else
     \pdfoutput=1
     \pdftrue
 \fi

\def\includefigtr#1#2#3{\begin{center}
  \ifpdf
   \includegraphics[#2]{#1.pdf}
  \else
   \includegraphics[#3]{#1.eps}
  \fi
\end{center}
}

\date{Ann\'ee 2014-2015}
\title{Projets de fin d'ann\'ee\\Sujets, Dates et Consignes}


\begin{document}

\maketitle \tableofcontents

% \noindent
% {Institut Galil\'ee \hfill ~ \\
% Ann\'ee 2006-2007 \hfill Licence 3 Informatique}

% \begin{center}
% {\Large\bf Projets de fin d'ann\'ee}
% \end{center}


\chapter{Consignes}

\section{Introduction}

Ce document regroupe l'ensemble des informations n\'ecessaires \`a la
r\'ealisation du projet de fin d'ann\'ee. Vous y trouverez les directives
g\'en\'erales,
% (section \ref{sec:inform-et-dero})
les sujets (section \ref{cha:liste-des-projets}) 
% (section \ref{cha:inform-compl}),
les dates de remises de documents
ainsi qu'en annexe, un guide et des consignes pour la r\'ealisation du
projet.

%(annexes \ref{cha:guide-de-realisation}, \ref{cha:conseils},
% \ref{cha:le-memoire-de}, \ref{cha:evaluation-du-projet}, et 
% \ref{cha:stand-de-progr}).
Formation des groupes: la plupart des projets sont pr\'evus pour \^etre r\'ealis\'es en trin\^ome. (Le nombre d'\'etudiants peut \^etre quatre, mais dans ce cas, il faut que les fonctionnalit\'es propos\'ees le justifient). De mani\`ere g\'en\'erale, la pr\'esence d'une interface graphique est recommand\'ee, mais pour les \'etudiants dispens\'es de stage (le module vaut alors 6 ECTS) une interface graphique est obligatoire. Pour les \'etudiants ayant suivis l'option Logiciel Libre, le projet est l'occasion cette ann\'ee de leur donner une note de mise en pratique des logiciels libres valant pour l'option. Il est donc conseill\'e \`a ces \'etudiants de se r\'eunir dans un m\^eme groupe. (Il leur sera demand\'e en particulier de choisir une licence, et de mettre en place un git ou un svn pour le projet).

\section{D\'eroulement des projets}
\label{sec:inform-et-dero}

%Les projets seront  r\'ealis\'es en trin\^ome. Mais si les 
%fonctionnalit\'es pr\'evues le justifient, on
%pourra accepter plus de 3 \'etudiants. 
%(Le nombre maximal d'\'etudiants par projet est indiqu\'e).

Vous devez normalement choisir un sujet parmi ceux pr\'esent\'es ici. Mais si vous souhaitez faire une autre
proposition, envoyez rapidement une page de description au format PDF 
 \`a Nicolas Rolin et Catherine Recanati qui valideront ou non votre
proposition.

Vous devez envoyer  \`a Nicolas Rolin (\url{nicolas.rolin@lipn.univ-paris13.fr}) et Catherine Recanati (\url{catherine.recanati@lipn.univ-paris13.fr}) trois sujets int\'eressant votre groupe
dans l'ordre de vos pr\'ef\'erences, ainsi que la liste des membres de votre groupe
et leurs adresses \'electroniques, et ceci \textbf{avant le 11 mars 2015, 17h}. 
Le sujet qui vous sera ensuite
attribu\'e vous sera indiqu\'e par courrier \'electronique, avant le
22 mars 2015. (NB~: Si vous ne fournissez pas une liste de trois sujets, il
  est possible que vous vous voyiez attribuer un tout autre sujet).
  
Le langage utilis\'e sera a priori le langage C ou Java. Des librairies graphiques (Gtk par
exemple) sont autoris\'ees pour l'interface graphique. En cas de doute sur le (ou les) langage(s) de dveloppement utilis\'e(s), envoyez un mail   \`a vos deux encadrants.

Le \textbf{13 avril 2015 \`a 0h au plus tard}, vous enverrez un document de 15 pages (maximum) \textbf{au format PDF
  uniquement}. Ce premier document suivra les indications fournies dans l'annexe A et inclura :

\begin{itemize}
\item une pr\'esentation g\'en\'erale et une analyse approfondie de votre projet (cf. \ref{sec:ana-approf})
\item une liste d\'etaill\'ee des fonctionnalit\'es de votre logiciel (cf. \ref{subsec:liste})
\item l'architecture logicielle (les diagrammes de classes 
\'eventuels si vous programmez dans un langage objet) et les interactions
  entre modules et librairies en vue de l'impl\'ementation sous forme d'un diagramme de d\'ependances entre les modules (les modules \'etant repr\'esent\'es par des bo\^ites et des fl\`eches mat\'erialisant les d\'ependances entre les bo\^ites). (cf.  \ref{subsec:archi})
% \item la description des formats d'entr\'ees/sorties s'il y a lieu
%\item les tests devant \^etre  r\'eali\'es pour v\'erifier, lors de la deuxi\`eme
%  phase du projet, le fonctionnement correct du logiciel d\'evelopp\'e.
\item une liste des t\^aches et un planning pr\'evisionnel (diagramme dans le temps)
\end{itemize}
\textbf{Notez bien qu'aucune programmation n'est demand\'ee \`a ce stade} (il ne s'agit que de 
sp\'ecifications) \textbf{et qu'il est tr\`es important que vous respectiez les d\'elais.}
~

Vous soignerez l'analyse du sujet et  la pr\'esentation du document. Un guide de r\'ealisation des projets et des indications sur les documents \`a rendre vous sont fournis en annexet \ref{cha:guide-de-realisation} et \ref{cha:le-memoire-de}. Soignez en particulier la premi\`ere page, et faites une table des mati\`eres pagin\'ee. La note finale tiendra compte de la qualit\'e de ce premier rapport et des corrections qui
 lui seront apport\'ees ult\'erieurement.

Le 10 mai 2015 au plus tard, vous aurez des retours sur votre document
par courrier \'electronique. Les groupes en difficult\'e seront convoqu\'es pour une s\'eance
de discussion informelle autour du rapport dans la semaine du 11 mai. Vous serez pr\'evenu de ce rendez-vous par courrier  \'electronique.
~

La soutenance finale du projet est pr\'evue la  \textbf{semaine du 1er juin} (vous serez inform\'e par affichage et par mail).   \textbf{La semaine qui pr\'ec\'ede (semaine du 25 mai)}, vous devrez envoyer par mail  \`a Nicolas Rolin et Catherine Recanati~:

\begin{itemize}
\item un rapport d'au plus 25 pages (format PDF  uniquement)
d\'ecrivant l'ensemble de votre projet (vous pourrez partir
du rapport d'analyse du projet envoy\'e initialement)
  \item un manuel utilisateur (comportant aussi un manuel d'installation) au format PDF 
  \'egalement

\item une archive \texttt{ZIP} ou tar.gz contenant le code comment\'e de vos programmes dans leur \'etat  actuel (tout autre format sera refus\'e - except\'e une archive jar pour le code java) 


\end{itemize}
~
NB: Le code pourra \^etre modifi\'e jusqu'au jour de la pr\'esentation et de
la d\'emonstration mais \`a vos risques et p\'erils (conservez une
version qui fonctionne).
~
La note finale du projet tiendra compte du rendu de ce rapport (qualit\'e des
documents, qualit\'e des
commentaires du code, pr\'ecision du manuel utilisateur et du manuel d'installation).

~

Vous effectuerez pour la soutenance elle-m\^eme une pr\'esentation collective (bas\'ee sur un fichier  PowerPoint, OpenOffice ou pdf) et vous ferez une d\'emonstration de votre logiciel en salle machine. 
~

Le fichier de la
pr\'esentation (format .pdf, .ppt ou .pptx uniquement) sera
envoy\'e \textbf{deux jours avant la soutenance orale} pour que nous puissions l'installer par avance sur un m\^eme ordinateur. Par ailleurs, vous devez pr\'eparer soigneusement 
le sc\'enario de votre d\'emonstration et r\'ep\'eter dans l'environnement pr\'evu pour cette d\'emo. M\^eme si votre logiciel ne fonctionne pas 
enti\`erement, vous pouvez montrer le fonctionnement correct de certaines fonctions
ou modules dans une d\'emonstration. La note finale tiendra compte de la qualit\'e de la pr\'esentation, de celle de
la d\'emonstration, ainsi que du rendu logiciel.

~

\textbf{Aide technique}~: Vous pouvez naturellement 
 envoyer des messages \'electroniques pour avoir des
\'eclaircissements sur votre sujet ou une aide sur un probl\`eme  technique
(ne restez pas trois semaines sur un bug sans r\'eagir ! Mais
ne venez pas non plus pour un probl\'eme  de compilation d\^u \`a une simple
erreur de syntaxe). Pensez \`a d'abord envoyer un mail pour fixer un rendez-vous,
et \`a amener
votre code sous format \'electronique (de pr\'ef\'erence sur cl\'e USB, sinon
disponible sur le r\'eseau).

\newpage


\chapter{Liste des projets}
\label{cha:liste-des-projets}

\section{Gestion de r\'eferences bibliographiques en bibtex et HTML}

%%\paragraph{Nombre d'\'etudiants maximum~: 4.} 
Le projet consiste \`a \'ecrire un logiciel permettant de g\'erer des r\'ef\'erences bibliographiques contenues dans un fichier au format bibtex. 
Le logiciel offrira les fonctionnalit\'es suivantes~:

\begin{itemize}
\item chargement d'un fichier bibtex

\item ajout de r\'ef\'erences

\item modification de r\'ef\'erences

\item suppression de r\'ef\'erences. 

\item sauvegarde des modifications

\item Extraction/recherche des r\'ef\'erences \`a partir de noms d'auteurs,
  de mots du titre, de noms de r\'ef\'erences

\item g\'en\'eration d'un fichier HTML valide permettant d'afficher la
  liste des r\'ef\'erences dans le format standard~:

\begin{center}
 author, title, publisher, series, booktitle, volume(number),
pages, adress, year, note, annote.
\end{center}


\item interrogation \`a distance, gr\^ace \`a une architecture
  client/serveur. (Obligatoire si plus de deux \'etudiants).

\end{itemize}

Une base de donn\'ees de r\'ef\'erences bibliographiques contient des
r\'ef\'erences qui peuvent r\'ef\'erencer des livres, des articles de revues ou des
articles de conf\'erences. A chacun de ces types de r\'ef\'erence
correspondent plusieurs champs dans le format bibtex. Ces diff\'erents champs sont donn\'es
dans les exemples ci-dessous~:

\begin{itemize}
\item Exemple de r\'ef\'erence au format bibtex, pour un livre~:
\begin{verbatim}
@Book{Mallatbook,
  author = 	 {S. Mallat},
  title = 	 {A Wavelet Tour of Signal Processing},
  publisher = 	 {Academic Press},
  year = 	 {1998},
  OPTeditor = 	 {},
  OPTvolume = 	 {},
  OPTnumber = 	 {},
  OPTseries = 	 {},
  address = 	 {Boston},
  OPTedition = 	 {},
  OPTnote = 	 {},
  OPTannote = 	 {}
}
\end{verbatim}
\item Exemple de r\'ef\'erence au format bibtex, pour un article de revue~:
\begin{verbatim}
@Article{Temlyakov,
  author = 	 {V. Temliakov},
  title = 	 {Nonlinear methods of approximation},
  journal = 	 {FOCM},
  year = 	 {2008},
  OPTkey = 	 {},
  volume = 	 {3},
  number = 	 {1},
  pages = 	 {33-107},
  month = 	 {Feb.},
  OPTnote = 	 {},
  OPTannote = 	 {}
}
\end{verbatim}
\item Exemple de r\'ef\'erence au format bibtex, pour un article de conf\'erence~:
\begin{verbatim}
@InProceedings{pati93OMP,
  author = 	 {Y. Pati and R. Rezaiifar and P. Krishnaprasad},
  title = 	 {Orthogonal Matching Pursuit: Recursive Function 
                  Approximation with Applications to Wavelet Decomposition},
  booktitle = {27 th Annual Asilomar Conference on Signals, Systems,
    and Computers},
  pages = 	 {40-44},
  year = 	 {93},
  OPTeditor = 	 {},
  volume = 	 {1},
  OPTnumber = 	 {},
  OPTseries = 	 {},
  OPTaddress = 	 {},
  publisher = {IEEE},
  OPTnote = 	 {},
  OPTannote = 	 {}
}
\end{verbatim}
\end{itemize}

Dans les r\'ef\'erences ci-dessus, les champs commen\c{c}ant par OPT, sont
optionnels et ne sont pas renseign\'es. Les r\'ef\'erences portent ici les noms
"Mallatbook", "Temlyakov" et "pati93OMP".

NB~:
\begin{itemize}
\item Vous pourrez utiliser les outils Flex et Bison pour analyser un fichier
Bibtex. 
\item Un fichier  charg\'e pourra contenir des r\'ef\'erences incompl\`etes
\end{itemize} 

\section{Gestion de cave \`a vin}

%%\paragraph{Nombre d'\'etudiants maximum~: 4.}
Il s'agit d'\'ecrire un logiciel permettant de g\'erer le stock d'une cave \`a vin. On peut imaginer que
cette cave appartienne \`a un particulier ou \`a un marchand de vin.
On caract\'erisera un vin par sa r\'egion, son domaine, son
ch\^ateau, sa couleur, son ann\'ee, son c\'epage. Une bouteille de vin
sera caract\'eris\'ee par le vin qu'elle contient et la taille de la
bouteille. La cave contient des vins. On voudra donner pour un vin, le nombre de
bouteilles, une ann\'ee de maturit\'e, une localisation (dans la cave),
des commentaires (d'au plus $1000$ caract\`eres).

Le logiciel offrira les
fonctionnalit\'es suivantes~:

\begin{itemize}
\item Chargement d'un
fichier d\'ecrivant une cave
\item modification des vins
\item ajout de vins
\item suppression de vins
\item sauvegarde d'une cave

\item Recherche et affichage des vins par nom, par ann\'ee de maturit\'e, par couleur, par
  c\'epage, r\'egion, etc. Plusieurs crit\`eres pourront \^etre combin\'es.

\item interrogation
  \`a distance, gr\^ace \`a une architecture client/serveur si le cas envisag\'e est celui d'un magasin
\end{itemize}


NB~:
\begin{itemize}
\item Le nombre de vins ne sera pas limit\'e (vous utiliserez une
structure de donn\'ees dont la taille n'est pas fix\'ee \`a l'avance).

\item Vous pourrez utiliser les outils Flex et Bison pour analyser les
  fichiers stockant les informations relatives \`a/aux cave(s) \`a vins.

\end{itemize}


\section{Jeu d'\'echecs en r\'eseau}


%%\paragraph{Nombre d'\'etudiants maximum~: 4.}
Ce projet devra permettre \`a un joueur de jouer une ou
plusieurs parties \`a  travers le r\'eseau avec d'autres
partenaires. 
%
Un serveur g\'erera les plateaux correspondant aux  diff\'erentes parties.
Les clients se connecteront au serveur soit pour jouer, soit pour assister,
comme spectateur, au d\'eroulement d'une ou plusieurs parties.


% Catherine: je pense qu'il faut supprimer ce sujet 

%\section{Un d\'emon terminal de connexion espion}

%%\paragraph{Nombre d'\'etudiants maximum~: 3.}


%On souhaite avoir un d\'emon effectuant les t\^aches suivantes : 
%\begin{itemize}
%\footnotetext[2]{On informera l'administrateur}
%\item[$\bullet$] V\'erification que toute personne connect\'ee sur une machine soit
%r\'ef\'erenc\'ee.\footnotemark[2]
%\item[$\bullet$] Si un utilisateur n'est pas r\'ef\'erenc\'e r\'ecup\'erer toutes les commandes effectu\'ees
%par le dit individu.\footnotemark[2] 
%\item[$\bullet$] V\'erification d'utilisation de commandes illicites.\footnotemark[2]
%\item[$\bullet$] Ex\'ecution de commandes envoy\'ees par l'administrateur.\\
%Exemple: destruction de tous les textedits d'un utilisateur $\lambda$.
%\end{itemize}


%\section{Un serveur de calculs}

%%\paragraph{Nombre d'\'etudiants maximum~: 2.}

%Il s'agirait d'un serveur permettant \`a  ses clients d'ex\'ecuter \`a  l'aide d'un
%m\'eta-langage des op\'erations de calcul d'expression en parall\`ele sur des machines peu charg\'ees.\\
% Exemple: le client envoie la suite d'instructions :

%\begin{center} 
%\begin{tabular}{ll}
%{[}1] & res1=3*x+7*y\\
%{[}2] & res2=6*x+9*y\\
%{[}3] \& [1]& res3=exp(res1)\\
%{[}4] \& [2]& res4=exp(res2)\\
%{[}5] \& [1] \& [4]& res5=res4*res1\\
%\end{tabular}
%\end{center}

%Le serveur effectue les calculs suivants (voir Fig.~\ref{fig-1})~:\\

%\begin{figure}[h!]
%\begin{center}

%\includefigtr{AgencTache}{scale=.5}{scale=.5}

% \setlength{\unitlength}{0.00083333in}
% %
% \begingroup\makeatletter\ifx\SetFigFont\undefined
% % extract first six characters in \fmtname
% \def\x#1#2#3#4#5#6#7\relax{\def\x{#1#2#3#4#5#6}}%
% \expandafter\x\fmtname xxxxxx\relax \def\y{splain}%
% \ifx\x\y   % LaTeX or SliTeX?
% \gdef\SetFigFont#1#2#3{%
%   \ifnum #1<17\tiny\else \ifnum #1<20\small\else
%   \ifnum #1<24\normalsize\else \ifnum #1<29\large\else
%   \ifnum #1<34\Large\else \ifnum #1<41\LARGE\else
%      \huge\fi\fi\fi\fi\fi\fi
%   \csname #3\endcsname}%
% \else
% \gdef\SetFigFont#1#2#3{\begingroup
%   \count@#1\relax \ifnum 25<\count@\count@25\fi
%   \def\x{\endgroup\@setsize\SetFigFont{#2pt}}%
%   \expandafter\x
%     \csname \romannumeral\the\count@ pt\expandafter\endcsname
%     \csname @\romannumeral\the\count@ pt\endcsname
%   \csname #3\endcsname}%
% \fi
% \fi\endgroup
 %\begin{picture}(1665,2364)(0,-10)
 %\thicklines
% \path(969,2337)(1243,2063)
%\path(1380,1927)(1653,1653)
 %\path(1653,1653)(1380,1380)
% \path(1243,1243)(969,969)
%\path(969,2337)(969,1653)
% \path(969,1516)(969,969)
% \path(969,969)(969,559)
%\path(969,422)(969,12)
%\path(969,969)(696,696)
%\path(559,559)(12,12)
%\put(593,593){\makebox(0,0)[lb]{\smash{{{\SetFigFont{5}{6.0}{rm}[3]}}}}}
% \put(935,1551){\makebox(0,0)[lb]{\smash{{{\SetFigFont{5}{6.0}{rm}[1]}}}}}
%\put(935,456){\makebox(0,0)[lb]{\smash{{{\SetFigFont{5}{6.0}{rm}[5]}}}}}
%\put(1277,1277){\makebox(0,0)[lb]{\smash{{{\SetFigFont{5}{6.0}{rm}[4]}}}}}
 %\put(1277,1961){\makebox(0,0)[lb]{\smash{{{\SetFigFont{5}{6.0}{rm}[2]}}}}}
% \end{picture}
%\end{center}
%\caption{Agencement des t\^aches.\label{fig-1}}
%\end{figure} 

%\begin{center}
%\begin{tabular}{ll}
%{[}1], {[}3] et {[}5] & sur une machine A\\
%{[}2] et {[}4] & sur une machine B\\
%\end{tabular}
%\end{center}

%Le logiciel devra d\'efinir un mini-langage d\'efinissant de telles suites d'instructions, et les clients enverront au serveur de telles suites \`a ex\'ecuter sous forme de texte dans ce mini-langage. Le serveur d\'eterminera alors comment il peut fractionner (et ordonner) les calculs sur diff\'erentes machines, il enverra des demandes de calculs \`a des programmes simples (tournant sur une autre machine). Ces programmes  lui renverront leurs r\'esultats, puis il calculera le r\'esultat final (et le renverra au client initial) une fois les r\'esultats partiels r\'ecup\'er\'es.

%Pour simplifier le sujet, on \'ecrira donc le programme serveur de calcul, un programme client pouvant se connecter au serveur et permettre \a l'utilisateur de formuler une demande de calcul, et on fera tourner sur une autre machine un (ou plusieurs) programme(s) capable de r\'ealiser un calcul simple et d'en retourner le r\'esultat au serveur, sans se pr\'eoccuper ici de la r\'eelle charge des machines.

% \section{Filemanager}

% %\paragraph{Nombre d'\'etudiants (maximum)~: 2}

% Le but de ce projet est de r\'ealiser la g\'en\'eralisation r\'eseau du
% filemanager dans le sens o\'e l'on peut acc\'eder (copier, transf\'erer
% \'editer etc...) \`a  des donn\'ees pr\'esentes sur des machines distantes.


\section{Allocation contigu\"e en m\'emoire centrale}

%%\paragraph{Nombre d'\'etudiants maximum~: 3.}

Il s'agit de simuler l'arriv\'ee de processus ( "threads")
venant demander un espace m\'emoire au syst\`eme pour s'ex\'ecuter, et d' implanter des algorithmes classiques d'allocation m\'emoire 
 \`a  savoir "best fit",
"first fit", et "worst fit ", en vue de permettre
une comparaison
de leurs performances. Le logiciel permettra de param\'etrer la simulation, de la lancer, et de comparer les r\'esultats obtenus par les diff\'erents algorithmes.


\section{Ordonnancement de processus}

%\paragraph{Nombre d'\'etudiants maximum~: 3.}

On suppose que des processus (sous forme de "threads ") arrivent dans
le syst\`eme au hasard. On fera pour cela une simulation temporelle d'arriv\'ee de processus demandant un temps de calcul au processeur. Implanter les diff\'erents algorithmes d'ordonnancement de ces processus vus en cours. Le logiciel permettra de
lancer ces diff\'erents algorithmes et de comparer leur efficacit\'e.

% \section {Anneau de processeurs}

% %\paragraph{Nombre d'\'etudiants (maximum)~: 2}

% On cherche \`a  cr\'eer un ensemble de n processeurs (simul\'es par n
% "threads") dispos\'es en anneau et se communiquant entre eux \`a  travers
% des tubes. Le processeur i ne peut communiquer qu' avec les
% processeurs voisins  i-1 et i+1.

% Pour cela, on r\'ealise la commande :

% \begin{center}
% Anneau nombre r\'ef\'erence
% \end{center}

% qui doit cr\'eer un anneau de nombre processus ex\'ecutant tous le
% programme de r\'ef\'erence donn\'ee. On se propose d' appliquer ce mod\'ele \'e
% l'\'election d'un serveur (algorithme de Chang et Roberts). Pour ce
% probl\`eme , des informations suppl\'ementaires seront fournies \`a  ceux qui
% sont int\'eress\'es. Une analyse algorithmique et une \'evaluation de
% l'anneau sont n\'ecessaire.


% \section{Proxy Web}

% %\paragraph{Nombre d'\'etudiants (maximum)~: 3}

% Le but de ce projet et la r\'ealisation d'un proxy WEB. Un proxy WEB
% n'est en fait qu'un cache dont le but est d'acc\'el\'erer les acc\'es aux
% requ\'etes WEB. Les pages d\'ej\'e visit\'ees sont stock\'ees sur un serveur.
% Chaque client WEB (mozilla, galeon, ....) ne contacte pas le site
% h\'ebergeant la page demand\'ee, mais fait appel au proxy WEB. Le proxy va
% dans un premier v\'erifier dans son cache si la page n'est pas d\'ej\'e
% pr\'esente. Si elle l'est, la page est envoy\'e au client. Si elle ne
% l'est pas, le proxy va la chercher sur le WEB et la met dans son
% cache. Un processus s'occupe de nettoyer r\'eguli\'erement le cache en
% supprimant les pages trop anciennement t\'el\'echarg\'ees depuis le WEB.
% Pour ce sujet, on vous demande :

% \begin{itemize}
% \item de cr\'eer un tel proxy
  
% \item de limiter l'espace utilis\'e par le proxy
 
% \item d'avoir 2 niveaux de cache (m\'emoire centrale pour les
%   pages acc\'ed\'ees tr\`es fr\'equement et disque pour les autres)
 
% \item g\'erer l'authentification aupr\'es de ce proxy
 
% \item de g\'erer des filtres au niveau du proxy.

% \end{itemize}

\section{SGBD r\'eparti}

%\paragraph{Nombre d'\'etudiants maximum~: 4.}

Dans ce projet, on souhaite g\'erer un SGBD r\'eparti simplifi\'e. Dans un
SGBD r\'eparti, les donn\'ees ne sont pas stock\'ees sur un seul serveur
mais sur un ensemble de serveurs (on suppose qu'un enregistrement est
stock\'e compl\`etement sur un serveur). Lorsqu'un client fait une requ\^ete
sur ce SGBD, on doit interroger l'ensemble des serveurs constituant le
SGBD pour obtenir le r\'esultat (on suppose des requ\^etes simples : SELECT
FROM WHERE sans jointure). De m\^eme, lorqu'il fait une insertion ou une
mise \`a  jour, il faut d\'eterminer sur quel serveur doit se faire
l'op\'eration. Pour r\'esoudre ce probl\`eme,  deux solutions architecturales sont
envisageables :

\begin{enumerate}
\item un serveur central qui a  la connaissance de tous les serveurs
  constituant la base

\item  une architecture de type P2P.

\end{enumerate}

Vous mettrez en place un m\'ecanisme pour le stockage des enregistements
sur les serveurs, et un m\'ecanisme de cache en m\'emoire pour les
enregistements les plus souvent acc\'ed\'es. Vous d\'efinirez un mini
langage de requ\^etes pour ce SGBD.

\section{Gestion d'arbres g\'en\'ealogiques}
\label{arbregene}

%\paragraph{Nombre d'\'etudiants maximum~: 4.}

L'arbre g\'en\'ealogique d'une personne contient tous ses ascendants
(parents, grands-parents, arri\`ere-grands-parents, etc.) connus. 

Le programme doit permettre \`a  l'utilisateur d'entrer une personne et son arbre g\'en\'ealogique.
Pour chaque personne, on peut donner son nom, son pr\'enom, sa date et son
lieu de naissance, et \'eventuellement sa date et son lieu de d\'ec\`es.
Le programme doit permettre
de saisir l'arbre
g\'en\'ea\-logique d'une personne, puis de l'afficher et de le modifier. L'utilisateur devra aussi avoir la possibilit\'e de sauvegarder un arbre g\'en\'ea\-logique
dans un fichier et, bien s\^ur, de pouvoir afficher, modifier, ou
compl\'eter un arbre ainsi sauvegard\'e.

Le couple des parents d'une personne peut avoir d'autres enfants.
On souhaite \'egalement pouvoir stocker les autres enfants d'un couple,
ce qui am\`ene les notions de fr\`ere et s\oe ur. 

Le logiciel pourra avoir la notion de fr\`ere et s\oe ur, ainsi que d'autres notions de
parent\'e et 
permettre de rechercher dans la base un fr\`ere, une s\oe ur, un
cousin, ou tout autre relation de parent\'e comprise par le logiciel.

Vous devrez \'egalement  permettre d'effectuer des recherches par nom, pr\'enom,  date ou
  lieu de naissance, date ou lieu de d\'ec\`es, etc. sur des personnes connues de la base.

Vous pourrez utiliser les outils Flex et Bison pour analyser les fichiers
stockant les informations relatives \`a  un arbre g\'en\'ealogique.

\section{Gestion d'une biblioth\`eque}
%\label{sec:biblio}
%\paragraph{Nombre d'\'etudiants maximum~: 3.}

%--------------------------------------------------------------

Dans ce projet, vous d\'evelopperez un logiciel de gestion de
biblioth\`eque. Il devra offrir les fonctionnalit\'es suivantes~:

\begin{itemize}
\item  stocker des r\'ef\'erences de livres (auteur, titre, ...)

\item ajout, suppression et modification de livres


\item Recherche d'un ouvrage selon un ou plusieurs crit\`eres

\item Gestion des pr\^ets

\end{itemize}

Deux interfaces de visualisation et de manipulation sont demand\'ees~:
d'une part, une interface en ligne de commande, d'autre part une
interface graphique.


Vous pourrez utiliser les outils Flex et Bison pour analyser les fichiers
stockant les informations relatives \`a  une biblioth\`eque.

Des informations compl\'ementaires d\'etaillant le sujet sont fournies \`a 
la section \ref{sec:biblio}.


\section{Matrices creuses}
%\label{sec:creuses}

\paragraph{Nombre d'\'etudiants maximum~: 2.}

Dans beaucoup de domaines on utilise des matrices de grande taille
mais dont beaucoup de coefficients sont nuls.  Ces matrices sont
appel\'ees {\it creuses}. On peut repr\'esenter ces matrices en ne
stockant que la liste de leurs coefficients non nuls.  \'Ecrire un
programme manipulant des matrices creuses.
%
Ce logiciel doit permettre de saisir, de sauvegarder, de charger des
matrices et d'effectuer des op\'erations courantes sur les matrices.

Des informations compl\'ementaires d\'etaillant le sujet sont fournies
\`a la section \ref{sec:creuses}.


\section{Calcul formel}
\label{sec:expsymb}

Une expression symbolique du type $x+5$ peut \^etre repr\'esent\'ee par un arbre

\begin{tabular}{ccccc}
        &&+&&\\
        &$\swarrow$&&$\searrow$&  \\
        $x$&&&&$5$\\
\end{tabular}


Le logiciel permettra de saisir une expression (par exemple
$x^2+3x+8$), de l'\'evaluer pour une valeur de x et de la d\'eriver.  On
d\'esire aussi sauvegarder et r\'ecup\'erer des expressions. Les expressions seront
repr\'esent\'ees dans le programme sous forme d'arbres.

Des informations compl\'ementaires d\'etaillant le sujet sont fournies \`a
la section \ref{expsymb}.

\section{Polyn\^omes}
\label{poly}

%\paragraph{Nombre d'\'etudiants maximum~: 3.}
%--------------------------------------------------------------
Un polyn\^ome \`a  coefficients r\'eels est repr\'esent\'e par la liste de ses
mon\^omes (sans limitation de degr\'e). Le logiciel devra permettre de faire toutes les
op\'erations usuelles sur les polyn\^omes (addition, soustraction,
multiplication, division euclidienne, PGCD, PPCM, d\'erivation) et aussi permettre de
sauvegarder et restaurer des polyn\^omes pr\'ec\'edemment d\'efinis.

Vous \'etudierez une variante o\`u les coefficients sont dans $\Z/p\Z$
avec $p$ premier. Vous pourrez \'egalement \'etendre les calculs aux polyn\^omes de 2
variables quand cela a un sens.

Le logiciel devrait permettre d'entrer un polyn\^ome de diff\'erentes mani\`eres (en entrant par exemple les coefficients de chaque mon\^ome  \`a l'aide d'une interface graphique), mais on veillera  \`a avoir aussi une proc\'edure d'entr\'ee qui consiste  \`a lire une cha\^ine 
de caract\`eres repr\'esentant le polyn\^ome. Pour cela on d\'efinira la syntaxe d'\'ecriture d'un polyn\^ome, et si la syntaxe de la cha\^ine entr\'ee est incorrecte, on affichera un message d'erreur. Une possibilit\'e de syntaxe est de repr\'esenter les exposants avec le caract\`ere circonflexe. Ainsi le polyn\^ome 
$3x^5 + 4x^2 + 7x -1$ pourrait \^etre entr\'e  \`a l'aide de la cha\^ine de caract\`eres 3x\textasciicircum5 + 4x\textasciicircum2 + 7x -1. Avec ce type de syntaxe, l'ordre d'entr\'ee des mon\^omes serait quelconque.

On devra aussi pouvoir donner un nom \`a un polyn\^ome et le sauvegarder avec son nom dans un fichier. On pourra aussi charger un fichier contenant un polyn\^ome. Il pourrait aussi \^etre int\'eressant de pouvoir charger ou sauvegarder des fichiers contenant plusieurs polyn\^omes.




\section{Simulation de circuits \'electroniques}
%\label{sec:circuit}

%\paragraph{Nombre d'\'etudiants maximum~: 4.}

Les circuits \'electroniques sont constitu\'es de composants
reli\'es entre eux par des entr\'ees et des sorties. La simulation
consiste \`a  envoyer un signal \`a  l'entr\'ee du circuit (des $0$ ou des
$1$) et \`a  observer ce qui se passe \`a  la sortie (encore des $0$ ou des
$1$). Le logiciel devra permettre de cr\'eer, de sauvegarder et de
charger des circuits \'electroniques.


Des informations compl\'ementaires d\'etaillant le sujet sont fournies \`a
la section \ref{sec:circuit}.

\section{Assembleur MAMIAS}
%\label{sec:MAMIAS}

%\paragraph{Nombre d'\'etudiants maximum~: 4.}


MAMIAS est un  langage assembleur  \'el\'ementaire (pour une machine virtuelle) utilis\'e pour
l'enseignement en premier cycle. Le logiciel lira un fichier source
contenant un programme \'ecrit en langage MAMIAS et g\'en\'erera un fichier binaire contenant le
code machine de ce programme. On pourra alors ex\'ecuter le programme pas \`a pas.

Les informations  d\'etaillant le sujet sont fournies
dans la section  \ref{sec:MAMIAS}.

\section{Le jeu de la vie}
%\label{sec:jeuvie}

%\paragraph{Nombre d'\'etudiants maximum~: 3.}

Le jeu de la vie (cr\'e\'e par le math\'ematicen John Horton Conway) est bas\'e
sur l'\'evolution de populations cellulaires. La naissance et la mort d'une cellule y
sont conditionn\'ees par la pr\'esence suffisante ou excessive de cellules
 vivantes dans le voisinage de cette cellule. On consid\'ere g\'en\'eralement un
espace plat, constitu\'e d'une grille, dans laquelle chaque case a 8
voisins. Une case ne peut contenir qu'une seule cellule et les r\'egles
sont les suivantes~: i) si le voisinage d'une case vide contient trois
cellules, alors une cellule nait~; ii) si une cellule est entour\'ee de
plus de 4 cellules, elle meurt \'etouff\'ee~; iii) si une cellule est
entour\'ee d'une cellule ou moins, elle meurt d'isolement. 

On voudrait
pouvoir simuler l'\'evolution d'une population de cellules plac\'ees sur une grille, avec des
facilit\'es de chargement et sauvegarde d'\'etats. Ainsi, on devra pouvoir entrer une grille facilement pour tester le logiciel, l'id\'eal \'etant de pouvoir le faire interativement sur une grille avec la souris. (Mais on pourra aussi choisir de le faire par l'interm\'ediaire de fichiers textes \'editables si l'on ne fournit pas d'interface graphique).

Le logiciel doit permettre de simuler l'\'evolution d'une population de cellules initialement plac\'ees sur une grille. Cette simulation devrait pouvoir \^etre r\'ealis\'ee en diff\'erent mode: un mode pas \`a pas encha\^inant les \'evolutions successives, ou un mode rapide. On doit \'egalement pouvoir \`a  tout moment sauvegarder une grille ou en charger une nouvelle. On pr\'eparera pour la d\'emonstration des exemples int\'eressants, pr\'ealablement sauvegard\'es dans des fichiers.

Des informations compl\'ementaires sur le sujet sont fournies
dans la section  \ref{sec:jeuvie}.


\section{Moteur d'indexation}

%\paragraph{Nombre d'\'etudiants maximum~: 3.}


Un moteur de recherche est compos\'e de trois grandes parties~:
l'exploration (r\'ealis\'ee par le moissonneur ou le \textit{crawler}),
l'indexation, et la recherche.

On s'int\'eressera ici \`a  la partie indexation. L'objectif est de
construire un index d'une collection de documents. L'index construit
est similaire \`a  l'index d'un livre. Il contient notamment les termes
(mots et groupes de mots) pr\'esents dans les documents et en indique la liste. Il doit \^etre
organis\'e de mani\`ere \`a  faciliter la recherche, c'est-\`a-dire la
r\'ecup\'eration des documents pertinents pour un terme donn\'e.

Le projet consiste \`a  d\'evelopper un moteur d'indexation suffisamment
g\'en\'erique pour indexer des documents en fonction de  termes, mais aussi en
fonction de diff\'erents types de m\'eta-donn\'ees qui
pourraient \^etre associ\'ees aux documents. Il pourra g\'erer ainsi
plusieurs index. On fournira \'egalement une interface minimale
offrant la possibilit\'e de soumettre des requ\^etes au format CQL (Common
Query Language, protocole Z3940).


Documentation compl\'ementaire~: 

\begin{itemize}
\item \url{http://fr.wikipedia.org/wiki/Moteur_de_recherche}

\item
  \url{http://fr.wikipedia.org/wiki/Optimisation_pour_les_moteurs_de_recherche}

\item \url{http://fr.wikipedia.org/wiki/Indexation}

\item \url{http://zing.z3950.org/cql/}


\item \url{http://www.ifla.org/IV/ifla72/papers/102-McCallum_trans-fr.pdf}
\end{itemize}

 \section{Master Mind}
%\label{sec:mastermind}
%\paragraph{Nombre d'\'etudiants maximum~: 3.}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Le but du jeu est de d\'ecouvrir une combinaison de pions de couleurs diff\'erentes (le nombre de pions et de couleurs peut varier en fonction du niveau). Le joueur
qui cherche propose une combinaison de pions de couleur. Le programme lui indique alors combien de pions sont bien plac\'es (bonne couleur \`a  la bonne place) et combien
sont mal plac\'es (bonne couleur, mais pas \`a  la bonne place). Pour un exemple de jeu, on pourra consulter le site  \url{http://www.litterales.com/jeux}

Ce jeu de Master Mind pourra se jouer \`a  un ou deux joueurs. Dans la version mono-joueur, le choix de la
combinaison  \`a d\'ecouvrir sera fait par le programme. Le but est alors de trouver 10 combinaisons en un minimum de propositions. Dans la version \`a  deux joueurs, c'est l'adversaire
qui propose une combinaison. A chaque tour, on \'echange les r\^oles et on additionne le nombre de coups qu'a utilis\'es le joueur pour trouver la bonne combinaison. Le perdant est le
premier qui atteint $100$. Une partie pourra \^etre  sauvegard\'ee en cours de route et recharg\'ee pour \^etre poursuivie plus tard.

\section{Th\'ematiseur G\'en\'eral}
%\label{sec:thematiseur}
%\paragraph{Nombre d'\'etudiants maximum~: 3.}
Un th\'ematiseur g\'en\'eral est un logiciel prenant en entr\'ee un document et retournant une liste de mots-cl\'es (les th\`emes) correspondant au contenu du document (par exemple : science, tourisme, humour, horoscope, etc.). 
Un document est un fichier texte, ici sans ponctuation : on consid\`erera qu'il s'agit d'une suite de mots (cha\ine de caract\`eres sans espace) s\'epar\'es par des espaces. 
Un th\'ematiseur g\'en\'eral fait appel \`a des th\'ematiseurs sp\'ecialis\'es (un par th\`eme). Un th\'ematiseur sp\'ecialis\'e est initialis\'e pour un th\`eme (ou mot-cl\'e) particulier. Il a comme ressource une liste de mots correspondant au th\`eme (par exemple pour le th\`eme 'science' les mots 'informatique', 'physique', 'chimie', etc.). Sa fonction principale, \'etant donn\'e un document, est de retourner le pourcentage de mots du document faisant partie de sa liste de mots th\'ematique. 

Des informations compl\'ementaires sont fournies
\`a la section \ref{sec:thematiseur}.

\section{Serveur de petites annonces}
%\paragraph{Nombre d'\'etudiants maximum~: 2.}

Le projet consiste \`a \'ecrire un gestionnaire de petites annonces sous la forme d'une architecture client/serveur. Le programme serveur stockera un ensemble d'annonces et permettra aux clients de consulter les annonces, d'en cr\'eer de nouvelles, ou d'en supprimer. Une annonce sera constitu\'ee d'un titre et d'un texte (les deux sous forme de cha\^ine de caract\`eres) et d'un auteur (l'utilisateur ayant cr\'e\'e  l'annonce). Le serveur permettra la connexion de programmes clients et ceux-ci pourront consulter la liste des titres des annonces, \'editer le texte d'une annonce particuli\`ere, cr\'eer une nouvelle annonce, ou encore supprimer une annonce (mais on ne pourra supprimer une annonce que si on en est l'auteur). Le programme client aura une interface graphique agr\'eable affichant en permanence la liste des titres des annonces et leur nombre. Des boutons permettront l'ajout, la suppression et l'\'edition d'une annonce s\'electionn\'ee par son titre. Un bouton de mise-\`a-jour permettra de recharger la liste des annonces disponibles au niveau du serveur.

\chapter{Informations compl\'ementaires}
\label{cha:inform-compl}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Gestion d'une biblioth\`eque}
 \label{sec:biblio}

Le logiciel est destin\'e \`a  la biblioth\`eque d'un petit coll\`ege de $12$
classes contenant environ un millier de livres.\\

Il faudra g\'erer trois fichiers~:
\begin{itemize}
\item le fichier des emprunteurs~:
  \subitem r\'ef\'erence (n\'e d'identifiant unique)
  \subitem nom
  \subitem pr\'enom
  \subitem classe
\item le fichier des ouvrages
  \subitem r\'ef\'erence (n\'e d'identifiant unique)
  \subitem nom auteur
  \subitem pr\'enom auteur
  \subitem titre
  \subitem \'etat : emprunt\'e, rendu, en rayon, en r\'eparation
  \subitem r\'ef\'erence d'emprunt
\item le fichier des emprunts

  \subitem r\'ef\'erence (n\'e d'identifiant unique)
  \subitem r\'ef\'erence livre
  \subitem r\'ef\'erence d'emprunteur
  \subitem date d'emprunt
  \subitem date limite d'emprunt
\end{itemize}

Il faut que l'on puisse emprunter, rendre, ajouter, retirer, modifier l'\'etat d'un livre, et inscrire,
d\'esinscrire les emprunteurs.\\

Vous permettrer \'egalement~:
\begin{itemize}
\item de g\'erer les retards de rendu d'ouvrages
\item de rechercher un ouvrage
\end{itemize}
% \acacher{
% *Analyse besoins~:
% -Objectif (but, pb \`a  r\'esoudre, vision sujet)~:
% -Type d'utilisateur (niveau comp\'etence)~:
% -Contexte d'utilisation (\'e quelles occasions, types d'utilisation (initialisation, configuration), novice/exp\'eriment\'e)~:
% -I/O (donn\'ees \`a  fournir et sous quelle forme, r\'esultats et sous quelle forme)~:
% -Caract. quant. (taille et quantit\'e des donn\'ees)~:
% *Sp\'ecification~:
% -Fonctionalit\'es (services qu'il doit rendre, donner des sc\'enario d'utilisation, donn\'ees apparaissent)~:
% -Version pr\'eliminaire interface (\'ecrans et enchainement en fonction choix user)~:
% -Version pr\'eliminaire manuel utilisateur (fonctionalit\'es bien d\'ecrites donc comment utiliser logiciel)~:
% }

\newpage 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Matrices creuses}
\label{sec:creuses}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Les matrices creuses sont des matrices ayant beaucoup d'\'el\'ements nuls.
Soit $A$ une matrice creuse.  Pour chaque \'el\'ement non nul $a[i,j]$ on
cr\'ee un enregistrement de cinq champs contenant


\begin{itemize}
\item la valeur,


\item  les indices $i$,$j$,


\item  deux pointeurs vers l'\'el\'ement non nul suivant de de sa ligne et
  de sa colonne respectivement.


\end{itemize}
        
La matrice sera repr\'esent\'ee par un tableau ligne et un tableau colonne
de pointeurs t\'ete de liste pour les lignes et les colonnes
respectivement.  Par exemple la matrice :

$$\left(
\begin{array}{cccccc}
        0       &0      &7      &0      &0      &4\\
        0       &0      &0      &0      &0      &0\\
        0       &0      &0      &0      &0      &0\\
        0       &0      &5      &0      &0      &0
\end{array}
\right)
$$

donnera la repr\'esentation :

\begin{center}
\includefigtr{mat1}{scale=.75}{scale=.75}
%\includegraphics{mat1.eps}
\end{center}

Le logiciel permettra l'addition, la soustraction et la multiplication
de matrices creuses.  On pourra sauvegarder et restaurer des matrices
creuses. Vous pourrez \'egalement remplacer les tableaux qui
repr\'esentent la matrice par des listes.

\newpage

\section{Calcul formel}
\label{expsymb}


Une expression symbolique du type $x^2+3x+8$ peut \^etre repr\'esent\'ee par un arbre

\begin{center}
\includefigtr{a1}{scale=.5}{scale=.5}
% \includegraphics{a1.eps}
\end{center}
 

Dans un premier temps on se limitera aux 4 op\'erations de base.  Le
logiciel permettra de saisir une expression symbolique, de l'\'evaluer
pour un valeur de $x$, et de la d\'eriver.  La notation la plus facile \`a
lire pour un programme est la notation polonaise invers\'ee (en
vigueur sur certaines calculatrices comme les HP48). Elle consiste
simplement \`a  donner les arguments de la fonction avant la fonction
elle m\^eme. Ainsi, $x^2+3x+8$ est-il not\'e $\ \ x\ x\ \times\ 3\ x\ 
\times\ +\ 8\ +$ en
notation polonaise invers\'ee.

Pour d\'eriver on utilise les formules de d\'erivation d'une somme, d'une
diff\'erence, d'un produit et d'un quotient.  Ainsi la formule $\ \ 
(ab)' = ab' + a'b \ \ \ \ $ se traduira par le fait que la d\'eriv\'ee de l'arbre

\begin{center}
\includefigtr{A2}{scale=.75}{scale=.75}
% \includegraphics{A2.eps}
\end{center}
 
 est l'arbre
 
 \begin{center}
\includefigtr{A3}{scale=.75}{scale=.75}
% \includegraphics{A3.eps}
\end{center}

Mais vous devrez aussi faire des simplifications \'el\'ementaires :

$$ (3x +1)' = 3 \times 1 + 0 \times x + 0 = 3 + 0 + 0 = 3 $$

Vous inclurez les fonctionnalit\'es suivantes~:

\begin{itemize}
\item ajouter des constantes: $\pi$ , $e$ ...
  
\item ajouter d'autres fonctions: sinus, log ...
  
\item am\'eliorer les simplifications.

\end{itemize}


% \acacher{
% *Analyse besoins~:
% -Objectif (but, pb \`a  r\'esoudre, vision sujet)~:
% -Type d'utilisateur (niveau comp\'etence)~:
% -Contexte d'utilisation (\'e quelles occasions, types d'utilisation (initialisation, configuration), novice/exp\'eriment\'e)~:
% -I/O (donn\'ees \`a  fournir et sous quelle forme, r\'esultats et sous quelle forme)~:
% -Caract. quant. (taille et quantit\'e des donn\'ees)~:
% *Sp\'ecification~:
% -Fonctionalit\'es (services qu'il doit rendre, donner des sc\'enario d'utilisation, donn\'ees apparaissent)~:
% -Version pr\'eliminaire interface (\'ecrans et enchainement en fonction choix user)~:
% -Version pr\'eliminaire manuel utilisateur (fonctionalit\'es bien d\'ecrites donc comment utiliser logiciel)~:
% }

\newpage


\section{Simulation de circuits \'electroniques}
\label{sec:circuit}

On voudrait simuler le fonctionnement d'un circuit \'electronique
logique, c'est-\`a-dire donner les valeurs de sortie (0 ou 1) en
fonction des valeurs donn\'ees en entr\'ee (0 ou 1).

Un circuit \'electronique est un ensemble de composants connect\'es entre
eux.  Ces composants peuvent \^etre  des portes AND (2 entr\'ees, 1
sortie), des portes OR (2 entr\'ees, 1 sortie), des portes XOR (2
entr\'ees, 1 sortie), des inverseurs NOT (1 entr\'ee, 1 sortie), des
entr\'ees IN (0 entr\'ee, 1 sortie) ou des sorties OUT (1 entr\'ee, 0
sorties). Les tables de
v\'erit\'es de ces composants sont les suivantes~:

\begin{center}
\begin{tabular}[h]{cccc}
  \begin{tabular}{c|c|c}
    AND&0&1\\
    \hline
    0&0&0\\
    \hline
    1&0&1\\
  \end{tabular}
  &
  \begin{tabular}{c|c|c}
    OR&0&1\\
    \hline
    0&0&1\\
    \hline
    1&1&1\\
  \end{tabular}
  &
  \begin{tabular}{c|c|c}
    XOR&0&1\\
    \hline
    0&0&1\\
    \hline
    1&1&0\\
  \end{tabular}
  &
  \begin{tabular}{c|c|c}
    NOT&0&1\\
    \hline
    &1&0\\
  \end{tabular}
\\
\end{tabular}

\end{center} 

Les circuits ne seront pas \'edit\'es dans le logiciel, mais charg\'es \`a
partir d'un fichier. Une ligne dans un fichier d\'ecrit soit un
composant (\texttt{composant NomComposant TypeComposant}), soit une
liaison entre deux composants (\texttt{liaison NomComposant N\'eSortie
  NomComposant N\'eEntr\'ee}), avec
\texttt{TypeComposant}$\in\{$\texttt{AND,OR,NOT,IN,OUT}$\}$ et
\texttt{NomComposant} un mot (suite de caract\`eres sans espace).

\textbf{Exemple de fichier de circuit~:}

\texttt{
\begin{tabular}[h]{lllll}
  composant&in1&IN\\
  composant&in2&IN\\
  composant&in3&IN\\
  composant&out1&OUT\\
  composant&and1&AND\\
  composant&or1&OR\\
  liaison&in1&1&and1&1\\
  liaison&in2&1&and1&2\\
  liaison&and1&1&or1&1\\
  liaison&in3&1&or1&2\\
  liaison&or1&1&out1\\
\end{tabular}
}\\

~ 
Vous inclurez les fonctionnalit\'es suivantes~:

\begin{itemize}
  
\item ajouter d'autres composants~: noeud1-2 (noeud qui envoie sur ses
  deux sorties la m\^eme chose que ce qu'il a en entr\'ee),
  multiplexeurs, ...
  
\item produire des tables de v\'erit\'e (tableaux dont les colonnes
  contiennent les valeurs en entr\'ee et les valeurs en sortie)
  
\item \'editer un circuit avec le logiciel


\item (et animer) les circuits (difficile)

\end{itemize}

% \acacher{
% *Analyse besoins~:
% -Objectif (but, pb \`a  r\'esoudre, vision sujet)~:
% -Type d'utilisateur (niveau comp\'etence)~:
% -Contexte d'utilisation (\'e quelles occasions, types d'utilisation (initialisation, configuration), novice/exp\'eriment\'e)~:
% -I/O (donn\'ees \`a  fournir et sous quelle forme, r\'esultats et sous quelle forme)~:
% -Caract. quant. (taille et quantit\'e des donn\'ees)~:
% *Sp\'ecification~:
% -Fonctionalit\'es (services qu'il doit rendre, donner des sc\'enario d'utilisation, donn\'ees apparaissent)~:
% -Version pr\'eliminaire interface (\'ecrans et enchainement en fonction choix user)~:
% -Version pr\'eliminaire manuel utilisateur (fonctionalit\'es bien d\'ecrites donc comment utiliser logiciel)~:
% }


\newpage
~

% \newpage 

\section{Assembleur MAMIAS}
\label{sec:MAMIAS}

MAMIAS est un langage assembleur pour machine virtuelle \'el\'ementaire utilis\'e pour
l'enseignement en premier cycle. Le logiciel lira un fichier source
contenant un texte de programme du type

\vskip 3mm

\begin{tabular}{lll}
def     & x     &31\\
def     & y     &30\\
\\
        & INIT  &0\\
        & CHARGE        &x\\
        & SAUTE &suite\\
        & RANGE &y\\
suite:
        & ADD   &x\\
        & ....
\end{tabular}
\vskip 3mm

o\`u les deux premi\`eres lignes d\'efinissent des 'variables', et dont les suivantes
sont les instructions du programme dans une notation symbolique.
Le logiciel g\'en\'erera un fichier binaire contenant le code de ce programme.

\vskip 5mm

Vous \'ecrirez aussi un outil de
visualisation de la m\'emoire centrale permettant d'ex\'ecuter un programme MAMIAS
pas \`a pas.

\vspace*{1cm}

\centerline{\bf Description de MAMIAS. }
\vspace*{3mm}

Les instructions et les donn\'ees sont cod\'ees dans des mots m\'emoire
({\bf huit positions binaires}). Chaque mot m\'emoire est rep\'er\'e par
un entier $n \geq 0$ appel\'e son {\bf adresse}, le mot m\'emoire
d'adresse $n$ est d\'esign\'e par $\texttt{(n)}$. On dispose en plus d'un
mot m\'emoire particulier appel\'e {\bf accumulateur} et d\'esign\'e par
$Acc$.

\vspace*{0.5cm}

{\bf Une instruction} est un mot m\'emoire d\'ecomposable en $Code Argument$
\begin{itemize}
\item $Code$ : est le num\'ero de code de l'op\'eration
(les 3 positions binaires de gauche), 
\item $Argument$ : est 
\begin{itemize}
\item ou bien une adresse \texttt{n},
\item ou bien un entier${}^5$ \texttt{x} (les 5 positions binaires de
droite).
\end{itemize}
\end{itemize}

On peut donc coder $8$ op\'erations (puisque Code est sur 3 bits), adresser $32$ mots m\'emoire (de $0$ \`a
$31$, puisque sur 5 bits) et utiliser des entiers sign\'es compris entre $-16$ et $15$.

{\bf Une donn\'ee} est un entier${}^8$ cod\'e dans
un mot m\'emoire adress\'e, ou figurant dans  l'accumulateur.

\vspace*{0.3cm}

Pour faciliter la lecture, chaque code op\'eration sera d\'esign\'ee
par une ``expression mn\'emonique'' (que MAMIAS lui-m\'eme n'est pas cens\'e
comprendre: il ne comprend que le code des 3 bits).

Les 8 op\'erations et l'effet des instructions correspondantes sont les
suivants : ($\leftarrow$ est l'affectation)
\begin{itemize}
\item \texttt{INIT} (Code $= 000$) : \texttt{INIT } est \texttt{Acc} $\leftarrow$ \texttt{x}

Note : \texttt{x} est un entier${}^5$ qui se trouve traduit en entier${}^8$
 dans l'accumulateur, plus pr\'ecis\'ement :
\begin{itemize}
\item l'instruction $0000abcd$ (\texttt{INIT }$0abcd$) donne la valeur
$0000abcd$ \`a  l'accumulateur,
\item l'instruction $0001abcd$ (\texttt{INIT }$1abcd$) donne la valeur
$1111abcd$ \`a  l'accumulateur.
\end{itemize}
\item \texttt{CHARGE } (Code $= 001$) : \texttt{CHARGE\ n} est \texttt{Acc} $\leftarrow$ \texttt{(n)}
\item \texttt{RANGE } (Code $= 010$) :  \texttt{RANGE\ n}  est \texttt{(n)}$\leftarrow$ \texttt{Acc}
\item \texttt{ET } (Code $= 011$) : \texttt{ET n} est \texttt{Acc}$\leftarrow$ \texttt{Acc }$\wedge$ \texttt{(n)}
 
o\`u $\wedge$ est l'op\'eration de conjonction bit \`a  bit (ou masquage)
d\'efinie par $1 \wedge 1 = 1$, $1 \wedge 0 = 0 \wedge 1 = 0 \wedge 0 = 0$.
Par exemple $10110001\wedge 11010000 = 10010000$.
\item \texttt{SAUTE } (Code $= 100$) : \texttt{SAUTE n}  est ``si \texttt{Acc} $= 0$
alors aller \`a  l'adresse \texttt{(n)}''
\item \texttt{ADD } (Code $= 101$) : \texttt{ADD n} est \texttt{(n)}$\leftarrow$ \texttt{(n) + Acc}
\item \texttt{DEC } (Code $= 110$) : \texttt{DEC x} d\'ecale de \texttt{x} positions le contenu
  de \texttt{Acc}

Ce d\'ecalage se produit vers la gauche si \texttt{x} est positif, et vers
la droite s'il est n\'egatif  : les digits qui ``sortent'' du mot sont perdus !

Par exemple, si \texttt{Acc }$= 01110011$ : 
\begin{itemize}
\item l'instruction $11000010$ (\texttt{DEC}$2$) donne la valeur $11001100$
\`a  l'accumulateur,
\item l'instruction $11011101$ (\texttt{DEC }$-3$) donne la valeur $00001110$
\`a  l'accumulateur.
\end{itemize}
\item \texttt{STOP } (Code $= 111$) : \texttt{STOP} arr\'ete l'ex\'ecution.

Les cinq positions binaires de droite n'ont aucune signification.

\end{itemize}
\vspace*{0.3cm}
Sauf avis contraire (donn\'e par l'op\'eration \texttt{SAUTE}), les instructions
s'ex\'ecutent dans l'ordre des adresses croissantes, \`a  partir de $0$.


\newpage
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Le jeu de la vie}
\label{sec:jeuvie}
Le jeu de la vie (cr\'e\'e par le math\'ematicen John Horton Conway) est
bas\'e sur l'\'evolution de populations cellulaires. Les cellules sont dispos\'ees sur une grille. La naissance et la
mort d'une cellule donn\'ee sont conditionn\'ees par la pr\'esence suffisante ou excessive de
cellules vivantes dans son voisinage imm\'ediat.
% l'\'enonc\'e disait 7 voisins au maximum, mais je ne comprends pas pourquoi
% j'ai corrig\'e en 8 voisins....
On consid\`ere que l'espace est constitu\'e d'une grille, dans laquelle
chaque case a 8 voisins au maximum (moins pour les bords et les
coins). Une case ne peut contenir qu'une seule cellule et les r\egles
de vie et mort sont les suivantes~:

\begin{itemize}
\item si le voisinage d'une case vide contient trois cellules, alors
  une cellule nait~;
  
\item si une cellule est entour\'ee de plus de 4 cellules, elle meurt
  \'etouff\'ee~;
  
\item si une cellule est entour\'ee d'une cellule ou moins, elle meurt
  d'isolement.

\end{itemize}

On voudrait pouvoir simuler l'\'evolution d'une population de cellules,
avec des facilit\'es de chargement/sauvegarde d'\'etat.

\hspace{-3.5cm}
{\small
\begin{tabular}{ccc}

\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & &X&X& & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}
&
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & &X&X& & & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & & & &X&X& & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}
&
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & &X& &X& & & & \\
  \hline
   & & & &X& & &X& & & \\
  \hline
   & & & &X& &X& & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}
\\
\'Etape 1&\'Etape 2&\'Etape 3\\
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & &X&X& &X&X& & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}
&
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & & &X& &X& & & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}
&
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & &X& &X& & & & \\
  \hline
   & & &X& & & &X& & & \\
  \hline
   & & & &X& &X& & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}\\
\'Etape 4&\'Etape 5&\'Etape 6\\
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & &X&X& &X&X& & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}
&
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & &X& & & &X& & & \\
  \hline
   & & &X& & & &X& & & \\
  \hline
   & & &X& & & &X& & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}
&
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & &X& &X& &X& & & \\
  \hline
   & &X&X&X& &X&X&X& & \\
  \hline
   & & &X& &X& &X& & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}\\
\'Etape 7&\'Etape 8&\'Etape 9\\
\end{tabular}
}

\acacher{
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & &X& & & &X& & & \\
  \hline
   & & &X& & & &X& & & \\
  \hline
   & & &X& & & &X& & & \\
  \hline
   & & & &X&X&X& & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}
\begin{tabular}[h]{|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|p{0.1cm}|}
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & &X&X&X& &X&X&X& & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & &X& & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
   & & & & & & & & & & \\
  \hline
\end{tabular}
}

 \paragraph ~
 
Vous inclurez les fonctionnalit\'es suivantes~:
\begin{itemize}

\item consid\'erer un espace torique (le haut et le bas se rejoignent,
  ainsi que la droite et la gauche)
  
   \item fixer les dimensions d'une grille
\item \'editer une configuration de grille 


\item  choisir la vitesse de d\'eroulement
\item lancer une simulation
\item  permettre \`a  l'utilisateur de modifier l'\'etat du jeu pendant son d\'eroulement
\item sauvegarder/recharger une grille \`a partir d'un fichier

\end{itemize}

\newpage

\section{Th\'ematiseur G\'en\'eral}
\label{sec:thematiseur}

Le logiciel de th\'ematisation (th\'ematiseur g\'en\'eral) aura en entr\'ee un document et r\'ecup\`erera en provenance des th\'ematiseurs sp\'ecialis\'es les pourcentages qu\'ils obtiennent (c'est-\`a-dire les pourcentages de mots faisant partie de leur liste th\'ematique de mots-cl\'es associ\'es). Il retourne alors la liste des th\`emes (i.e. des th\'ematiseurs) pour lesquels le pourcentage obtenu est sup\'erieur \`a un certain seuil. Le th\'ematiseur g\'en\'eral peut ainsi parcourir la liste de tous les th\'ematiseurs sp\'ecialis\'es pour d\'ecouvrir les th\`emes correspondant au document, mais l'utilisateur peut aussi s\'electionner au pr\'ealable une liste de th\`emes \`a parcourir (i.e. une liste de th\'ematiseurs sp\'ecialis\'es \`a consulter) pour limiter la recherche des th\`emes dans un sous-ensemble de th\`emes initiaux.
 \paragraph ~
Quelques id\'ees pour vous permettre d'impl\'ementer un jeu d'essais :
  \paragraph ~
Th\`eme astronomie : astronomie astronome soleil lune v\'enus saturne pluton neptune mercure galaxie plan\`ete plan\`etes \'etoile \'etoiles satellites mars jupiter cosmique terre lunette t\'elescope ciel lumi\`ere \'eclipse exploration astrophysique cosmogonie cosmos cosmographie longue-vue lorgnette astre com\`ete nova filante m\'et\'eorite m\'et\'eore ast\'erode a\'erolithe spoutnik lact\'ee astral.

Th\`eme science : science scientifique technologique m\'edecine astronomie astrophysique chimie informatique math\'ematique biologie physique g\'eologie pal\'eontologie histologie g\'eom\'etrie empirisme logique empirique d\'ecouverte scientifique cognition savoir exp\'erimental alg\`ebre alg\'ebrique formule preuve connaissances.

Th\`eme horoscope : horoscope horoscopes poisson verseau b\'elier taureau g\'emeau cancer lion vierge balance scorpion sagittaire capricorne amour travail sant\'e sensible coeur chance argent carri\`ere c\'elibataire soleil lune v\'enus mars saturne jupiter rencontre \'etoile ciel pr\'ediction astrologie astrologue astrologues devin \'esot\'erisme divination destin destin\'ees signe signes astral ascendant d\'ecan.

Th\`eme humour : rire histoires belges blondes blonde belge toto comique blague blagues com\'edie charade plaisanterie dr\^ole gal\'ejade canular farce farces hilarit\'e pouffer esclaffer sourire rigoler amuser amuse amusant hilarant jeu bouffonnerie bouffon clown ironie malice noir anglais.

 \paragraph ~
 
Document1 :
Les astrologues sont de plus en plus consult\'es par les personnes fragiles lire leur horoscope les rassure et les amuse le ciel et les plan\`etes ont toujours fascin\'e l homme et l astronomie n a pas su faire dispara\^itre l astrologie

Document2 :
Le rire est le propre de homme mais il y a des sens de l humour bien particulier j aime l humour anglais mais je d\'eteste l humour des \'etudiants de m\'edecine leurs farces sont souvent macabres et ne me font pas rire

Document3 :
Je ne regarde jamais mon horoscope sur Internet je pr\'ef\`ere y lire des blagues mes blagues pr\'ef\'er\'ees sont celles sur les blondes

Document4 :
Une blonde entre dans une biblioth\`eque et demande un livre \`a la biblioth\'ecaire de quel auteur interroge la biblioth\'ecaire heu r\'epond la blonde de vingt centim\`etres


% \acacher{
% *Analyse besoins~:
% -Objectif (but, pb \`a  r\'esoudre, vision sujet)~:
% -Type d'utilisateur (niveau comp\'etence)~:
% -Contexte d'utilisation (\'e quelles occasions, types d'utilisation (initialisation, configuration), novice/exp\'eriment\'e)~:
% -I/O (donn\'ees \`a  fournir et sous quelle forme, r\'esultats et sous quelle forme)~:
% -Caract. quant. (taille et quantit\'e des donn\'ees)~:
% *Sp\'ecification~:
% -Fonctionalit\'es (services qu'il doit rendre, donner des sc\'enario d'utilisation, donn\'ees apparaissent)~:
% -Version pr\'eliminaire interface (\'ecrans et enchainement en fonction choix user)~:
% -Version pr\'eliminaire manuel utilisateur (fonctionalit\'es bien d\'ecrites donc comment utiliser logiciel)~:
% }




% \end{document}

% Voir quelles sont les informations \`a  donner aux \'etudiants.
% Pour chaque sujet, noter les informations, sans r\'ediger.
% R\'ediger les sujets


% \acacher{
% *Analyse besoins~:
% -Objectif (but, pb \`a  r\'esoudre, vision sujet)~:
% -Type d'utilisateur (niveau comp\'etence)~:
% -Contexte d'utilisation (\'e quelles occasions, types d'utilisation (initialisation, configuration), novice/exp\'eriment\'e)~:
% -I/O (donn\'ees \`a  fournir et sous quelle forme, r\'esultats et sous quelle forme)~:
% -Caract. quant. (taille et quantit\'e des donn\'ees)~:
% *Sp\'ecification~:
% -Fonctionalit\'es (services qu'il doit rendre, donner des sc\'enario d'utilisation, donn\'ees apparaissent)~:
% -Version pr\'eliminaire interface (\'ecrans et enchainement en fonction choix user)~:
% -Version pr\'eliminaire manuel utilisateur (fonctionalit\'es bien d\'ecrites donc comment utiliser logiciel)~:
% }

% D'abord faire des choses correctes, ensuite am\'eliorer par rapport au sujet




% \documentclass[a4paper]{article}
% \usepackage{graphics}
% \usepackage[latin1]{inputenc}
% \usepackage{vmargin}
% \setmarginsrb{20mm}{20mm}{20mm}{20mm}{0mm}{0mm}{0mm}{0mm}
% \date{}
% \newcommand{\code}[1]{\texttt{#1}}
% \newcommand{\para}[1]{\\\textbf{#1.}}
% \def\rc{\mbox{}\\}
% \begin{document}
% \begin{flushleft}
%   LICENCE D'INFORMATIQUE 
% \end{flushleft}
% \begin{flushright}
%   2001-2002
% \end{flushright}
% \begin{center}
% {\Large \rc\rc \textbf{\'Etude de cas}\\\textbf{Sujets de projet}\\\rc\rc}
% \end{center}
% Vous devez r\'ealiser un projet par groupe de trois. Le langage impos\'e est le langage C. Vous pouvez soit choisir un sujet parmi ceux pr\'esent\'es ici (une
% description plus compl\'ete vous sera fournie \`a  la prochaine s\'eance), soit en proposer un (dans ce cas, il devra comporter une partie demande d'informations \'e
% l'utilisateur, une partie affichage de r\'esultats, et une partie gestion de fichiers). Dans tous les cas, vous pourrez poser des questions \`a  votre enseignant
% durant le cours de l'ann\'ee.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Le jeu Othello (aussi appel\'e Reversi)}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Le jeu prend place sur un damier de 8$\times$8. Les pions ont deux faces de couleur diff\'erente~: une blanche, et une noire. Chaque joueur choisit une couleur
% au d\'ebut du jeu, et le but est de colorier le plus de case possible sur l'\'echiquier avec sa couleur. Au d\'ebut du jeu, chaque joueur dispose deux de ses pions
% en diagonale au centre du damier, avant de jouer. Le blanc commence alors \`a  jouer en pla\'eant un pion dans une case vide en respectant les conditions
% suivantes~: i) le pion est plac\'e de fa\'eon \`a  former un alignement vertical, horizontal ou diagonal avec un autre pion de m\^eme couleur~; ii) entre les deux
% extr\'emit\'es de l'alignement form\'e, il ne doit y avoir que des pions adverses (il n'est pas possible de laisser des espaces vides). Les pions de couleur adverse
% ainsi pris au pi\'ege changent de couleur, et c'est au tour de l'autre joueur. Si un joueur ne peut pas jouer, il passe son tour autant de fois que n\'ecessaire.
% Le jeu s'arr\^ete lorsque le damier est plein ou que plus personne ne peut jouer. Il est alors temps de compter le nombre de cases occup\'ees par chaque
% couleur.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Gestion d'arbres g\'en\'ealogiques}
% \label{arbregene}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Le programme doit permettre \`a  l'utilisateur de saisir des arbres g\'en\'ealogiques, puis de les afficher et de les modifier. L'utilisateur devra aussi avoir la
% possibilit\'e de sauvegarder l'arbre dans un fichier et, bien s\^ur, de pouvoir afficher, modifier, compl\'eter un arbre ainsi sauvegard\'e.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Roulette}
% \label{sec:roulette}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Plusieus joueurs s'affrontent \`a  la roulette. Chaque joueur poss\'ede initialement une certaine somme. \`A chaque tour, chacun mise sur un num\'ero seul ou sur une
% combinaison (plusieurs num\'eros, num\'eros pairs, ...). Ensuite, on proc\'ede au tirage d'un num\'ero. Les joueurs qui ont mis\'e juste re\'eoivent des gains
% proportionnels. On souhaite aussi pouvoir sauvegarder (et donc r\'ecup\'erer) des parties en cours.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Monopoly}
% \label{sec:monopoly}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Le but est de simuler le c\'el\'ebre jeu du monopoly. Il s'agit d'un jeu de plateau comportant un circuit de $36$ cases sur lesquelles se trouvent des terrains \'e
% acheter. Chaque joueur est muni d'une somme initiale et avance son pion sur le circuit par des lancers de d\'es. Si le terrain sur lequel s'arr\^ete un joueur
% n'est pas encore vendu, il peut l'acheter~; sinon, il doit payer un loyer au propri\'etaire. On veut pouvoir sauvegarder et charger des parties en cours.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{La guerre des programmes}
% \label{sec:batailleprog}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% L'objectif du logiciel ``la guerre des programmes'' est de simuler un combat entre plusieurs programmes \'ecrits en MAMIAS. Initialement, chaque programme est
% plac\'e al\'eatoirement dans la m\'emoire dans une certaine zone qui constitue son territoire. Le logiciel simule l'ex\'ecution des deux programmes pas-\'e-pas, l'un
% apr\'es l'autre, de fa\'eon entrelac\'ee. Une adresse \`a  laquelle un programme MAMIAS \'ecrit une valeur devient son territoire. Un joueur perd s'il ex\'ecute une
% instruction ``stop'' ou s'il ex\'ecute une instruction se trouvant dans le territoire ennemi. Au bout d'un certain nombre d'it\'erations sans gagnant, le joueur
% qui a conquis le plus d'adresses est d\'eclar\'e vainqueur.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Le jeu de la vie}
% \label{sec:jeuvie}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Le jeu de la vie (cr\'e\'e par math\'ematicen John Horton Conway) est bas\'e sur l'\'evolution de populations cellulaires. La naissance et la mort y sont conditionn\'ees
% par la pr\'esence suffisante ou excessive de cellule vivantes dans le voisinage d'une cellule. On consid\'ere g\'en\'eralement un espace plat, constitu\'e d'une grille,
% dans laquelle chaque case a 7 voisins. Une case ne peut contenir qu'une seule cellule et les r\'egles sont les suivantes~: i) si le voisinage d'une case vide
% contient trois cellules, alors une cellule nait~; ii) si une cellule est entour\'ee de plus de 4 cellules, elle meurt \'etouff\'ee~; iii) si une cellule est
% entour\'ee d'une cellule ou moins, elle meurt d'isolement. On voudrait pouvoir simuler l'\'evolution d'une population de cellules, avec des facilit\'es de
% chargement/sauvegarde d'\'etat.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Manipulation de matrices}
% \label{sec:syseqlin}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Ce logiciel doit permettre de saisir, de sauvegarder et de charger des matrices. Il doit aussi permettre de r\'esoudre des syst\`emes d'\'equations lin\'eaires par
% diff\'erentes m\'ethodes, et d'effectuer des op\'eration courantes.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Gestion de compte bancaire}
% \label{sec:compteBanque}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Une petite banque a besoin d'un logiciel pour g\'erer les livrets d'\'epargne de ses clients. Un client peut venir ouvrir un livret, le fermer, effectuer des
% retraits, des d\'ep\^ots. Tous les ans, ce compte lui rapporte $3,5\%$.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Motus}
% \label{sec:motus}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Il s'agit simplement de simuler le jeu t\'el\'evisuel. La premi\'ere lettre d'un mot de taille connue est donn\'ee. Le joueur doit proposer un mot la m\^eme taille.
% Toute lettre du mot propos\'e qui est aussi dans le mot cherch\'e est signal\'e soit bien plac\'ee (si elle se situe \`a  la bonne place) soit mal plac\'ee. Le but est de
% d\'ecouvrir le mot en un nombre de coups limit\'e.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Organiseur}
% \label{sec:organiseur}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Un organiseur est un logiciel qui permet \`a  un utilisateur de stocker son emploi du temps. Le logiciel doit au moins permettre de noter des rendez-vous sur un
% an, de 6h00 \`a  23h00, \`a  raison d'un par heure. L'organiseur devra permettre de noter, de stocker et de r\'ecup\'erer son emploi du temps.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Gestion de biblioth\'eque}
% \label{sec:biblio}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Le gestionnaire de biblioth\'eque devra permettre de stocker des r\'ef\'erences de livres (auteur, titre, ...) et \'egalement de rechercher un ouvrage selon certaines
% informations.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Manipulation d'expressions symboliques}
% \label{sec:expsymb}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Le logiciel permettra de saisir une expression symbolique (par exemple $x\ln x-x$), de l'\'evaluer ($[x\ln x-x]_{x=1}=-1)$ et de la d\'eriver ($(x\mapsto x\ln
% x-x)'=\ln x)$). On d\'esirera aussi stocker et r\'ecup\'erer les fonctions sauvegard\'ees. Rmq~: les difficult\'es apparentes ne doivent pas vous effrayer~; les
% indications qui vous seront fournies vous permettront de vaincre les probl\`eme s algorithmiques.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Les chiffres et les lettres}
% \label{sec:chiffre_lettre}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Ce jeu est la r\'eplique du c\'el\'ebre jeu de t\'el\'evision ``les chiffres et les lettres''. La partie chiffre consiste \`a  se rapprocher le plus possible d'une
% certaine valeur en utilisant les quatres op\'erateurs de base ($+$,$\times$,$-$,$\div$) et un tirage de nombres. Le but de la partie lettre est de trouver le
% plus long mot en utilisant au plus une fois les lettres d'un tirage de neuf lettre.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{La bataille navale}
% \label{sec:batnav}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Initialement, chaque joueur place ses bateaux de diff\'erents types sur son damier. Puis, chacun son tour, chaque joueur essaie de tirer sur les bateaux ennemis
% en donnant les coordonn\'ees d'une case adverse. Si le boulet tombe sur un bateau, le programme doit le signaler par un message ``bateau de type T touch\'e''. Si
% le bateau est enti\'erement touch\'e, il est consid\'er\'e coul\'e. Si le boulet tombe \`a  une case d'un bateau, le programme doit le signaler par un message ``bateau en
% vue''. Le joueur qui r\'eussit \`a  couler tous les bateaux ennemis a gagn\'e.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Master Mind}
% \label{sec:mastermind}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Le but du jeu est de d\'ecouvrir une combinaison de pions de couleur diff\'erentes (le nombre de 
% pion et de couleur peut varier en fonction du niveau). Le joueur
% qui cherche propose une combinaison de pions. Le programme lui indique alors combien de pions sont bien plac\'es (bonne couleur \`a  la bonne place) et combien
% sont mal plac\'e (bonne couleur, mais pas \`a  la bonne place). Le master mind peut se jouer \`a  un ou deux joueurs. Dans la version mono-joueur, le choix de la
% combinaison est fait par le programme. Le but est de trouver $10$ combinaisons en un minimum de propositions. Dans la version bi-joueurs, c'est l'adversaire
% qui propose une combinaison. A chaque tour, on aditionne le nombre de coups qu'a utilis\'e le joueur pour trouver la bonne combinaison. Le perdant est le
% premier qui atteint $100$. La partie pourra \^etre  sauvegard\'ee et recharg\'ee.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Jeu de r\^oles}
% \label{sec:jeu_role}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% L'univers de notre jeu de r\^oles est l'universit\'e~: il contient plusieurs salles de classes desquelles les joueurs-\'etudiants peuvent entrer et sortir.
% Lorsqu'un \'etudiant entre dans une salle, il peut capitaliser une UV (la pr\'esence d'UV est al\'eatoire). Mais il doit \'echapper aux d\'ebaucheurs qui volent les UV
% quand on le rencontre dans une salle. Si un \'etudiant sans UV p\'en\^etre dans une salle qui contient un d\'ebaucheur, il peut lui voler ses UV. Les enseignants
% renvoient tous les voleurs d'UV, d\'ebaucheurs ou \'etudiants. Dans ce logiciel, les joueurs auront le r\^ole d'\'etudiant. Le premier qui r\'eussit \`a  capitaliser 5
% UV a gagn\'e. Le d\'eplacement des d\'ebaucheurs et les enseignants seront simul\'es par l'ordinateur. Il faudra pouvoir sauvegarder une partie en cours.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Rami}
% \label{sec:rami}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Le rami est un jeu de cartes qui se joue \`a  deux personnes. Le but est de poser des combinaisons de cartes avant l'adversaire, une combinaison pouvant \^etre 
% un s\'equence d'au moins trois cartes ou un brelan (trois cartes identiques) ou un carr\'e (quatre cartes identiques). Initialement, chaque joueur re\'eoit treize
% cartes. Il doit poser toutes se cartes sous forme de combinaisons avant l'adversaire, et peut compl\'eter les combinaisons de son adversaire.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Black-Jack}
% \label{sec:blackjack}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Chaque joueur re\'eoit du croupier (simul\'e par l'ordinateur) deux cartes, chaque valeur ayant une certaine valeur (de $2$ \`a  $10$ pour les cartes basses, $10$
% pour toutes les t\^etes couronn\'ees, et au choix $1$ ou $11$ pour l'as). L'objectif du joueur est que la somme de ses cartes s'approche le plus possible de
% $21$, sans le d\'epasser.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Simulation de circuits \'electroniques}
% \label{sec:circuit}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Les circuits \'electroniques \`a  simuler sont constitu\'es de composants reli\'es entre eux par des entr\'ees et des sorties. La simulation consiste \`a  envoyer un signal
% \`a  l'entr\'ee du circuit (des $0$ ou des $1$) et \`a  observer ce qui se passe \`a  la sortie (encore des $0$ ou des $1$). Ce logiciel devra permettre de cr\'eer, de
% sauvegarder et de charger des circuits \'electroniques.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \para{Space Invaders}
% \label{sec:space_invaders}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% ``Space Invaders'' est un jeu sens\'e simuler une bataille contre les envahisseurs de l'espace. Votre vaisseau se d\'eplace horizontalement au bas de l'\'ecran
% tandis que les extra-terrestres font des aller-retour de gauche \`a  droite et descendent d'une ligne \`a  chaque fois qu'ils atteignent une extr\'emit\'e de l'\'ecran.
% Le joueur et l'ennemi se tirent dessus~; vous perdez quand vous avez \'et\'e touch\'e trois fois, vous gagnez des points quand vous tuez un vaisseau et quand vous
% les avez tous d\'etruit. Le joueur devra pouvoir sauvegarder et r\'ecup\'erer une partie en cours.


\appendix

	
\chapter{Guide de r\'ealisation des projets}
\label{cha:guide-de-realisation}

% Cette partie a \'et\'e initialement r\'edig\'ee par Marc Champesme
% (D\'epartement d'Informatique, Institut Galil\'ee, Universit\'e
% Paris-Nord). Mais de nombreuses modifications ont \'et\'e apport\'ees pour l'adapter
% aux contraintes des projets de fin d'ann\'ee.


\section{Pr\'eliminaires}

L'\'ecriture d'un programme sur machine doit imp\'erativement \^etre
pr\'ec\'ed\'ee de l'analyse du probl\`eme et de la conception du logiciel.  C'est la raison
pour laquelle nous vous demandons de nous remettre un document avant de vous mettre \`a coder. Ce document nous permet de vous faire des remarques, et vous le corrigerez avant
de vous mettre \`a la conception d\'etaill\'ee et au codage. La version corrig\'ee sera ensuite incorpor\'ee au
m\'emoire que vous nous remettrez en fin de projet.
%Une fois les algorithmes \'ecrits dans un
%pseudo-langage, l'ex\'ecution de ceux-ci doit \^etre simul\'ee ``\`a la main"
%pour des exemples de petite taille dans le but d'\'eviter de d\'ecouvrir,
%lors de la programmation, des erreurs dues \`a  des contraintes non
%prises en compte lors de l'analyse, ou d'essayer de corriger un
%programme qui repose sur des algorithmes erron\'es d'un point de vue
%logique.  Une fois le programme mis au point, il faut le tester, c'est
%\`a dire prendre des valeurs de param\`etres moyennes ou limites, pour
%v\'erifier le bon comportement du programme en toute occasion.

%De plus, un logiciel doit \^etre \'ecrit en pensant qu'il peut \^etre
%r\'eutilis\'e un jour, par son concepteur ou un autre informaticien. Il
%doit donc \^etre facile \`a  comprendre, lisible et bien comment\'e. Cela
%n\'ecessite un certain style de programmation, comme de ne pas utiliser
%d'astuces (ou alors de les commenter dans le code), de ne pas essayer
%d'optimiser \`a  tout prix (en particulier optimiser la longueur du code
%en minimisant la longueur des identificateurs, ce qui est sans effet
%sur le temps d'ex\'ecution !). Le programme doit \^etre accompagn\'e d'un
%document qui en explique l'organisation, les fonctionnalit\'es et les
%diff\'erents modules pour l'informaticien r\'eutilisateur (celui qui aura
%\`a corriger les bogues du logiciel ou \`a  en concevoir des extensions) et
%d'un manuel utilisateur (pour celui qui utilisera effectivement le
%logiciel sans avoir particip\'e \`a  sa r\'ealisation).

Votre projet devra \^etre r\'ealis\'e en fonction des besoins et
caract\'eristiques des futurs utilisateurs du logiciel. 
%Cependant, dans
%le cadre de ce projet, vous ne disposez pas d'un interlocuteur
%susceptible de jouer le r\^ole de l'utilisateur final. La r\'ealisation de
%votre projet n\'ecessitera donc que vous imaginiez un utilisateur et le
%plus simple sera probablement d'imaginer que cet utilisateur est
%quelqu'un qui vous ressemble ! Cependant, en aucun cas vous ne devez
%supposer que vous serez le seul et unique utilisateur du logiciel~:
Vous devez concevoir le logiciel afin qu'il soit facilement utilisable
pour les personnes auxquelles il est destin\'e. Ainsi il peut s'agir d'un enfant ou d'un adulte,
de quelqu'un qui ne connait rien \`a l'informatique ou au domaine explor\'e, ou au contraire
d'un expert du domaine ou d'un expert en informatique. 
Il est  donc important de savoir \`a qui le logiciel
est destin\'e, car cela d\'etermine la forme de l'interface utilisateur et les fonctionnalit\'es propos\'ees.

~
Parall\`element, on doit d\'eterminer quelle est la t\^ache effectu\'ee par cet
utilisateur potentiel.
Le but du logiciel, c'est ce \`a quoi il sert, ce qu'il permet de faire, sa ou ses fonctions principales. Les ergonomes distinguent ici deux niveaux de description : celui de la t\^ache que permet d'accomplir le logiciel (par exemple, \'ecrire une lettre pour un traitement de texte, jouer aux \'echecs pour un jeu d'\'echecs, g\'erer une biblioth\`aque, etc.), et celui des fonctionnalit\'es propos\'ees par le logiciel pour permettre d'accomplir la t\^ache (par exemple, mettre en gras, justifier \`a droite, d\'efinir des marges, etc. pour un logiciel de traitement de texte, ou se connecter en r\'eseau, jouer une partie, pour un jeu d'\'echecs). Le niveau de la t\^ache est assez g\'en\'eral et orient\'e "utilisateur", et celui des fonctionnalit\'es est plus fin et plus orient\'e "programmation". 
~
Pour bien fixer tout cela, nous vous demandons de nous rendre un premier document contenant une pr\'esentation et une analyse approfondie de votre projet, ainsi qu'une liste d\'etaill\'ee des fonctionnalit\'es du logiciel. La section qui suit vous donne des indications sur le contenu de cette premi\`ere partie. La section suivante concerne la conception et vous aidera \`a r\'ediger la seconde partie concernant l'architecture logicielle qui vous est \'egalement demand\'ee dans le premier document \`a remettre.

\section{Analyse approfondie et sp\'ecifications fonctionnelles}
\label{sec:ana-approf}

Cette \'etape de la description du projet doit permettre de d\'eterminer
ce que le logiciel \`a  d\'evelopper devra permettre de faire (le quoi ?). A cette
\'etape, on ne se pr\'eoccupe pas de savoir comment le logiciel permettra
de r\'ealiser ces fonctionnalit\'es (on ne se pr\'eoccupe donc pas de l'interface utilisateur), ni
bien entendu de comment ces fonctionnalit\'es seront
programm\'ees. Cela signifie, en particulier, que cette partie ne
ne doit pas d\'ependre ou mentionner des aspects d'implantation comme
les caract\'eristiques d'un langage de programmation ou d'une machine.
On ne se pr\'eoccupe \`a  cette \'etape que des services que le logiciel
doit rendre \`a  l'utilisateur. En principe, c'est
seulement apr\`es cette premi\`ere \'etape que le choix du langage de
programmation et de l'environnement logiciel et mat\'eriel sera effectu\'e.
% (quel syst\`eme
%d'exploitation ? quels outils de d\'eveloppement ?).
%M\^eme si dans le cadre de votre projet ces choix (langage de
%programmation et environnement logiciel et mat\'eriel) vous sont
%impos\'es, il faut, au maximum, en faire abstraction. 
%Le risque est que
%les fonctionnalit\'es du logiciel soient d\'etermin\'ees en fonction de vos
%connaissances du langage de programmation ou de l'environnement
%logiciel et mat\'eriel. En effet, un des buts majeurs de la r\'ealisation
%de ces projets est justement de vous faire acqu\'erir des comp\'etences
%suppl\'ementaires dans ces domaines (programmation dans un environnement
%logiciel et mat\'eriel bien d\'efini).

\subsection{Analyse approfondie et analyse des besoins}

L'analyse approfondie est consacr\'ee \`a  l'explicitation du contexte d'utilisation du
logiciel et des besoins des utilisateurs. C'est la raison pour laquelle on parle d'analyse des besoins. Cette analyse r\'epondra aux questions suivantes :

\begin{description}

\item[Quel est l'objectif du logiciel :] \`a  quoi doit-il servir, quel
  est le probl\`eme  qu'il doit r\'esoudre ?  L'analyse commence par exposer
  ce sur quoi porte le logiciel, et ce qu'il permet de faire (la ou les  t\^aches qu'il permet d'ex\'ecuter). En particulier, il faudra introduire les objets (ou entit\'es abstraites)
  faisant partie du domaine sur lequel porte le logiciel (par exemple, des fichiers, des utilisateurs, et des arborescences de r\'epertoires pour un gestionnaire de fichiers; des pi\`eces, des joueurs, des parties, des coups et des plateaux pour un jeu  d'\'echecs; des vins, des bouteilles et des \'etag\`eres pour une cave \`a vin; des expressions alg\'ebriques pour un logiciel de calcul formel, etc.). Il est important ici d'introduire et de fixer le vocabulaire li\'e au domaine.
  
\underline{Conseil}: pour d\'ecrire ce que fait votre logiciel, vous pourrez partir de l'\'enonc\'e du sujet et d'un premier texte (de vous) d\'ecrivant le logiciel que vous souhaitez faire. Soulignez-y les mots qui vous semblent importants et essayez d'isoler de cette mani\`ere les entit\'es (objets ou concepts cl\'es) qui font partie de ce petit monde (=le domaine de l'application). Un programme est toujours la simulation d'un petit univers. Vous devez dans cette premi\`ere phase de conception, lister les objets faisant partie de cet univers en vous aidant de la terminologie. Cela vous permet de mieux cerner ce que fait votre logiciel et vous permettra plus tard de choisir les structures de donn\'ees ou les objets qui feront partie de votre programme. Les entit\'es de votre domaine correspondront normalement \`a des noms, et les actions pouvant \^etre ex\'ecut\'ees \`a des verbes.
Une fois cette analyse de texte effectu\'ee, vous pourrez r\'e\'ecrire un texte de pr\'esentation du logiciel plus clair et plus pr\'ecis, car vous en aurez fix\'e le vocabulaire.
	
\sloppy

\item[A quel type d'utilisateur s'adresse le logiciel ?] quel est son \^age et son
  niveau de comp\'etence dans le domaine couvert par le logiciel?  Ces
  informations seront essentielles pour la conception de l'interface
  utilisateur et le choix des fonctionnalit\'es qui seront offertes.

\fussy

\item[Quel est le contexte d'utilisation du logiciel ?] A quelle(s)
  occasion(s), l'utilisateur se servira-t-il du logiciel?  Quelles
  sont les diff\'erents types d'utilisation du logiciel ? A titre
  d'exemple, il arrive souvent qu'un logiciel n\'ecessite une phase
  d'initialisation ou de configuration durant laquelle seules
  certaines fonctionnalit\'es seront utilis\'ees (et ces fonctionnalit\'es ne
  seront que tr\`es rarement utilis\'ees dans le contexte courant).
  Souvent, les diff\'erents contextes d'utilisation correspondent \`a  des
  types d'utilisateurs diff\'erents, par exemple, des utilisateurs
  novices ou des utilisateurs exp\'eriment\'es.

\item[D\'eterminer pr\'ecis\'ement les entr\'ees et les sorties du logiciel :]
  l'utili\-sa\-teur devra parfois fournir des donn\'ees au logiciel (les
  entr\'ees) pour qu'il puisse accomplir sa t\^ache.  Vous devez
  d\'eterminer sous quelle forme l'utilisateur disposera de ces donn\'ees
  afin de choisir la proc\'edure d'entr\'ee des donn\'ees la plus adapt\'ee.
  De la m\^eme fa\c{c}on, vous devez d\'eterminer quelle est la mani\`ere la
  plus appropri\'ee pour pr\'esenter les r\'esultats du programme (les
  sorties) \`a  l'utilisateur, cela d\'ependra en particulier de
  l'utilisation que fera l'utilisateur des r\'esultats produits par le
  logiciel.

\item[Caract\'eristiques quantitatives :] vous devez d\'eterminer la
  taille et la quantit\'e de donn\'ees que l'utilisateur doit pouvoir
  traiter avec le logiciel. Indiquer aussi s'il existe des limitations.

\end{description}

\subsection{Liste des fonctionnalit\'es du logiciel}
\label{subsec:liste}
En prenant en compte les points pr\'ec\'edents, vous devez d\'eterminer
pr\'ecis\'ement ce que le programme permet de faire, c'est-\`a-dire \'etablir la liste exhaustive de ses
fonctionnalit\'es.  C'est la partie la plus importante de cette \'etape, et c'est
celle qui n\'ecessitera le plus
gros travail de r\'edaction.  Chaque fonctionnalit\'e doit \^etre d\'ecrite sans pour autant entrer dans des d\'etails
d'implantation ou de configuration mat\'erielle.  Il ne faut pas  non plus expliciter comment
les fonctionnalit\'es seront propos\'ees \`a l'utilisateur par l'interface utilisateur. Pour bien
d\'ecrire les fonctionnalit\'es, il faut au contraire faire abstraction de l'interface utilisateur. Une bonne
mani\`ere pour vous de faire abstraction de l'interface utilisateur est d'imaginer que le logiciel n'a
pas d'interface graphique et ne permet d'interagir avec l'utilisateur que dans une fen\^etre
de type console dans laquelle il pourrait taper des commandes.
On essayera aussi dans la mesure du possible de pr\'esenter la liste des fonctionnalit\'es du logiciel
en les regroupant par sections, \'eventuellement hi\'erarchis\'ees. 
%Pour faire une
%analogie avec le travail d'un architecte pr\'eparant le plan d'une
%maison individuelle, il s'agit de d\'eterminer de quels types de pi\`eces
%le futur propri\'etaire aura besoin, comment le propri\'etaire souhaite
%utiliser chaque pi\`ece (pour dormir, regarder la t\'el\'evision, manger en
%famille, \'ecouter de la musique, travailler...), s'il souhaite disposer
%d'un jardin et pour quelle utilisation (pour cultiver un potager, pour
%jouer au football, pour mettre une caravane...).  Ce n'est qu'\`a
%l'\'etape suivante et en fonction des informations recueillies \`a  cette
%\'etape qu'il d\'eterminera le nombre exact de pi\`eces, leur emplacement et
%leur taille, et encore plus tard qu'il pourra d\'eterminer comment
%chaque pi\`ece sera effectivement construite (choix des mat\'eriaux et des
%proc\'ed\'es de construction).

%Les fonctionnalit\'es que doit r\'ealiser le logiciel seront d\'efinies via
%les interactions de l'utilisateur avec le syst\`eme.  Vous d\'ecrirez les
%diff\'erents sc\'enarios d'interactions entre syst\`eme et utilisateur en
%pr\'ecisant pour chaque sc\'enario les actions du syst\`eme et celles de
%l'utilisateur.  C'est ce qu'on appelle un cas d'utilisation (en UML et
%OOSE).  Par exemple, pour un logiciel de comptabilit\'e, un cas
%d'utilisation possible est de calculer et \'editer une fiche de paye.
%La description de cette utilisation possible est donn\'ee sous la forme
%d'un sc\'enario, qui indique s\'equentiellement les interactions et
%actions de chacun des intervenants dans le sc\'enario (les acteurs).  Ce
%sc\'enario est habituellement d\'ecrit \`a  l'aide d'un sch\'ema (cf.  figure
%\ref{fig:scenario}).

%\begin{figure}[htb]
%	\includegraphics[scale=1]{scenario}
%	\caption{Exemple de sc\'enario d'utilisation}
%	\label{fig:scenario}
%\end{figure}

%D'autres sc\'enarios sont possibles pour ce cas d'utilisation, mais on
%d\'ecrit le sc\'enario standard sur le sch\'ema.  Il faut cependant pr\'eciser
%les cas d'erreur ou les diff\'erentes possibilit\'es qui peuvent survenir.
%Ici, les donn\'ees pourraient \^etre non valides, ou bien le comptable
%pourrait ne pas demander l'impression mais continuer \`a  \'editer d'autres
%feuilles de paye, ou vouloir modifier un des param\'etres qu'il a
%entr\'es.

%Les fonctionnalit\'es du syst\`eme apparaissent en cherchant les
%utilisations possibles du logiciel.  Et en m\^eme temps, les donn\'ees
%n\'ecessaires au traitement (ici, quels sont les param\'etres saisis ?
%Que peut on imaginer comme donn\'ees internes au syst\`eme n\'ecessaires au
%calcul des montants ?  Du coup, une fonctionnalit\'e de modification des
%param\`etres du syst\`eme devient n\'ecessaire, par exemple pour changer le
%taux de TVA ou de pr\'el\`evement pour les ASSEDIC ou la caisse de
%retraite).  Les fonctions ou proc\'edures \`a  d\'efinir pour r\'ealiser le
%syst\`eme se dessinent \'egalement, avec leurs param\`etres.

%\sloppy

Pour chaque fonctionnalit\'e, il faudrait id\'ealement aussi pr\'evoir une proc\'edure de
test.  Il s'agit ici de pr\'eparer la phase de test en d\'ecrivant des
proc\'edures et \'eventuellement des donn\'ees qui permettront, une fois la
programmation effectu\'ee, de v\'erifier que la fonctionnalit\'e est
correctement implant\'ee.  (Ces tests pourront aussi \^etre utilis\'es lors de la d\'emonstration
finale pour la soutenance du projet).  Ici, vous pouvez dresser un tableau de validation indiquant pour chaque fonctionnalit\'e les valeurs probl\'ematiques et l'\'etat du test de validation (\`a faire, en cours, ou valid\'e). Ce tableau de validation vous sera demand\'e en phase de
conception mais ne fera pas n\'ecessairement partie du premier document remis. 
%comme
%illustr\'e sur le tableau~\ref{tbl:validation} (la colonne validation
%sera remplie lorsque la fonctionnalit\'e aura \'et\'e implant\'ee).


%\begin{table}[tbp]
%	\centering
%	\caption{Tableau de validation}
%	\begin{tabular}{|p{3.5cm}|p{5cm}|c|}
%		\hline
%		Fonctionnalit\'e & Valeur nominales, cas particuliers &
%		Validation \\
%		\hline
%		\hline
%		Calcul et \'edition de feuille de paye &
%		\begin{enumerate}
%			\item Nom du salari\'e connu
			
%			\item Nbre d'heures travaill\'ees : entier compris entre 20
%			et 39 ; cas particuliers <20, >39 et < 45 ; si autre
%			chose, message et it\'eration
%	
%			\item Salaire en francs et en euros, avec deux d\'ecimales
%		\end{enumerate} & \\
%		\hline
%		Modification des param\`etres du syst\`eme & V\'erifier les unit\'es
%		et ordre de grandeur des diff\'erents param\`etres & \\
%		\hline
%	\end{tabular}
%	\label{tbl:validation}
%\end{table}
%\fussy
	

\section{Conception}

L'activit\'e de conception consiste \`a  enrichir la description du
logiciel de d\'etails d'implantation afin d'aboutir \`a  une description
tr\`es proche d'un programme. Elle se d\'eroule en deux \'etapes: l'\'etape de
conception architecturale et l'\'etape de conception d\'etaill\'ee.  Cette seconde
\'etape peut \'eventuellement donner lieu \`a  une r\'evision de
la premi\`ere.
%
\subsection{Conception architecturale}
\label{subsec:archi}
L'\'etape de conception architecturale a pour but de d\'ecomposer le 
logiciel en composants simples et ind\'ependants les uns des 
autres (ces composants sont aussi appel\'es modules) afin de simplifier 
l'activit\'e de programmation qui suivra. Cette d\'ecomposition doit \^etre 
faite de sorte que chaque module puisse \^etre r\'ealis\'e de mani\`ere 
totalement ind\'ependante des autres, par des programmeurs diff\'erents. 
La personne qui, \`a  l'\'etape du codage, programmera un module doit 
pouvoir effectuer sa t\^ache sans avoir besoin de savoir comment les 
autres modules ont \'et\'e, sont ou seront programm\'es.

C'est aussi \`a  cette \'etape que l'on doit faire les choix contraignant 
l'implantation :
\begin{description}
	\item[Configuration mat\'erielle :] sur quel type de machine
	fonctionnera le logiciel ? Votre logiciel n\'ecessite-t-il la
	pr\'esence de p\'eriph\'eriques particuliers (\'ecran graphique, souris,
	imprimante, scanner, lecteur de CD-ROM, etc.)  ?

	\item[Configuration logicielle :] syst\`eme d'exploitation,
	compilateur, biblioth\`eques de fonctions. Pour chacun de ces
	logiciels, vous devrez pr\'eciser le num\'ero de version.

	\item[R\'eutilisation de logiciels existants :] Dans le cas
	particulier o\`u vous faites une nouvelle version d'un logiciel d\'ej\`a
	op\'erationnel, il faut choisir entre reprendre et modifier le
	logiciel ou le refaire compl\`etement.


\sloppy

	\item[Choix de l'environnement de d\'eveloppement :] l'environnement
	de d\'eveloppement est l'ensemble des logiciels que vous utiliserez
	pour la programmation (par exemple gcc, java ou eclipse).  Il comprend, au
	minimum, un compilateur, un \'editeur de texte et un d\'ebogueur.  Ces
	logiciels peuvent ou non \^etre accessibles \`a  partir d'une unique
	application.

\fussy

\end{description}

Pour r\'ealiser le d\'ecoupage en modules, on part des fonctionnalit\'es 
qui ont \'et\'e d\'efinies pr\'ec\'edemment. Pour chaque fonctionnalit\'e, on 
d\'efinit pr\'ecis\'ement son interface avec le reste du logiciel, 
c'est-\`a-dire l'ensemble des informations dont elle aura besoin pour 
effectuer sa t\^ache, et celles qu'elle pourra modifier. Puis on la 
d\'ecompose en modules plus simples, dont on pr\'ecise la fonction 
r\'ealis\'ee et l'interface avec le logiciel. Ce processus de 
d\'ecomposition est r\'eit\'er\'e jusqu'\`a obtenir des modules aussi simples 
que possible.

Lors de ce travail vous devez donner un nom le plus explicite 
possible \`a  chaque module et aux donn\'ees qu'il utilise ou produit.

Un autre but important de cette d\'ecomposition est de mettre en 
\'evidence des modules poss\'edant des caract\'eristiques suffisamment proches 
pour \^etre fusionn\'es en un m\^eme 
module plus g\'en\'eral (cette factorisation r\'eduira d'autant le travail de programmation). 
Dans le m\^eme ordre d'id\'ee, lorsque des biblioth\'eques logicielles sont 
disponibles, le d\'ecoupage en modules devra, autant que possible, 
permettre la r\'eutilisation de modules d\'ej\`a existant dans ces 
biblioth\`eques.

\sloppy
 \paragraph ~
En m\^eme temps que ce d\'ecoupage, vous devez faire appara\^{i}tre les 
d\'ependances entre modules : quel module utilise quel autre module ? Le 
r\'esultat de ce travail sera exprim\'e sous forme d'un graphe de 
d\'ependances : chaque module est repr\'esent\'e par une bo\^{i}te et les 
d\'ependances sont repr\'esent\'ees par des fl\`eches entre ces bo\^{i}tes.

\fussy

Pour d\'ecrire l'architecture du programme, on fournira donc dans le premier document remis
un d\'ecoupage en modules
(en choisissant soigneusement leurs noms). On donnera une br\`eve description des
modules et on les repr\'esentera sur un 
graphe de d\'ependances. 
Remarque: Il se peut qu'il existe plusieurs programmes, et
une architecture particuli\`ere du syst\`eme si ce dernier
utilise plusieurs composants logiciels, comme par exemple, une architecture
client/serveur. Mais on ne fait pas en r\'ealit\'e de distinction entre programme et module, et on repr\'esentera cette architecture globale sur le m\^eme diagramme
en indiquant les d\'ependances des diff\'erents programmes (consid\'er\'es comme des modules) par des fl\`eches.

On aura en particulier un d\'ecoupage classique si le logiciel poss\`ede
une interface graphique, ou s'il utilise une base de donn\'ees.
Dans le cas o\`u l'on a une interface graphique, on pr\'evoie g\'en\'eralement un
module destin\'e \`a l'interface. En effet le monde de l'interface est un monde \`a part
de celui du domaine du logiciel. Il est peupl\'e d'\'el\'ements comme des boutons
ou des menus, des bo\^ites de dialogue, etc. La construction et l'agencement
de ces \'el\'ements interactifs seront donc effectu\'es dans le module de l'interface graphique,
et ce dernier sera reli\'e au reste de l'application par des appels de fonctions.

De m\^eme, si l'on souhaite utiliser une base de donn\'ees, on pourra regrouper
dans un m\^eme module tout ce qui concerne la gestion de cette base de donn\'ees.
Ce module interagira alors avec le reste de l'application en permettant l'interrogation et
la modification de la base de donn\'ees.

\subsection{Conception de l'interface utilisateur}
Les diff\'erentes fonctionnalit\'es du logiciel seront accessibles via l'interface utilisateur. 
Mais une m\^eme fonctionnalit\'e peut  \^etre accessible de diff\'errentes mani\`eres : par exemple,
par l'interm\'ediaire d'un menu et par l'interm\'ediaire d'un bouton, ou encore, via une combinaison
de touches particuli\`eres (raccourci de commande) et par l'interm\'ediaire d'une barre d'outils.
En outre, l'interface utilisateur n'est pas n\'ecessairement une interface graphique avec clavier et souris.
N\'eanmoins dans la plupart des cas, on pourra donner une version pr\'eliminaire de
l'interface en pr\'esentant les diff\'erents \'ecrans devant lesquels pourra se trouver l'utilisateur. Bien que  la description de l'interface utilisateur ne figure pas dans le premier document que vous devez nous rendre, vous devrez, avant de vous lancer dans la conception d\'etaill\'ee et le codage, produire les documents suivants :


\begin{description}

\item[R\'ealisation d'une version pr\'eliminaire de l'interface :] les
  diff\'erents \'ecrans de l'interface utilisateur doivent \^etre d\'ecrits,
  ainsi que la mani\`ere dont ils s'encha\^{i}nent en fonction des choix de
  l'utilisateur.
	
\item[R\'edaction d'une version pr\'eliminaire du manuel utilisateur :]
  les fonctionnalit\'es doivent \^etre suffisamment bien d\'ecrites pour
  pr\'evoir pr\'ecis\'ement comment le logiciel pourra \^etre utilis\'e.  Le
  manuel utilisateur ne vous est pas demand\'e initialement, mais vous devrez
  le fournir dans la documentation finale. Il sera r\'edig\'e du point de vue
  de l'utilisateur et pourra  \^etre constitu\'e en partie de la description des diff\'erents
  \'ecrans. Pensez donc
  lors de la r\'edaction de votre document de description de l'interface \`a  garder le
  point de vue de l'utilisateur.
\end{description}

Mais avant de vous lancer dans la conception de l'interface utilisateur, il vous est vivement recommand\'e de lire le document qui figure dans l'annexe \ref{cha:conseils}.

%
\subsection{Conception d\'etaill\'ee et Planning pr\'evisionnel}
%
L'\'etape de conception d\'etaill\'ee fournit pour chaque composant (ou 
module) une description de la mani\`ere dont les fonctions du composant 
sont r\'ealis\'ees et une description pr\'ecise de la mani\`ere dont les autres modules
pourront interagir avec lui. Pour que vous puissiez travailler en parall\`ele sur plusieurs modules, il faut en effet
d\'efinir soigneusement pour chaque module les structures de donn\'ees et les fonctions dont les
autres modules auront besoin. C'est ce que l'on appelle l'interface logicielle.

C'est \`a  cette \'etape que vous devez d\'efinir et nommer les structures 
de donn\'ees qui seront utilis\'ees dans le programme. Pour les 
principales structures de donn\'ees vous devez donner une justification 
pr\'ecise des choix effectu\'es.

Lorsque le logiciel utilise des fichiers, c'est \`a  cette \'etape que 
vous devez d\'ecrire tr\`es pr\'ecis\'ement le format de ces fichiers. Il 
s'agit de donner tous les d\'etails n\'ecessaires afin que chaque module 
utilisant ces fichiers puisse \^etre programm\'e ind\'ependamment des 
autres.

Pour les modules les plus importants, vous devez de plus donner un
algorithme \emph{en fran\c{c}ais} (et non pas dans un langage de programmation).  
A cette \'etape, il ne s'agit pas de commencer la programmation,
mais seulement \emph{de pr\'eparer} le travail de programmation en
pr\'ecisant la mani\`ere dont les fonctionnalit\'es seront
r\'ealis\'ees.

Vous devez ensuite \'etablir un planning pr\'evisionnel indiquant
la liste des t\^aches \`a  r\'ealiser, la date et le d\'ebut de chaque t\^ache,
qui dans le groupe la r\'ealise, en veillant \`a  ce que l'encha\^{i}nement des t\^aches dans le
temps soit correct : il faut r\'ealiser d'abord les t\^aches n\'ecessaires \`a
la r\'ealisation d'autres t\^aches.  On ordonnera ou parall\'elisera en particulier les  t\^aches de programmation
des diff\'erents modules, mais il ne faudra pas oublier de lister aussi  les t\^aches
de documentation, d'apprentissage ou de recherche d'informations, ainsi 
que les t\^aches de r\'edaction ou de pr\'eparation de la d\'emonstration.
%
L'int\'egration des diff\'erents modules (par exemple l'int\'egration de l'interface graphique)
ou l'int\'egration d'un module de base de donn\'ees, r\'eserve souvent des surprises et
demande parfois des corrections. Il est donc important de r\'eserver aussi du temps pour
la phase d'int\'egration des diff\'erents modules.

Si vous en avez le temps, vous reprendrez le tableau de validation sugg\'er\'e \`a la fin de la section \ref{subsec:liste}, 
en pr\'esentant cette fois,
pour chaque module la liste des fonctionnalit\'es \`a  implanter, les
valeurs d'entr\'ees normales avec les r\'esultats attendus (jeu de test) en
pr\'ecisant les cas particuliers qui peuvent se pr\'esenter, et l'\'etat
actuel de la validation (pas fait~: les tests n'ont pas \'et\'e pass\'es ;
en cours~: les tests sont en cours, mais la mise au point n'est pas
termin\'ee, il reste des bogues ; OK~: les tests ont \'et\'e pass\'es avec
succ\`es).  La colonne ``validation" sera remplie au fur et \`a  mesure
de la mise au point, apr\`es le codage, et restera donc vide pour le
moment.
%
\section{Codage}
%
C'est seulement \`a  cette \'etape que commence la programmation. Si les 
\'etapes pr\'ec\'edentes ont \'et\'e pass\'ees correctement chaque module peut 
\^etre programm\'e ind\'ependamment des autres et le travail de 
programmation pourra \^etre r\'eparti entre les diff\'erents participants 
du projet. Cette phase de programmation doit suivre certaines r\`egles~:
\begin{itemize}
	\item se conformer strictement \`a  la description du module qui a
	\'et\'e faite lors de la conception d\'etaill\'ee (fonctionnalit\'es \`a
	r\'ealiser et interface avec le reste du logiciel)~: tout \'ecart \`a
	cette r\`egle peut remettre en cause la r\'ealisation de l'ensemble du
	projet et r\'eduire \`a  n\'eant tout le travail d\'ej\`a effectu\'e sur les
	autres modules.

	\item adopter des standards de programmation (cf.  annexe) pour le
	nommage des diff\'erents objets du langage (fichiers, type,
	variables, constantes, fonctions, proc\'edures...), pour l'\'ecriture
	des commentaires, pour la pr\'esentation du code (en particulier
	pour l'indentation), pour le traitement des erreurs (d\'etection
	syst\'ematique des erreurs pouvant \^etre caus\'ees par les appels
	syst\`emes, format des messages d'erreurs, ...).
\end{itemize}
%
\subsection*{Tests et mise au point}
%
Le programme est ex\'ecut\'e sur les donn\'ees de test et les r\'esultats 
obtenus sont compar\'es avec ceux attendus. Lorsque les r\'esultats 
obtenus diff\`erent des r\'esultats attendus, il faut corriger le 
programme et faire repasser tous les tests. La phase de tests est 
consid\'er\'ee comme termin\'ee lorsque la version d\'ebogu\'ee du logiciel 
passe tous les tests avec succ\`es.

%
% cette partie a t rdige intgralement par Catherine Recanati
\chapter{Conception de l'interface graphique}
\label{cha:conseils}

\section{Distinction Interface/Application}
Avant de r\'efl\'echir \`a la conception de l'interface, il convient de bien cerner cette notion. Pour l'organisation du code, on fait toujours, dit-on, une s\'eparation nette entre l'interface et l'application. La justification, outre la modularit\'e, est qu'il existe diff\'erents syst\`emes de fen\^etrages (Macintosh, X Window et Windows). L'application doit donc \^etre \'ecrite de mani\`ere ind\'ependante pour que seul le code de l'interface ait besoin d'\^etre r\'e\'ecrit s'il faut porter l'application dans un autre environnement.

La partie application, c'est le coeur du logiciel, ce \`a quoi il sert, ce qu'il permet de faire, sa ou ses fonctions principales. Les fonctionnalit\'es propos\'ees pour accomplir les t\^aches de l'utilisateur constituent finalement l'essentiel de l'application, et le travail de l'informaticien est d'abord de les d\'efinir, puis de les impl\'ementer. Mais il n'est pas toujours facile de les distinguer de l'interface. 
L'interface guide l'utilisateur dans la mise en oeuvre des fonctionnalit\'es pour l'aider \`a r\'ealiser sa t\^ache. L'interface ne consiste donc pas uniquement en un dispositif permettant la mise en oeuvre des fonctionnalit\'es. Des notions li\'ees \`a la t\^ache peuvent y appara\^itre. 

 La d\'efinition de l'interface passe par l'utilisation des dispositifs d'entr\'ees/sorties. Ainsi, les interfaces utilisateurs ne sont pas n\'ecessairement des interfaces graphiques utilisant un clavier et une souris. Les premiers ordinateurs avaient des interfaces non interactives, qui utilisaient des cartes perfor\'ees. Il y a trente ans, les logiciels n'utilisaient en g\'en\'eral qu'une entr\'ee (le clavier) et les sorties se faisaient (\`a l'\'ecran ou sur imprimante) sous forme d'impression de caract\`eres. Ces interfaces ont \'et\'e appel\'ees alpha-num\'eriques, car elles ne manipulaient que des nombres ou des caract\`eres.
 Aujourd'hui la plupart des interfaces sont dites graphiques, et elles impliquent un dispositif 
 d'entr\'ees/sortie de type \'ecran/clavier/souris. 

Le code de l'application est constitu\'e des structures repr\'esentant les objets du monde sur lequel porte l'application (les fichiers et les r\'epertoires pour un gestionnaire de fichiers, etc.), et des structures utilis\'ees pour organiser ces donn\'ees (structures d'attributs, listes, tables de hachages, BD, entit\'es plus abstraites comme des mod\`eles de donn\'ees, etc.). C'est un univers sur lequel on d\'efinit les op\'erations et transformations permettant d'impl\'ementer les fonctionnalit\'es du logiciel. 

La programmation objet vous permet de d\'ecrire facilement un univers d'objets (et vous donne divers avantages comme l'h\'eritage, l'encapsulation, l'abstraction sur les proc\'edures et les donn\'ees, etc.), mais si vous programmez dans un autre langage, vous faites tout de m\^eme la m\^eme chose : vous repr\'esentez le monde de l'application et vous d\'efinissez les structures de donn\'ees et les proc\'edures n\'ecessaires \`a la mise en oeuvre des fonctionnalit\'es du logiciel.

Le code de l'interface graphique repr\'esente un autre monde, celui des \'ecrans actuels. Ce monde est complexe mais tr\`es conventionnel et a pour but de g\'erer l'interaction avec l'utilisateur. Il est constitu\'e d'entit\'es comme les fen\^etres, les menus, les boutons, les ascenseurs, les bo\^ites de dialogues, etc., mais aussi d'entit\'es plus abstraites comme les gestionnaires d'affichage, les mod\`eles ou les vues d'objets complexes (par exemple mod\`eles et vues de tables ou de listes en Java). 
La structuration du code est impos\'ee par la biblioth\`eque graphique utilis\'ee. Si vous utilisez Java, vous ferez une mod\'elisation objet et suivrez le mod\`ele de programmation par \'ev\'enement bas\'e sur les \'ecouteurs (mod\`ele par d\'el\'egation). Avec les toolkits X11 ou les librairies graphiques, vous serez amen\'e \'egalement \`a suivre le mod\`ele de programmation pr\'econis\'e  par les concepteurs de la librairie (pour Xt, les Callbacks par exemple). 
Ces mod\`eles pr\'evoient plus ou moins bien la communication entre l'interface et l'application, et on aura parfois des probl\`emes d'int\'egration si les langages de programmation utilis\'es dans l'application et l'interface sont diff\'erents. 
Quoiqu'il en soit, en cas d'interface graphique, on pr\'evoira un module s\'epar\'e pour la programmation de l'interface.

\section{Conception de l'interface graphique} 
On dit toujours qu'une interface graphique doit \^etre claire, simple et facile d'emploi. Nous avons ici cherch\'e \`a isoler quelques r\`egles \`a suivre pour r\'ealiser cet objectif. La lecture de cette section vous permettra de focaliser sur les points importants \`a prendre en compte dans la sp\'ecification de vos \'ecrans - points qui vous sembleront peut-\^etre \'evidents, mais qui \'echappent pourtant souvent aux d\'ebutants.

\subsection{R\`egles de conception} 
Nous avons essay\'e de lister des r\'egles de conception d'une interface graphique assez g\'en\'erales. Dans les sections suivantes, nous en d\'evelopperons quelques unes.

\begin{description}
\item[R\`egle 1: D\'efinir les termes utilis\'es.]
Pour la clart\'e de l'interface, il faut utiliser la terminologie du domaine de l'application. Il faut fixer les termes apparaissant dans l'interface avec soin. Cette t\^ache prend du temps mais est tr\`es importante. Ces termes appara\^itront dans les titres, les menus et les cadres. On r\'eutilisera ensuite ces m\^emes termes dans la documentation utilisateur et si possible dans le code. Cela permettra une meilleure compr\'ehension pour l'utilisateur et le programmeur. 
\item[R\`egle 2: D\'efinir les ic\^ones et les symboles.] 
De m\^eme que les \'el\'ements textuels doivent \^etre pr\'ecis\'ement d\'efinis, les ic\^ones, symboles et autres objets graphiques apparaissant dans l'interface doivent \^etre choisis avec soin et en accord avec les futurs utilisateurs.
\item[R\`egle 3: S'inspirer des interfaces existantes.] L'interface Macintosh a \'et\'e inspir\'ee par celle d'une machine graphique initialement con\c{c}ue par Rank Xerox. Elle aura elle m\^eme beaucoup inspir\'e Windows. Aujourd'hui, il y a une certaine standardisation qui s'effectue entre les diff\'erents syst\`emes, et des conventions s'instaurent \`a partir du moment o\`u elles sont reprises par plusieurs grands logiciels.
\item[R\`egle 4: S'appuyer sur les standards.] Pour que l'interface soit simple et claire, utilisez des conventions d\'ej\`a connues de l'utilisateur. On proc\`edera ainsi pour le choix de certains termes figurant dans les menus, le choix des ic\^ones,  et pour la disposition g\'en\'erale des fen\^etres et des objets graphiques. 
On utilisera aussi les bo\^ites pr\'ed\'efinies comme les s\'electeurs de fichiers ou les bo\^ites de dialogue standards.
\item[R\`egle 5: Concevoir l'interface pour le novice et pour l'expert.] En fait, il faut distinguer plusieurs types d'utilisateurs, car on peut \^etre novice ou expert de la t\^ache, et novice ou expert de l'application.
Pour le novice de l'application, le parcours de la barre de menu devra donner un panorama des possibilit\'es du logiciel. Pour l'expert de l'application, on offrira des raccourcis claviers et des barres d'ic\^ones, ou d'autres moyens (menus courts/menus longs, possibilit\'es de configuration de l'interface).
\item[R\`egle 6: Guider l'utilisateur.] L'utilisateur doit \`a chaque instant savoir ce qu'il est en train de faire (s'il vient de lancer une commande, si cette commande est en cours ou termin\'ee, etc.) et pouvoir visualiser les r\'esultats de ses commandes. On parle ici de \emph{feed-back} (retour) utilisateur.
Pour r\'ealiser ce \emph{feed-back}, on peut utiliser toutes sortes de moyens : des clignotements, des gris\'es, des animations, l'entra\^inement des ic\^ones \`a l'\'ecran, le trac\'e de rectangles pointill\'es pour s\'electionner des zones, la s\'election d'objets par de l'inverse vid\'eo (ou faire appara\^itre des poign\'ees), des curseurs ou pointeurs particuliers (montres, etc.), des barres de d\'efilement pour montrer l'\'ecoulement du temps, etc. 
Il est important \'egalement que l'utilisateur puisse visualiser l'effet de ses commandes (mises \`a jour de vues, fen\^etres de statuts ou de messages). 
L'utilisateur doit \'egalement savoir \`a chaque instant ce qu'il peut faire. On veillera \`a griser les commandes inaccessibles (textes ou ic\^ones), indiquer par un beep sonore les actions interdites (textes non \'editables), souligner \`a l'aide d'ic\^ones l'\'etat d'un document \'edit\'e (sauvegard\'e, modifi\'e), etc. 
Pour expliquer l'invalidation d'une commande, on affichera des messages d'erreurs. Ces messages appara\^itront dans des bo\^ites au centre de l'\'ecran ou dans une petite fen\^etre sp\'ecialis\'ee (par exemple en bas de la fen\^etre principale). Pour les bo\^ites de messages, on utilisera dans la mesure du possible les bo\^ites de dialogue toutes pr\^etes fournies par la biblioth\`eque utilis\'ee.
\item[R\`egle 7: Donner le contr\^ole \`a l'utilisateur.] L'utilisateur doit toujours avoir la main. S'il lance une t\^ache, il doit aussi pouvoir l'interrompre. Un bouton Annuler d'une bo\^ite de lancement inutilisable quand le curseur de souris est un sablier a de quoi l'\'enerver \`a juste titre. 
Il faut \'egalement veiller \`a ce que les actions explicites, comme la demande d'une sauvegarde, soient effectives (par exemple, pas de sauvegarde en m\'emoire locale pour optimiser le programme).
Il est \'egalement souhaitable que l'utilisateur puisse revenir en arri\`ere, et annuler l'effet de sa derni\`ere commande.
\item[R\`egle 8: G\'erer les erreurs.] Il faut pr\'evoir une gestion des erreurs concernant la saisie de donn\'ees, avec \'eventuellement des corrections automatiques, ou des valeurs par d\'efaut. 
\item[R\`egle 9  Soigner la mise en page.] Nous d\'evelopperons quelques id\'ees sur la mise en page dans les paragraphes suivants. Mais il n'est pas toujours \'evident d'analyser pourquoi une interface est belle et pourquoi une autre ne l'est pas.
\item[R\`egle 10: Regrouper spatialement les \'el\'ements.] La clart\'e de l'interface provient en grande partie de la disposition g\'eom\'etrique des \'el\'ements. 
Le regroupement d'objets dans des zones sp\'ecifiques doit correspondre \`a un regroupement conceptuel. Cette r\`egle est fondamentale. Elle s'applique partout dans l'interface : dans les barres de menus, dans les barres d'ic\^ones, dans l'organisation de l'interface principale et des bo\^ites de dialogue. On regroupe ensemble les commandes correspondant \`a un groupe de fonctionnalit\'es (portant par exemple sur des objets de m\^eme type), et l'on regroupe ensemble les objets de l'interface permettant la mise en oeuvre d'une m\^eme fonctionnalit\'e (par exemple les boutons sur lesquels ils d\'eclenchent des actions).
%\item[R\`egle 11: Distinguer et grouper les \'el\'ements par la forme.] Le groupement d'objets peut aussi s'effectuer par le fait qu'ils prennent la m\^eme forme graphique. Combin\'e avec la r\`egle pr\'ec\'edente, on pourra avoir la m\^eme forme au m\^eme endroit, mais on peut \'egalement avoir une forme identique dans des endroits diff\'erents. C'est la forme en effet qui permet de distinguer les \'el\'ements (fontes grasses, italiques, ic\^ones sp\'ecifiques, couleurs, etc.) et qui permettra de regrouper s\'emantiquement les \'el\'ements par types.
\item[R\`egle 11: Veiller \`a la coh\'erence.] Par exemple, si vous avez plusieurs fa\c{c}ons de d\'eclancher une commande, la proc\'edure d\'eclanch\'ee doit \^etre exactement la m\^eme. (\c{c}a vous \'evite aussi de dupliquer le code). En Java, on pourra utiliser les Actions pour d\'eclencher les m\^emes commandes dans la barre d'ic\^ones et dans la barre de menu. 
Il faut \'egalement avoir une utilisation coh\'erente des fontes et des couleurs. Pour que la documentation soit correcte, il faudra \'egalement utiliser les termes apparaissant dans l'interface de mani\`ere coh\'erente avec le manuel utilisateur, et si possible, retrouver ces m\^emes termes dans le code.
\end{description}
Nous allons pour finir indiquer comment appliquer certaines de ces r\`egles.
\subsection{D\'efinir les termes utilis\'es}
Dans les barres de menus, on unifiera la syntaxe des termes utilis\'es : soit tout nominal, soit tout verbal. Cette remarque s'applique aussi aux titres des bo\^ites de dialogues. N'h\'esitez pas non plus \`a pr\'eciser un terme par un compl\'ement ou un adjectif. 
Le titre d'un menu doit recouvrir s\'emantiquement les diff\'erents items du menu. C'est un titre de rubrique. 
On veillera \'egalement \`a ne pas m\'elanger le fran\c{c}ais et l'anglais. Pr\'evoir si vous avez le temps deux versions, en utilisant des tables pour les termes et les messages d'erreurs. Une fois fix\'ee la terminologie, on \'evitera l'utilisation de synonymes dans la documentation. Par exemple, si on utilise le terme Couper dans un menu, on gardera ce terme partout, et on \'evitera les synonymes comme Supprimer, Effacer, etc. Cela \'evite des ambigut\'es et supprime le risque d'incoh\'erences.
\subsection{Soigner la mise en page}
Utilisez a priori une disposition standard : une fen\^etre principale  avec en haut une barre de menu et une barre d'ic\^ones ; en bas, un ascenseur \'eventuel et/ou une petite fen\^etre pour les messages; \`a droite, un ascenseur.

Mais il y a d'autres dispositions possibles. En particulier, les fen\^etres \`a panneaux multiples (r\'eajustables par l'utilisateur), ou des fen\^etres \`a onglets (faciles \`a impl\'ementer en Java). 
On peut \'egalement choisir de d\'emarrer le logiciel avec une barre d'ic\^ones au lieu d'une fen\^etre principale. Cette solution est pr\'econis\'ee quand le logiciel est complexe et poss\`ede de nombreux types de fen\^etres.
\subsubsection{Faciliter la navigation}
L'utilisateur doit pouvoir se rep\'erer dans les diff\'erents \'ecrans du logiciel. Savoir o\`u il en est dans sa t\^ache, ce qu'il est en train de faire et comment revenir \`a une \'etape ant\'erieure. Si votre disposition est standard, le probl\`eme ne se pose pas vraiment. Mais si vous devez afficher de nombreuses fen\^etres, vous devez organiser la coh\'erence graphique de vos fen\^etres et la navigation entre les fen\^etres. Vous avez plusieurs solutions classiques :
\begin{itemize}
\item Utiliser des fen\^etres \`a onglets.
\item Utiliser une vue des fen\^etres permettant de naviguer entre elles. Cette vue peut se pr\'esenter comme une liste de boutons repr\'esentant les fen\^etres, comme une fen\^etre menu, ou comme un arbre si l'organisation du logiciel s'y pr\^ete. 
\item Utiliser les menus Modes ou Fen\^etres de la barre de menu.
\end{itemize}

\subsubsection{Cr\'eer des zones et les nommer}
Mettez des titres bien pens\'es aux fen\^etres. En particulier, donnez toujours un titre aux bo\^ites de dialogue.
Groupez les \'el\'ements op\'erant sur des objets de m\^eme type (ou concernant un m\^eme groupe de fonctionnalit\'es) dans une m\^eme r\'egion. Proc\'edez ainsi dans les bo\^ites de dialogue, mais aussi dans les barres de menus, les menus, les barres d'ic\^ones, et utilisez des s\'eparateurs ou des cadres titr\'es pour faire ressortir ce d\'ecoupage. 
\subsubsection{Organiser les bo\^ites de dialogues}
 Encadrez et donnez des titres aux diff\'erentes zones d'une bo\^ite de dialogue complexe. Pour cela utilisez des cadres (ou bords avec titre en Java). N'h\'esitez pas \`a ce qu'il y ait une certaine redondance entre les titres des zones et les labels utilis\'es dans la bo\^ite. Vous pouvez \'egalement scinder l'espace de la fen\^etre horizontalement (avec des s\'eparateurs ou des panneaux r\'eajustables) pour s\'eparer les zones groupant des fonctionnalit\'es diff\'erentes.
Ainsi, si l'on veut organiser la sp\'ecification de certains param\`etres, on les pr\'esentera par exemple sous forme de cases \`a cocher ou de champs \'etiquet\'es dans une m\^eme zone de la bo\^ite avec un titre rappelant la fonctionnalit\'e mise en oeuvre (par exemple, le titre Param\`etres). On n'oubliera pas \'egalement de donner un titre g\'en\'eral \`a la bo\^ite (comme Sp\'ecifier les param\`etres).
Les boutons qui apparaissent habituellement dans les bo\^ites sont les boutons Ok, Annuler, Valider, Appliquer, Enregistrer, et Aide. Notez qu'il y a des emplacements standards pour ces boutons.

~
Les boutons doivent \^etre plac\'es de sorte qu'on voit imm\'ediatement ce sur quoi ils portent. L'encadrement des zones permet de d\'elimiter la port\'ee des actions sur ces boutons. Ainsi, le bouton Supprimer situ\'e pr\`es d'une liste dans une zone encadr\'ee contenant la liste portera naturellement sur les items s\'electionn\'es de la liste. 

Un dernier point sur les bo\^ites : il ne faut pas qu'il y ait trop d'encha\^inements de bo\^ites, car cela ennuie l'utilisateur (le cot d'accessibilit\'e est trop \'elev\'e). Si l'utilisateur doit configurer beaucoup d'\'el\'ements, pensez plut\^ot \`a des bo\^ites complexes, ou revoyez la fa\c{c}on dont vous organisez l'acc\`es aux fonctionnalit\'es du logiciel.


\subsubsection{R\`egles de mise en page :}
\begin{description}
\item[Aligner les objets.]
Par exemple, on alignera les bords gauches des labels \'etiquetant des champs textuels. 
\item[Laisser des marges suffisantes.]
Ne collez pas vos \'etiquettes ou vos champs de textes aux bords des zones qui les contiennent. 
\item[Eviter les espaces vides.]
Cette r\`egle s'applique \`a la conception des bo\^ites de dialogue. Une zone de travail vide n'est, bien entendu, pas g\^enante.
\item[Minimiser le nombre de lignes verticales.]
Par lignes verticales, j'entends les lignes virtuelles qui apparaissent quand on aligne verticalement les bords gauche ou droit  d'un groupe d'objets. Ces objets sont alors align\'es sur une ligne (virtuelle) verticale que l'oeil per\c{c}oit. Cette ligne prend appui sur les bords align\'es des objets. Ainsi, dans l'exemple pr\'ec\'edent, si on aligne les bords gauches des labels et les bords gauches des champs de texte situ\'es en vis-\`a-vis, on fera appara\^itre deux lignes verticales . Ne pas multiplier ces lignes consistera ici \`a aligner \'egalement d'autres objets de la m\^eme fen\^etre sur ces lignes, comme par exemple, des boutons situ\'es en dessous, ou le bord d'une zone encadr\'ee situ\'ee plus bas dans la bo\^ite. Cela revient \`a aligner les diff\'erents objets Ð parfois m\^eme au-del\`a des s\'eparateurs de zones. 
\item[Placer toujours les m\^emes choses aux m\^emes endroits.]
C'est pour cela que l'on a choisi de griser les commandes inaccessibles dans les menus, plut\^ot que de les faire dispara\^itre dynamiquement, car les items ne se seraient pas trouv\'es toujours \`a la m\^eme place dans le menu et cela aurait perturb\'e l'utilisateur.
Dans cet esprit, uniformisez la mise en page des diff\'erentes bo\^ites ou fen\^etres en pla\c{c}ant les boutons, titres, etc. aux m\^emes endroits. 
Adoptez un certain point de vue sur la mani\`ere dont l'utilisateur doit par exemple configurer des param\`etres et maintenez une certaine coh\'erence entre vos bo\^ites. En particulier, n'h\'esitez pas dans le code \`a utiliser les m\^emes panneaux si vos bo\^ites ont des parties communes.
\end{description}
\subsection{Coh\'erence des fontes et des couleurs}
Les fontes doivent normalement \^etre sp\'ecifi\'ees par l'utilisateur. Mais vous pouvez permettre \`a l'utilisateur de choisir sa fonte, et r\'eserver l'italique ou le gras de la m\^eme fonte pour un usage particulier.

N\'eanmoins, il doit y avoir une coh\'erence dans l'usage des fontes de votre logiciel. On donnera un sens \`a leur usage. Par exemple, on pourra utiliser une fonte particuli\`ere pour les items de menu et faire appara\^itre le titre du menu dans une autre fonte (par exemple, en gras). 

Surtout, ne pas multiplier les fontes. Si vous voulez plusieurs fontes, utilisez la m\^eme fonte dans diff\'erentes tailles, avec \'eventuellement du gras ou de l'italique. Car, outre l'effet g\'en\'eral de confusion, rien n'est plus laid qu'un m\'elange de fontes.

Les couleurs de la m\^eme fa\c{c}on devront \^etre utilis\'ees de mani\`ere coh\'erente. On donnera un sens \`a l'usage d'une couleur. Par exemple, on pourra mettre en relief les lignes d'erreur dans un \'editeur de programmes en leur affectant une certaine couleur, une autre \'etant r\'eserv\'ee aux mots cl\'es. 

Le choix des couleurs est suppos\'e aussi \^etre du ressort de l'utilisateur. Vous pouvez cependant fixer l'usage d'une couleur, et laisser l'utilisateur choisir cette couleur. Il faudra cependant veiller dans certains cas \`a ce que les couleurs choisies, en particulier pour des couleurs de fonte et d'arri\`ere plan, aient un contraste suffisant. Le contraste id\'eal est celui du blanc et du noir. Si l'on veut mettre de la couleur, on peut utiliser une couleur claire \`a la place du blanc et \'ecrire en noir, ou \`a l'inverse, prendre une couleur fonc\'ee pour le fond et \'ecrire en blanc. 

%
\chapter{Le m\'emoire du projet}
\label{cha:le-memoire-de}
%
Lors de la r\'ealisation du projet, chaque \'etape a donn\'e lieu \`a  la
r\'edaction de documents.  Ces diff\'erents documents ont du \^etre r\'evis\'es
au fur et \`a  mesure que la r\'ealisation avan\c{c}ait.  Le document final du
projet reprend l'essentiel de ces documents dans leur version finale, y ajoute certaines
informations compl\'ementaires, un manuel utilisateur et un manuel d'installation.
%
\section{Pr\'esentation}
%
Sa pr\'esentation est la m\^eme que tous les documents interm\'ediaires.  Le
m\'emoire doit \^etre tap\'e \`a  l'aide d'un traitement de texte.  Il doit
comporter une premi\`ere page avec~:

\begin{itemize}
	\item un titre (mentionnant le sujet trait\'e)
	
	\item le nom de(s) (l')auteur(s) et leur(s) courrier(s) \'electronique(s)
	
	\item la formation et l'ann\'ee
	
	\item le nom des enseignanst encadrants auquel le document est destin\'e
	
	\item la date \`a  laquelle cette version du m\'emoire a \'et\'e termin\'ee ou un num\'ero de version

\end{itemize}

Toutes les pages doivent \^etre num\'erot\'ees et le m\'emoire doit comporter 
une table des mati\`eres.

%
\section{Plan du m\'emoire}
%
Le m\'emoire proprement dit doit comporter les chapitres suivants :

\begin{enumerate}

\sloppy


	\item L'\'enonc\'e du probl\`eme  et son analyse approfondie, afin de
	d\'ecrire enti\`erement le projet \`a  r\'ealiser.  Les probl\`emes
	(th\'eoriques ou pratiques) sous-jacents \`a  l'\'enonc\'e, la liste des
	fonctionnalit\'es demand\'ees ou n\'ecessaires, les contraintes
	explicites ou non, l'environnement mat\'eriel et logiciel du projet,
	doivent \^etre d\'etaill\'es ; les choix effectu\'es doivent \^etre
	pr\'esent\'es avec leur justification.

\fussy

	\item La conception architecturale du logiciel, afin de d\'efinir
	les constituants du logiciel.  Le projet est d\'ecoup\'e en modules,
	chaque module regroupe des proc\'edures ou fonctions.  Cette partie
	du document comprend l'architecture logicielle (la d\'ecoupe en
	modules et le graphe de d\'ependances).

	\item La conception d\'etaill\'ee :
	\begin{itemize}
		\item les param\`etres et variables principaux, qui sont nomm\'es et d\'ecrits,
		
		\item la liste des en-t\^etes de proc\'edures ou fonctions class\'es
		par module puis ordre alphab\'etique,

		\item la liste des donn\'ees partag\'ees et leur structure
		class\'ees par ordre alphab\'etique,

		\item la liste des fichiers comportant les donn\'ees ou les
		programmes avec leur structure,

		\item l'esquisse des algorithmes cruciaux.
	\end{itemize}
%	Pour chaque objet, ajouter un commentaire le d\'ecrivant et la page
%	o\`u il est d\'eclar\'e dans le code.  Pr\'eciser \'eventuellement \`a  quoi il
%	sert et dans quels modules, proc\'edures ou fonctions il est
%	utilis\'e,

% 	\item Le code comment\'e avec pages num\'erot\'ees ; les commentaires
% 	peuvent comporter des renvois aux pages des chapitres d'analyse et
% 	de conception.

	\item Un manuel utilisateur en deux parties : 
	\begin{itemize}
		\item le manuel d'installation, qui donne :
		\begin{itemize}
			\item la liste des fichiers n\'ecessaires pour ex\'ecuter le
			logiciel (librairies, utilitaires, programme source,
			ex\'ecutable) en les commentant ; ne pas oublier de pr\'eciser
			les num\'eros de version de syst\`eme ou de compilateur ; tout
			l'environnement n\'ecessaire \`a  l'ex\'ecution doit \^etre d\'ecrit (on fournira \'eventuellement les adresses internet o\`u les trouver);

			\item les fichiers constituant le logiciel et la fa\c{c}on de
			les installer sur sa machine. (On donnera par exemple un fichier makefile et on dira pr\'ecis\'ement quelles commandes taper pour l'ex\'ecuter).
		\end{itemize}
		\item le manuel utilisateur proprement dit, qui d\'ecrira :
		\begin{itemize}
			\item comment lancer le logiciel ;

			\item comment l'utiliser : quelles sont les
			fonctionnalit\'es possibles, quelles contraintes doivent
			\^etre respect\'ees, comment se d\'eroule le dialogue
			utilisateur-logiciel (\'eventuellement, donner les \'ecrans de
			l'interface utilisateur), que se passe-t-il en cas
			d'erreur (liste des messages d'erreur), comment quitter le
			logiciel (proc\'edure normale et en cas d'erreur). Une bonne mani\ere
			de proc\'eder pour cela est de faire un premier chap\^itre pr\'esentant une session
			typique d'un utilisateur, puis de d\'ecrire explicitement ensuite toutes les
			fonctionnalit\'es possibles du logiciel dans les chap\^itres suivants.
		\end{itemize}
	\end{itemize}
	\item Le planning pr\'evisionnel remis avec la conception d\'etaill\'ee
	et le planning r\'eel,
	
	\item Le tableau de validation compl\'et\'e,

	\item Le cas \'ech\'eant, les fichiers de donn\'ees avec lesquels vous
	avez test\'e votre logiciel ;

	\item Une liste de r\'ef\'erences bibliographiques et de sites internet consult\'es.  Les r\'ef\'erences bibliographiques
	sont les ouvrages (livres, articles, ...)  que vous avez utilis\'es
	pour l'analyse du probl\`eme  et la r\'ealisation de votre projet.  Ne
	faites appara\^{i}tre que les ouvrages que vous avez directement
	consult\'es.  De m\^eme, ne mentionnez que les sites qui vous ont \'et\'e utiles.
	% Une liste de r\'ef\'erences est une source d'information :
	% elle doit \^etre pr\'ecise et concise.
\end{enumerate}

L'ensemble de la documentation devra \^etre rendu par mail, au format pdf,
avec un fichier d'archive pour le code (format zip ou tar.gz uniquement).
%
\chapter{\'Evaluation du projet}
\label{cha:evaluation-du-projet}
%
L'\'evaluation du projet sera faite au vu de :
\begin{itemize}
	\item la qualit\'e technique de la r\'ealisation (en particulier
	l'ad\'equation du logiciel au probl\`eme  pos\'e, les fonctionnalit\'es propos\'ees et l'interface utilisateur)
	\item la qualit\'e du m\'emoire (pr\'esentation et contenu, corrections effectu\'ees apr\`es les remarques des encadrants) 
	
	\item la pr\'esentation orale
	\item la qualit\'e de la d\'emonstration du logiciel

        \item l'organisation du travail en groupe.

\end{itemize}
%

\section*{La pr\'esentation orale}
Vous devez pr\'esenter un bilan du projet dans une pr\'esentation PowerPoint (ou un fichier
de transparents au format pdf). Cette pr\'esentation peut \^etre collective et vous vous passerez alors tour-\`a-tour la parole. Vous commencerez bien s\^ur par pr\'esenter le sujet. Vous pouvez ensuite reprendre des sp\'ecifications du premier rapport comme la liste des fonctionnalit\'es propos\'ees ou des sch\'emas de sp\'ecifications fonctionnelles, ainsi que l'architecture globale du logiciel (par exemple le diagramme de d\'ependances entre les modules). Faites ensuite un bilan en indiquant bri\`evement ce qui a \'et\'e finalement d\'evelopp\'e (mais ne d\'eveloppez pas plus la pr\'esentation du logiciel car ce sera fait dans la d\'emonstration de l'apr\`es-midi). 

Vous pouvez aussi parler de l'organisation du travail (r\'epartition et planning). Enfin, vous pouvez indiquer les probl\`emes rencontr\'es et dire comment ils ont pu \^etre r\'esolus pour mettre en avant votre travail, et indiquer les possibilit\'es d'am\'elioration du logiciel. Vous conclurez par un bilan (collectif ou individuel) sur ce que vous aura apport\'e le projet sur le plan technique et humain.

\section*{La d\'emonstration du logiciel}
%
C'est lors de la d\'emonstration que la qualit\'e technique de la 
r\'ealisation sera \'evalu\'ee. Il faut donc pr\'eparer et r\'ep\'eter la d\'emonstration soigneusement.\\



Pour cela :
\begin{enumerate}
	\item d\'efinir des objectifs : ce que l'on veut montrer (si le code n'est pas compl\`etement int\'egr\'e vous pouvez pr\'evoir de montrer le fonctionnement de fonctions isol\'ees) 
	
	\item pr\'eparer un sc\'enario d'utilisation permettant de satisfaire
	ces objectifs ; cela peut n\'ecessiter l'utilisation de fichiers pr\'epar\'es d'avance

	\item r\'ep\'eter et minuter votre d\'emonstration en situation r\'eelle,
	c'est-\`a-dire dans la configuration mat\'erielle et logicielle qui
	sera celle de la v\'eritable d\'emonstration (en particulier, si vous
	avez r\'ealis\'e le projet chez vous, il est tr\`es probable que vous
	devrez y apporter des modifications pour qu'il fonctionne
	correctement \`a  l'Institut Galil\'ee) et pr\'eparer vos commentaires
	oraux
\end{enumerate}

Vous devez mettre en valeur ce que vous avez fait, et, seulement \`a  la
fin, expliquer les erreurs r\'esiduelles et les fonctionnalit\'es non
op\'erationnelles.  Les probl\`emes de gestion de groupe que vous pouvez
avoir rencontr\'es ne doivent pas appara\^{i}tre lors de la d\'emonstration
(ils doivent avoir \'et\'e \'evoqu\'es bien avant, au moment o\`u ils se sont
produits, avec votre enseignant).
%
%
%\appendix

\chapter{Standards de programmation de GNU}
\label{cha:stand-de-progr}
%

Traduction partielle des ``GNU Coding Standards" r\'edig\'es par
Richard Stallman et disponible \'e
\url{http://gnu.via.ecp.fr/prep/standards_toc.html}

\section{Comportement commun \`a  tous les programmes}

Ce chapitre d\'ecrit comment \'ecrire des logiciels robustes.  Il d\'ecrit
aussi des standards g\'en\'eraux pour les messages d'erreur, l'interface
ligne de commande, et la mani\`ere dont les biblioth\'eques de fonctions
doivent se comporter.
%
\subsection{Ecrire des programmes robustes}
%
Evitez les limites arbitraires sur la taille des structures de donn\'ees, y 
compris la taille des noms de fichiers, des lignes, des fichiers et des 
symboles. Pour cela, utilisez l'allocation dynamique pour toutes les 
structures de donn\'ees. Dans la plupart des utilitaires Unix, les lignes 
longues sont tronqu\'ees sans avertissement. Ce n'est pas toutefois pas acceptable.

Les utilitaires lisant des fichiers ne doivent pas \'eliminer les
caract\'eres NUL ou tout autre caract\`ere, \emph{y compris ceux dont le
code est inf\'erieur \`a  0177}.  Les seules exceptions admises concernent
les utilitaires qui sont destin\'es sp\'ecifiquement \`a  servir d'interface
\`a certains types d'imprimantes qui ne peuvent pas g\'erer ces
caract\`eres.

Testez toujours le code d'erreur renvoy\'e par un appel syst\`eme.  Tout
message d'erreur r\'esultant de l'\'echec d'un appel syst\`eme doit contenir
le texte de l'erreur syst\`eme (obtenu \`a  l'aide de \texttt{perror} ou
d'un \'equivalent) ainsi que le nom du programme dont l'appel syst\`eme
est issu et, le cas \'ech\'eant, le nom du fichier.  Afficher seulement ``\texttt{cannot open foo.c}" ou ``\texttt{stat failed}" n'est pas
suffisant.

Testez tout appel \`a  \texttt{malloc} ou \texttt{realloc} pour voir
s'il renvoie z\'ero.  Testez \texttt{realloc} m\^eme si vous diminuez la
taille du bloc ; avec un syst\`eme qui arrondit les tailles de bloc \`a  une
puissance de 2, \texttt{realloc} peut rendre un bloc diff\'erent si vous
demandez moins d'espace m\'emoire.

Sous Unix, \texttt{realloc} peut d\'etruire le bloc m\'emoire s'il renvoie
z\'ero.  Le \texttt{realloc} de GNU ne pr\'esente pas cette bogue : s'il
\'echoue, le bloc original est inchang\'e.  Vous pouvez faire l'hypoth\'ese
que cette bogue a \'et\'e corrig\'ee.  Si vous d\'esirez ex\'ecuter votre
programme sous Unix, et souhaitez \'eviter tout probl\`eme  dans ce cas,
vous pouvez utiliser le \texttt{malloc} de GNU.

Vous devez vous attendre \`a  ce que \texttt{free} modifie le contenu du
bloc qui a \'et\'e lib\'er\'e.  Tout ce que vous devez r\'ecup\'erer de ce bloc,
doit \^etre r\'ecup\'er\'e avant d'appeller \texttt{free}.

Si \texttt{malloc} \'echoue dans un programme non interactif, faites-en
une erreur fatale (i.e. avec terminaison imm\'ediate de l'ex\'ecution du
programme).  Pour un programme interactif (un programme qui lit des
commandes de l'utilisateur), il est pr\'ef\'erable de faire terminer la
commande pr\'ematur\'ement et de retourner \`a  la boucle de lecture de
commande.  Cela permet \`a  l'utilisateur de tuer d'autres processus pour
lib\'erer de la m\'emoire virtuelle et de r\'eessayer la commande apr\'es.

Utilisez \texttt{getopt\_long} pour d\'ecoder les arguments, \`a  moins que la syntaxe 
des arguments en rende l'utilisation d\'eraisonnable.

Quand de la m\'emoire statique (\texttt{static}) doit \^etre modifi\'ee lors de 
l'ex\'ecution d'un programme, utilisez du code C explicite pour 
l'initialiser. R\'eservez le m\'ecanisme d'initialisation \`a  la d\'eclaration de 
C pour les donn\'ees qui ne changeront pas.

Essayez d'\'eviter les r\'ef\'erences \`a  des structures de donn\'ees de bas
niveau de Unix (telles que r\'epertoires, \texttt{utmp} ou disposition
de la m\'emoire du noyau Unix), car il est peut probable que ce soit
compatible avec d'autres implantations d'Unix.  A titre d'exemple, si
vous avez besoin des noms de tous les fichiers d'un r\'epertoire,
utilisez \texttt{readdir} ou toute autre interface de haut niveau. 
Dans ce cas la compatibilit\'e sera assur\'ee par GNU.

Dans les tests d'erreurs qui d\'etecte des conditions ``impossibles", 
contentez vous de faire terminer le programme pr\'ematur\'ement. En g\'en\'eral, 
cela ne sert \`a  rien d'afficher quelque message que ce soit. Ces tests 
indiquent la pr\'esence de bogues. Qui que ce soit voulant corriger ces 
bogues devra lire le code source et utiliser un d\'ebogueur. Expliquez donc 
l'erreur \`a  l'aide de commentaires dans le code source. Les donn\'ees 
int\'eressantes seront dans des variables qui pourront \^etre examin\'ees 
facilement avec le d\'ebogueur.

N'utilisez pas un compteur d'erreurs comme code de retour d'un programme. 
\emph{Cela ne marche pas} car les valeurs de code de retour des programmes sont 
limit\'ees \`a  une repr\'esentation sur 8 bits (valeurs de 0 \`a  255). Il est 
possible qu'une seule ex\'ecution d'un programme produise 256 erreurs ; si 
vous essayez de renvoyer 256 comme code de retour, le processus p\`ere verra 
un code de retour \'egal \`a  0, et il supposera que le programme a r\'eussi.
Si vous cr\'eez des fichiers temporaires, testez la variable d'environnement 
\texttt{TMPDIR} ; si cette variable est d\'efinie, utilisez le r\'epertoire sp\'ecifi\'e \`a  
la place de \texttt{/tmp}.
%
\subsection{Biblioth\`eques de fonctions}

\sloppy

Voici maintenant quelques conventions de nommage concernant les 
biblioth\`eques de fonctions, afin d'\'eviter les conflits de nom.

\fussy

Choisissez pour chaque biblioth\`eque un pr\'efixe de plus de deux caract\'eres. 
Tout nom de fonction ou variable externe doit commencer par ce pr\'efixe. De 
plus, chaque membre de la biblioth\'eque ne doit contenir qu'un symbole 
externe. Cela signifie habituellement que chacun doit \^etre plac\'ee dans un 
fichier source distinct.

Une exception peut-\^etre faite lorsque deux symboles externes sont toujours 
utilis\'es ensemble de sorte qu'aucun programme raisonnable n'en utiliserait 
un sans utiliser l'autre ; dans ce cas, ils peuvent aller tous les deux 
dans le m\^eme fichier.

Les symboles externes qui ne sont pas des points d'entr\'ee document\'es pour 
l'utilisateur (et ne lui sont donc pas destin\'es) doivent avoir des noms 
commen\c{c}ant par '\texttt{\_}'. Ils doivent eux aussi contenir le pr\'efixe choisi pour 
la biblioth\`eque afin de pr\'evenir des conflits avec d'autres biblioth\`eques. 
Ils peuvent \^etre plac\'es dans les m\^emes fichiers avec des points d'entr\'ee 
pour l'utilisateur.
%
\subsection{Formattage des messages d'erreur}
%
Les messages d'erreurs des programmes non interactifs doivent ressembler \`a  
cela :

\emph{programme}:\emph{nom-fichier-source}:\emph{num-ligne}: \emph{message}

quand il existe un nom de fichier source appropri\'e, ou \`a  cela :

\emph{programme}: \emph{message}

quand il n'y a pas de fichier source pertinent.

Pour un programme interactif (un programme qui lit des commandes d'un 
terminal), il est pr\'ef\'erable de ne pas inclure le nom du programme dans le 
message d'erreur. L'endroit ad\'equat pour indiquer quel programme 
s'ex\'ecute, est l'invite (prompt) ou un emplacement sp\'ecifiquement r\'eserv\'e 
dans l'agencement de l'\'ecran. (Quand le m\^eme programme s'ex\'ecute en 
prenant son entr\'ee \`a  une autre source qu'un terminal, il n'est pas 
interactif et devra donc \'ecrire les messages d'erreur dans le style non 
interactif).

La cha\^{i}ne de caract\'eres message ne doit pas commencer par une majuscule 
quand elle suit un nom de programme ou de fichier. En outre, elle ne doit 
pas se terminer par un point.

Les messages d'erreur des programmes interactifs ainsi que les autres 
messages comme les messages d'utilisation (usage), doivent commencer par 
une majuscule mais ne doivent pas se terminer par un point.
%
\subsection{Standards pour l'interface ligne de commande}
%
Faites en sorte que le comportement d'un logiciel ne d\'epende pas du nom 
utilis\'e pour lancer la commande. Il est parfois utile de faire un lien 
vers un logiciel en utilisant un nom diff\'erent, et cela ne doit pas 
modifier ce qu'il fait.

Au lieu de cela, utilisez des options d'ex\'ecution ou des options de 
compilation ou bien les deux pour s\'electionnez parmi les diff\'erents 
comportements alternatifs.

De la m\^eme fa\c{c}on, ne rendez pas le comportement d'un programme
d\'ependant du type de p\'eriph\'erique de sortie avec lequel il est
utilis\'e.  L'ind\'ependance par rapport aux p\'eriph\'eriques est un principe
important de conception des syst\`emes ; ne le compromettez pas dans le
seul but d'\'eviter \`a  quelqu'un de taper une option par ci par l\`a.

Si vous pensez qu'un comportement est plus ad\'equat quand la sortie est 
dirig\'ee vers un terminal, et qu'un autre est plus pertinent lorsque la 
sortie est dirig\'ee vers un fichier ou un tube (pipe), alors, 
habituellement, le mieux est de choisir comme comportement par d\'efaut 
celui qui est le plus pertinent avec un terminal de sortie et de proposer 
une option pour l'autre comportement.

La compatibilit\'e n\'ecessite que certains programmes soient d\'ependants du
type de p\'eriph\'erique de sortie.  Il serait d\'esastreux que \texttt{ls}
ou \texttt{sh} ne le fasse pas de la mani\`ere \`a  laquelle tous les
utilisateurs s'y attendent.  Dans certains cas, nous ajoutons au
programme une version alternative pr\'ef\'er\'ee ne d\'ependant pas du type de
p\'eriph\'erique de sortie.  Par exemple, nous fournissons un programme
appell\'e \texttt{dir}, tr\`es proche de \texttt{ls} except\'e que son
format de sortie par d\'efaut est toujours multi-colonne.

Il est pr\'ef\'erable de suivre les principes propos\'es par POSIX pour les
options de la ligne de commande d'un programme.  La mani\`ere la plus
simple de le faire est d'utiliser \texttt{getopt} pour les extraire de
la ligne de commande.  Notez que, normalement, la version GNU de
\texttt{getopt} autorisera des options n'importe o\`u parmi les
arguments \`a  moins que l'argument sp\'ecial '\texttt{{-}{-}}' ne soit
utilis\'e.  Ce n'est pas ce que sp\'ecifie POSIX ; c'est une extension
GNU.

D\'efinissez des options \`a  noms longs, \'equivalentes aux options en une
lettre de style Unix.  Nous esp\'erons de cette mani\`ere rendre GNU plus
convivial.  C'est facile \`a  mettre en {\oe}uvre avec la fonction GNU
\texttt{getopt\_long}.

L'un des avantages des options \`a  noms longs est qu'elles peuvent \^etre
consistantes d'un programme \`a  l'autre.  Par exemple, les utilisateurs
doivent pouvoir s'attendre \`a  ce que l'option << verbeuse >> de tout
programme GNU en poss\'edant une s'\'ecrive exactement
'\texttt{{-}{-}verbose}'.

Habituellement, il est pr\'ef\'erable que les noms de fichier donn\'es comme
arguments ordinaires ne puissent \^etre que des fichiers d'entr\'ee ; tout
fichier de sortie devra \^etre sp\'ecifi\'e \`a  l'aide d'options (de
pr\'ef\'erence '\texttt{-o}' ou '\texttt{{-}{-}output}').  M\^eme si, pour des
raisons de compatibilit\'e, vous autorisez des noms de fichiers de
sortie comme arguments ordinaires, essayez d'offrir en plus la
possibilit\'e de les sp\'ecifier \`a  l'aide d'une option.  Cela conduira \'e
une plus grande consistance entre les utilitaires GNU et r\'eduira le
nombre de sp\'ecificit\'es dont les utilisateurs devront se rappeler.

Tout programme doit supporter deux options standards :
'\texttt{{-}{-}version}' et '\texttt{{-}{-}help}'.
%
\subsection{\texttt{{-}{-}version}}

Tout programme appel\'e avec cette option doit afficher sur la sortie 
standard des informations sur son nom, sa version, son origine et son 
statut l\'egal, ensuite de quoi le programme se termine normalement. Les 
autres options et arguments doivent \^etre ignor\'es d\`es que cette option est 
reconnue et le programme ne doit pas assurer son fonctionnement normal. La 
premi\`ere ligne est cens\'ee pouvoir \^etre analys\'ee facilement par un 
programme ; le num\'ero de version est plac\'e juste apr\`es le dernier espace. 
De plus, elle contient le nom canonique de ce programme sous le format 
suivant :

\texttt{GNU Emacs 19.30}

Le nom du programme doit \^etre une cha\^{i}ne de caract\`eres constante ;
\emph{ne la calculez pas} \`a  partir de \texttt{argv[0]}.  L'id\'ee est de
donner le nom standard ou canonique du programme, pas son nom de
fichier.  Il existe d'autres proc\'ed\'es pour retrouver le nom exact du
fichier trouv\'e par l'interm\'ediaire de \texttt{PATH} pour une commande
donn\'ee.  Si le programme est une partie annexe d'un package plus
important, mentionnez le nom du package entre parenth\`eses de la
mani\`ere suivante :

\texttt{emacsserver (GNU Emacs) 19.30}

Si le package a un num\'ero de version diff\'erent du num\'ero de version du 
programme, vous pouvez mentionner le num\'ero de version du package juste 
avant la parenth\`ese fermante. S'il est n\'ecessaire de mentionner les 
num\'eros de version des biblioth\`eques qui sont distribu\'ees s\'epar\'ement du 
package qui contient ce programme, vous pouvez le faire en affichant une 
ligne suppl\'ementaire d'information sur la version pour chaque biblioth\`eque 
que vous voulez mentionner. Pour ces lignes, utilisez le m\^eme format que 
pour la premi\`ere ligne. Ne mentionnez pas toutes les biblioth\`eques 
utilis\'ees par le programme ``juste par compl\'etude", cela produit un 
fouillis inutile. Ne mentionnez les num\'eros de version des biblioth\`eques 
que si vous trouvez que c'est tr\`es important pour vous pour le d\'eboguage. 
La ligne suivant la ou les lignes de num\'ero de version doit \^etre une 
notice de copyright. Si plusieurs notices de copyright sont n\'ecessaires, 
mettez-les chacune sur des lignes s\'epar\'ees. Ensuite, doit suivre une br\`eve 
d\'eclaration sur le fait que le programme est un logiciel libre, et que les 
utilisateurs sont libres de le copier et le modifier sous certaines 
conditions. Si le programme est couvert par la GNU GPL, dites le ici. 
Mentionnez aussi qu'il n'y a aucune garantie dans les limites permises par 
la loi. Vous pouvez terminer le message affich\'e par une liste des 
principaux auteurs du programme, afin de leur en attribuer le cr\'edit. 
Voyez ci-apr\'es un exemple d'affichage respectant ces r\`egles :

\begin{verbatim}
GNU Emacs 19.34.5
Copyright (C) 1996 Free Software Foundation, Inc.
GNU Emacs comes with NO WARRANTY,
to the extent permitted by law.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters,
see the files named COPYING.
\end{verbatim}

Bien entendu, vous devez adapter cela \`a  votre programme en y mettant les 
informations correctes concernant l'ann\'ee, le d\'etenteur du copyright, le 
nom du programme, le cadre autoris\'e pour la redistribution et en modifiant 
les termes employ\'es autant que n\'ecessaire. Dans cette notice de copyright, 
il n'est n\'ecessaire de mentionner que l'ann\'ee la plus r\'ecente \`a  laquelle 
des modifications ont \'et\'e apport\'ees ; il n'est aucunement n\'ecessaire de 
lister les ann\'ees concernant les modifications correspondant aux versions 
pr\'ec\'edentes. Vous n'avez pas \`a  mentionner le nom du programme dans ces 
notices, puisqu'il a d\'ej\`a \'et\'e mentionn\'e \`a  la premi\`ere ligne.
%
\subsection{\texttt{{-}{-}help}}
%
Cette option doit afficher sur la sortie standard une documentation br\`eve 
sur la mani\`ere d'appeler le programme, ensuite de quoi le programme se 
termine normalement. Les autres options et arguments doivent \^etre ignor\'es 
d\`es que cette option est reconnue et le programme ne doit pas assurer son 
fonctionnement normal. Vers la fin de cet affichage, il doit y avoir une 
ligne expliquant o\`u envoyer un mail pour signaler un bogue. Cette ligne 
doit respecter le format suivant :

\texttt{Report bugs to \emph{mailing-address}.}
%
\subsection{Utilisation de la m\'emoire}
%
Si vous n'utilisez que quelques m\'egas de m\'emoire, ne vous pr\'eoccupez pas de 
faire des efforts pour r\'eduire l'utilisation de la m\'emoire. Par exemple, 
si, pour de toutes autres raisons, il n'est pas envisageable en pratique 
de travailler sur des fichiers de plus de quelques m\'egaoctets, il est 
raisonnable de charger enti\`erement les fichiers d'entr\'ee en m\'emoire pour 
travailler dessus.

Cependant, pour des programmes comme \texttt{cat} ou \texttt{tail}, qui op\`erent utilement 
sur de tr\`es grands fichiers, il est important d'\'eviter d'utiliser une 
technique qui limiterait artificiellement la taille des fichiers qu'ils 
pourraient traiter. Si un programme travaille ligne par ligne et doit 
s'appliquer \`a  des fichiers quelconques fournis par 
l'utilisateur, il ne doit conserver qu'une ligne en m\'emoire, car cela 
n'est pas tr\`es difficile \`a  mettre en {\oe}uvre et que les utilisateurs 
voudront \^etre en mesure de travailler sur des fichiers d'entr\'ee plus 
grands que ceux qui pourraient tenir en m\'emoire.

Si votre programme cr\'ee des structures de donn\'ees complexes, faites le en 
m\'emoire et faites terminer le programme pr\'ematur\'ement (fatal error) si 
\texttt{malloc} retourne z\'ero.
%
\section{Faire le meilleur usage de C}
%
Ce chapitre fournit des conseils sur comment faire le meilleur usage du 
langage C lors de l'\'ecriture de logiciels GNU.
%

\subsection{Formater votre code source}

\sloppy

Il est important de placer en colonne z\'ero les accolades ouvrantes qui 
marquent le d\'ebut du corps d'une fonction C, et d'\'eviter de placer toute 
autre accolade ouvrante, parenth\'ese ouvrante ou crochet ouvrant en colonne 
z\'ero. Diff\'erents outils recherchent les accolades ouvrantes en colonne 
z\'ero pour d\'eterminer les d\'ebuts de fonctions C. Ces outils ne 
fonctionneront pas si vous ne formater pas votre code source de cette 
mani\`ere.

\fussy

De m\^eme, pour les d\'efinitions de fonctions, il est important de faire 
commencer le nom de la fonction en colonne z\'ero. Cela aide les gens dans 
la recherche de d\'efinitions de fonctions et peut aussi aider certains 
outils \`a  les reconna\^{i}tre. Le formatage correct est donc :

\begin{verbatim}
static char *
concat (s1, s2)        /* Name starts in column zero here */
	char *s1, *s2;
{                     /* Open brace in column zero here */
  ...
}
\end{verbatim}
ou bien, si vous voulez utiliser ANSI C, formater la d\'efinition de cette 
mani\`ere : 
\begin{verbatim}
static char *
concat (char *s1, char *s2)
{
  ...
}
\end{verbatim}
En ANSI C, si les arguments ne tiennent pas correctement sur une ligne, 
scinder la liste des arguments de la mani\`ere suivante :
\begin{verbatim}
int
lots_of_args (int an_integer, long a_long, short a_short,
              double a_double, float a_float)
...
\end{verbatim}
Pour le corps de la fonction, nous pr\'ef\'erons un code format\'e comme ceci : 
\begin{verbatim}
if (x < foo (y, z))
  haha = bar[4] + 5;
else
  {
    while (z)
      {
        haha += foo (z, z);
        z--;
      }
    return ++x + bar ();
  }
\end{verbatim}
Il est plus facile de lire un programme quand il y a des espaces avant les 
parenth\`eses ouvrantes et apr\`es les virgules. Plus particuli\'erement apr\`es 
les virgules.

Lorsque vous scinder une expression sur plusieurs lignes, scindez la avant 
un op\'erateur, pas apr\`es. Ceci est la bonne mani\`ere de faire :
\begin{verbatim}
if (foo_this_is_long && bar > win (x, y, z)
    && remaining_condition)
\end{verbatim}
Essayez d'\'eviter d'avoir deux op\'erateurs de pr\'ec\'edences diff\'erentes au 
m\^eme niveau d'indentation. Par exemple, n'\'ecrivez pas ceci :
\begin{verbatim}
mode = (inmode[j] == VOIDmode
        || GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])
        ? outmode[j] : inmode[j]);
\end{verbatim}
Au lieu de cela, utilisez des parenth\`eses suppl\'ementaires de sorte que 
l'indentation illustre l'imbrication :
\begin{verbatim}
mode = ((inmode[j] == VOIDmode
         || (GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])))
        ? outmode[j] : inmode[j]);
\end{verbatim}
Ins\'erez des parenth\`eses suppl\'ementaires, de sorte que Emacs indente le 
code correctement. A titre d'exemple, l'indentation suivante peut sembler 
correcte si vous la faites \`a  la main, mais Emacs sabotera votre beau 
travail :
\begin{verbatim}
v = rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
    + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000;
\end{verbatim}
L'ajout de quelques parenth\`eses r\'esoudra le probl\`eme  : 
\begin{verbatim}
v = (rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
     + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000);
\end{verbatim}
Formatez les structures de contr\^ole do-while comme ceci : 
\begin{verbatim}
do
  {
    a = foo (a);
  }
while (a > 0);
\end{verbatim}
Utilisez des caract\'eres de saut de page (control-L) pour s\'eparer votre 
programme en pages \`a  des endroits logiques (mais pas \`a  l'int\'erieur d'une 
fonction). La longueur des pages n'a aucune importance, il n'est pas 
n\'ecessaire qu'elle corresponde \`a  la longueur d'une page imprim\'ee. Une 
ligne contenant un saut de page ne doit rien contenir d'autre. 
%
\subsection{Commenter votre travail}
%
Tout programme doit commencer par un commentaire disant bri\`evement \`a  quoi 
il sert. Exemple : '\texttt{fmt - filter for simple filling of text}'.

Dans un programme GNU, \'ecrivez les commentaires en anglais, l'anglais est 
la langue que pratiquement tous les programmeurs de tous les pays peuvent 
lire. Si vous n'\'ecrivez pas bien anglais, \'ecrivez vos commentaires en 
anglais aussi bien que vous le pouvez puis demandez \`a  d'autres personnes 
de vous aider \`a  les r\'e\'ecrire. Si vous ne pouvez pas \'ecrire de commentaires 
en anglais, trouvez quelqu'un pour travailler avec vous et traduire vos 
commentaires en anglais.

Pour chaque fonction, mettez un commentaire d\'ecrivant ce que fait la
fonction, quelle sorte d'arguments elle prend ainsi que ce que
signifient et \`a  quoi sont utilis\'ees les diff\'erentes valeurs possibles
des arguments.  Il n'est pas n\'ecessaire de r\'ep\'eter avec des mots la
signification des d\'eclarations C des arguments, si un type C est
utilis\'e de mani\`ere habituelle.  Si il y a quelque chose de non
standard dans son utilisation (comme un argument de type \texttt{char
*} qui est en r\'ealit\'e l'adresse du second caract\`ere d'une cha\^{i}ne de
caract\`eres et non celle du premier), o\`u que l'une des valeurs
possibles ne fonctionnerait pas de la mani\`ere \`a  laquelle on peut
s'attendre (tel qu'un fonctionnement correct non garantie pour des
cha\^{i}nes de caract\`eres contenants des sauts de lignes), alors vous
devez obligatoirement le mentionner.

Expliquez aussi la signification de la valeur retourn\'ee, si elle en a une.

Afin que les commandes Emacs sur les phrases fonctionnent, mettez deux 
espaces apr\`es la fin d'une phrase dans vos commentaires. Ecrivez des 
phrases compl\`etes et mettez une majuscule au premier mot. En revanche, si 
un identificateur en minuscules vient en d\'ebut de phrase, ne lui mettez 
pas de majuscule ! Changer une des lettres en fait un identificateur 
diff\'erent. Si vous n'aimez pas commencer une phrase par une lettre 
minuscule, \'ecrivez la phrase autrement.

Le commentaire d'une fonction est plus claire si vous utilisez le nom
des arguments pour parler des valeurs des arguments.  Le nom de
variable lui-m\^eme doit \^etre en minuscule, mais \'ecrivez en capitales
quand vous parlez de la valeur plut\^ot que de la variable elle-m\^eme. 
Ainsi, ``the inode number NODE\_NUM" plut\^ot que ``an inode".

Normalement, redonner le nom de la fonction dans le commentaire qui la 
pr\'ec\`ede n'a aucun int\'er\^et, puisque le lecteur peut le voir par lui-m\^eme. 
Il peut n\'eanmoins y avoir une exception lorsque le commentaire est si long 
que la fonction elle-m\^eme pourrait ne pas appara\^{i}tre \`a  l'\'ecran.

Il doit aussi y avoir un commentaire pour chaque variable statique 
(\texttt{static}), comme :
\begin{verbatim}
/* Nonzero means truncate lines in the display;
   zero means continue them.  */
int truncate_lines;
\end{verbatim}
Tout '\texttt{\#endif}' doit avoir un commentaire associ\'e, except\'e dans
le cas de structures conditionnelles courtes (juste quelques lignes)
et sans imbrication.  Le commentaire doit donner la condition de la
structure conditionnelle qui se termine, ainsi que sa signification. 
Tout '\texttt{\#else}' doit avoir un commentaire d\'ecrivant la condition
et la signification du code qui le suit.  Par exemple :
\begin{verbatim}
#ifdef foo
  ...
#else /* not foo */
  ...
#endif /* not foo */
\end{verbatim}
en revanche, \'ecrivez les commentaires de cette mani\`ere pour un
'\texttt{\#ifndef}':
\begin{verbatim}
#ifndef foo
  ...
#else /* foo */
  ...
#endif /* foo */
\end{verbatim}
%
\subsection{Utilisation propre des constructions C}
%
D\'eclarez explicitement tous les arguments des fonctions. Ne les omettez 
pas sous pr\'etexte que ce sont des \texttt{int}.

Les d\'eclarations de fonctions externes et de fonctions apparaissant
plus loin dans le fichier source doivent toutes \^etre plac\'ees \`a  un
endroit vers le d\'ebut du fichier (quelque part avant le premi\`ere
d\'efinition de fonction du fichier) ou bien dans un fichier header
(avec suffixe \texttt{.h}).  Ne mettez pas de d\'eclarations \texttt{extern} \'e
l'int\'erieur des fonctions.

Evitez de r\'eutiliser toujours les m\^emes variables locales (avec des
noms comme \texttt{tmp}) pour des valeurs diff\'erentes \`a  l'int\'erieur
d'une m\^eme fonction.  Pour \'eviter cela, il est pr\'ef\'erable de d\'eclarer
une variable locale distincte pour chaque utilisation distincte, et de
lui donner un nom porteur de sens.  Ce n'est pas uniquement pour
rendre les programmes plus simples \`a  comprendre, mais aussi parce que
cela facilite l'optimisation faite par les bons compilateurs.  Vous
pouvez aussi d\'eplacer la d\'eclaration de chaque variable locale dans le
plus petit bloc incluant toutes ses utilisations.  Cela rend le
programme encore plus propre.

N'utilisez pas de variables locales ou de param\`etres masquant des 
identificateurs globaux.

Ne d\'eclarez pas plusieurs variables en une d\'eclaration s'\'etendant sur 
plusieurs lignes. Au lieu de cela, commencez une nouvelle d\'eclaration \`a  
chaque ligne. Par exemple, au lieu de ceci :
\begin{verbatim}
int    foo,
       bar;
\end{verbatim}
\'ecrivez soit cela : 
\begin{verbatim}
int foo, bar;
\end{verbatim}
soit cela : 
\begin{verbatim}
int foo;
int bar;
\end{verbatim}
(Si ce sont des variables globales, chacune doit \^etre pr\'ec\'ed\'ee d'un 
commentaire.)

Quand vous avez un \texttt{if-else} imbriqu\'e dans un autre
\texttt{if}, mettez toujours des accolades autour du \texttt{if-else}. 
Ainsi, n'\'ecrivez jamais ceci :
\begin{verbatim}
if (foo)
  if (bar)
    win ();
  else
    lose ();
\end{verbatim}
\'ecrivez toujours cela: 
\begin{verbatim}
if (foo)
  {
    if (bar)
      win ();
    else
      lose ();
  }
\end{verbatim}
Si vous avez un \texttt{if} imbriqu\'e dans un \texttt{else}, ou bien
\'ecrivez \texttt{else if} sur une ligne comme ceci,
\begin{verbatim}
if (foo)
  ...
else if (bar)
  ...
\end{verbatim}
avec la partie \texttt{then} indent\'ee comme la partie \texttt{then} pr\'ec\'edente,
ou bien \'ecrivez le \texttt{if} imbriqu\'e entre accolades comme cela :
\begin{verbatim}
if (foo)
  ...
else
  {
    if (bar)
      ...
  }
\end{verbatim}
Ne d\'eclarez pas \`a  la fois une structure et des variables ou des 
d\'efinitions de types dans la m\^eme d\'eclaration. Au lieu de cela, d\'eclarez 
la structure s\'epar\'ement et utilisez la ensuite pour d\'eclarer les variables 
ou les types.

Essayez d'\'eviter les affectations \`a  l'int\'erieur des conditions des \texttt{if}. Par 
exemple, n'\'ecrivez pas ceci :
\begin{verbatim}
if ((foo = (char *) malloc (sizeof *foo)) == 0)
  fatal ("virtual memory exhausted");
\end{verbatim}
\'ecrivez cela \`a  la place :
\begin{verbatim}
foo = (char *) malloc (sizeof *foo);
if (foo == 0)
  fatal ("virtual memory exhausted");
\end{verbatim}
Ne rendez pas le programme inutilement compliqu\'e, juste pour
satisfaire les exigences de \texttt{lint}.  Ne mettez jamais de cast
pour un \texttt{void}.  Un z\'ero sans cast convient \`a  la perfection
pour une constante pointeur nulle, sauf lors d'un appel de fonction \`a
nombre d'arguments variables.
%
\subsection{Choix des identificateurs de variables et de fonctions}
%
Dans un programme, les noms des variables globales et des fonctions 
constituent une forme de commentaire. En cons\'equence, plut\^ot que 
d'utiliser des noms concis, cherchez plut\^ot des noms qui donnent des 
informations utiles sur la signification de la variable ou de la fonction. 
Dans un programme GNU, de la m\^eme mani\`ere que pour les commentaires, les 
identificateurs doivent \^etre en anglais.

Les noms de variables locales peuvent \^etre plus courts, car ils sont 
utilis\'es uniquement dans un seul contexte o\`u des commentaires expliquent 
leur r\^ole.

Utilisez des caract\`eres underscore pour s\'eparer les mots dans un
identificateur, afin que les commandes sur les mots de Emacs puissent
leur \^etre appliqu\'ees utilement.  Tenez vous en aux lettres minuscules
; r\'eservez les majuscules aux constantes d\'efinies par macros ou
\texttt{enum} et aux pr\'efixes qui ob\'eissent \`a  une convention uniforme.

Vous pouvez, par exemple, utiliser des noms comme
\texttt{ignore\_space\_change\_flag} ; mais n'utilisez pas de nom
comme \texttt{iCantReadThis}.  Les variables indiquant si des options
de la ligne de commande ont \'et\'e sp\'ecifi\'ees doivent \^etre nomm\'ees
d'apr\`es la signification de l'option et non d'apr\`es la lettre
correspondant \`a  l'option.  Un commentaire doit indiquer \`a  la fois la
signification de l'option et sa lettre.  Par exemple :
\begin{verbatim}
/* Ignore changes in horizontal whitespace (-b).  */ 
int ignore_space_change_flag;
\end{verbatim}

Quand vous voulez d\'efinir des noms avec des valeurs constantes
enti\`eres, utilisez \texttt{enum} plut\^ot que '\texttt{\#define}'.  GDB
reconna\^{i}t les constantes \'enum\'erations.

Utilisez des noms de fichier de 14 caract\`eres ou moins, afin d'\'eviter
des probl\`emes avec les plus anciennes versions du syst\`eme System V.
Vous pouvez utilisez le programme \texttt{doschk} pour tester cela. 
\texttt{doscheck} teste aussi les conflits de nom potentiels si les
fichiers \'etaient charg\'es sur un syst\`eme de fichier MS-DOS -- libre \`a
vous de vous en soucier ou non.
%
\end{document}


\end{document}

