\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 dˇveloppement 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\'ero•de 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ˇ rˇdigˇe intˇgralement 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 ambigu•t\'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 co˛t 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}