\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{Janvier 2016} \title{L I C E N C E ~ ~ I N F O R M A T I Q U E\\Projet de fin d'\'etudes\\ Sujets, Dates et Consignes\\Ann\'ee 2015-2016} \author{\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\Encadrants: Catherine Recanati et Nicolas Rolin\\\url{catherine.recanati@lipn.univ-paris13.fr}\\ \url{nicolas.rolin@lipn.univ-paris13.fr}} \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 g\'en\'erales} \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, un guide pour la r\'ealisation du projet, les dates limites de remise des documents servant de base pour la notation de votre travail, et la liste des sujets propos\'es cette ann\'ee. Si vous souhaitez travailler sur un autre sujet, vous pouvez nous le proposer par mail pour validation. Vous devez imp\'erativement respecter les consignes et les dates de remise de documents. En particulier, vous devrez commencer par proposer la formation d'un groupe de 4 personnes avant le 12 f\'evrier, et donner la liste des trois sujets pr\'ef\'er\'es de votre groupe. L'acceptation du groupe et l'affectation du sujet seront alors valid\'ees par nous. Ce n'est pas vous qui choisissez le sujet, mais dans la mesure du possible nous validerons votre premier choix. N\'eanmoins en cas de probl\`eme, nous nous r\'eservons le droit de vous imposer un sujet ou un groupe. \section{Dates importantes} Vous commencerez donc par former un groupe de 3 personnes (en cas de difficult\'es, contactez vos encadrants) et choisirez trois sujets parmi ceux pr\'esent\'es ici. Si vous souhaitez travailler sur un sujet diff\'erent de ceux propos\'es, envoyez rapidement une page de description du sujet au format pdf \`a Nicolas Rolin et Catherine Recanati, qui valideront ou non votre proposition de sujet. \textbf{Remarque importante~: tous vos messages (et documents) doivent \^etre envoy\'es syst\'ematiquement en doublon \`a Nicolas Rolin et Catherine Recanati. Vous devez aussi prendre l'habitude de mettre tous les membres de votre groupe en copie.} \\ Vous devez envoyer \textbf{avant le 12 f\'evrier 2016, 17h}, \`a Nicolas Rolin et Catherine Recanati, trois sujets int\'eressants votre groupe (en ordonnant vos pr\'ef\'erences), ainsi que la liste des membres du groupe et leurs adresses mail. Vous serez inform\'es par courrier \'electronique du sujet qui vous sera finalement attribu\'e dans la semaine suivante. La deuxi\`eme date butoir est celle de l'envoi de votre premier rapport. C'est \textbf{le 28 mars 2016}. Vous serez en partie not\'es sur la qualit\'e de ce premier document de sp\'ecification logicielle, et il est tr\`es important que vous suiviez scrupuleusement les consignes de travail et de r\'edaction donn\'ees dans les deux prochains chapitres. Vous enverrez ce rapport de 15 pages maximum \textbf{au format pdf uniquement}. %Le langage utilis\'e sera C, Java ou C++. 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\'eveloppement utilis\'e(s), envoyez un mail \`a vos deux encadrants. \newpage Ce premier rapport 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 une description de l'architecture logicielle fournie sous la forme d'une liste des diff\'erents modules ou packages pr\'evus, et du sch\'ema ou diagramme de d\'ependances entre ces modules. Sur ce sch\'ema les modules seront repr\'esent\'es par des bo\^ites rectangulaires, et les appels (ou d\'ependances) entre modules seront repr\'esent\'es par des fl\`eches (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 du projet et un planning pr\'evisionnel de r\'epartition des t\^aches dans le temps (diagramme de Gantt, cf. \ref{subsec:planning}) \end{itemize} \textbf{Notez bien qu'aucune programmation n'est demand\'ee \`a ce stade} (il ne s'agit que de sp\'ecifications) \textbf{mais 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. D\'ebut avril vous aurez des retours sur votre rapport par courrier \'electronique. Il vous faudra alors le corriger en tenant compte des remarques qui vous auront \'et\'e faites et votre note finale tiendra compte du soin que vous aurez apport\'e \`a ces corrections dans le m\'emoire final. ~ Les groupes jug\'es en difficult\'e seront convoqu\'es par courrier \'electronique pour une s\'eance de travail avec les encadrants \textbf{la semaine du 4 ou du 11 avril}. ~ Les soutenances auront lieu le \textbf{mardi 7 juin}. Vous ferez le matin une pr\'esentation collective (bas\'ee sur un fichier PowerPoint, OpenOffice ou pdf) et vous ferez l'apr\`es-midi une d\'emonstration de votre logiciel en salle machine, sur les machines de Galil\'ee ou sur vos propres ordinateurs. \\ \textbf{NB}: Le fichier de la pr\'esentation orale (format .pdf, .ppt, .pptx ou .odp) sera envoy\'e par mail \textbf{deux jours avant la soutenance}, i.e. avant le dimanche soir, 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 le r\'ep\'eter dans l'environnement pr\'evu pour la d\'emo. ~ \textbf{La semaine qui pr\'ec\'ede celle des soutenances (semaine du 30 mai)}, vous devrez envoyer par mail : \begin{itemize} \item le m\'emoire final d'au plus 25 pages hors annexes (format pdf uniquement) d\'ecrivant l'ensemble de votre projet (vous compl\'eterez le premier rapport) \item le manuel utilisateur de votre logiciel (comportant aussi un manuel d'installation) au format PDF \'egalement \item votre pr\'esentation (en fin de semaine) \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 des soutenances mais \`a vos risques et p\'erils (conservez toujours 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). ~ %La note finale tiendra compte de la qualit\'e de la pr\'esentation, de celle de la d\'emonstration, ainsi que du rendu logiciel. \section{Aide} Vous pouvez naturellement envoyer des messages \'electroniques aux deux encadrants pour avoir des \'eclaircissements sur votre sujet, une aide sur la conception ou 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). Si votre probl\`eme ne peut pas \^etre r\'esolu par mail, nous vous donnerons rendez-vous. \newpage \chapter{\'Evaluation et livrables} \label{cha:evaluation-du-projet} % L'\'evaluation du projet sera faite au vu de : \begin{itemize} \item l'organisation du travail en groupe et le respect des d\'elais \item le premier rapport \item la qualit\'e du m\'emoire: corrections effectu\'ees apr\`es les remarques des encadrants sur le premier rapport, manuel utilisateur et pr\'ecision du manuel d'installation \item la soutenance orale finale \item la d\'emonstration finale du logiciel \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 quantit\'e de travail fournie, relativement aux nombre de participants \end{itemize} et enfin, la difficult\'e intrinsque du sujet. %\section{Envois par mail} ~ Les documents livrables seront envoy\'es par mail aux deux encadrants, et en copie \`a tous les membres du groupe. Les textes seront au format pdf, et pour le code on enverra un fichier d'archive (format zip ou tar.gz uniquement). La pr\'esentation orale finale sera livr\'ee au format PowerPoint, OpenOffice ou pdf, au plus tard deux jours avant la soutenance. Pour faciliter la recherche et classification de vos envois par mail, votre premier mail proposant un groupe et des sujets sera intitul\'e \textbf{[ProjetL3] Choix projet}. Ensuite, vous vous verrez attribuer un sujet et un num\'ero de groupe. Si vous \^etes le groupe G12, vous utiliserez le pr\'efixe \textbf{[ProjetL3 - G12]} pour tous vos envois. En particulier, les diff\'erents livrables demand\'es seront envoy\'es avec comme titres \textbf{[ProjetL3 - G12] Rapport}, pour le premier rapport, \textbf{[ProjetL3 - G12] M\'emoire}, pour le m\'emoire final, \textbf{[ProjetL3 - G12] Soutenance}, pour le fichier de pr\'esentation orale, \textbf{[ProjetL3 - G12] Code}, etc. \section{Le premier rapport} Soignez en particulier la premi\`ere page, et faites une table des mati\`eres pagin\'ee. La premi\`ere page doit comporter~: \begin{itemize} \item un titre (mentionnant le sujet trait\'e) \item le nom des auteurs (et leurs courriers \'electroniques) \item la formation et l'ann\'ee \item la date \`a laquelle cette version du rapport a \'et\'e termin\'ee et un num\'ero de version \item le nom des encadrants auxquels le rapport est destin\'e \end{itemize} % \subsection{Plan du rapport} % Le premier rapport doit comporter les chapitres suivants : \begin{enumerate} \sloppy \item Pr\'esentation g\'en\'erale du sujet (on doit pr\'evoir une introduction, et une pr\'esentation du domaine de l'application; s'il s'agit d'un jeu, expliquez les r\`elles du jeu par exemple). \item Analyse approfondie, afin de d\'ecrire enti\`erement le projet \`a r\'ealiser. On y pr\'ecisera les probl\`emes th\'eoriques ou pratiques sous-jacents \`a l'\'enonc\'e du sujet, le type d'utilisateur pr\'evu, les principales fonctionnalit\'es demand\'ees ou n\'ecessaires ainsi que la description des formats d'entr\'ees/sorties s'il y a lieu; les contraintes explicites ou non, l'environnement mat\'eriel et logiciel du projet doivent aussi \^etre d\'etaill\'es, et les choix effectu\'es doivent \^etre pr\'esent\'es avec leur justification (cf. \ref{sec:ana-approf}). \item La liste \textbf{compl\`ete} des fonctionnalit\'es du logiciel (cf. \ref{subsec:liste}). \fussy \item La conception architecturale du logiciel (cf. \ref{subsec:archi}). Le logiciel sera d\'ecoup\'e en modules. Cette partie du rapport comprend au minimum \textbf{la liste compl\`ete de tous les modules, et le graphe des d\'ependances entre les diff\'erents modules}. Sur ce graphe les modules seront repr\'esent\'es par des bo\^ites rectangulaires, et les appels (ou d\'ependances) entre modules seront repr\'esent\'es par des fl\`eches. \item Planning. On fournira la liste des t\^aches et un planning pr\'evisionnel repr\'esentant ces t\^aches en parall\`ele dans le temps (diagramme de Gantt). Remarque: \`a chaque module correspond d\'ej\`a une t\^ache de conception et une t\^ache d'impl\'ementation, mais il faut aussi pr\'evoir les t\^aches de r\'edaction de documents, d'apprentissage de langage ou de librairie, mais aussi les t\^aches d'int\'egration de modules, et celles de debuggages ou de tests. \end{enumerate} Nous ferons des retours critiques sur le premier rapport. Il vous faudra en tenir compte et le corriger avant de l'inclure dans le m\'emoire final du projet. \section{Le m\'emoire du projet} \label{cha:le-memoire-de} % Le m\'emoire final du projet reprend les chapitres du premier rapport en y ajoutant des compl\'ements (conception d\'etaillee, r\'epartition des t\^aches entre les diff\'erents membres du groupe, planning pr\'evisionnel initial et planning d\'etaill\'e effectif), auquel s'ajoute un manuel utilisateur et une conclusion (bilan du projet). % %\subsection{Pr\'esentation} % ~ Toutes les pages doivent \^etre num\'erot\'ees et le m\'emoire doit comporter une table des mati\`eres. La premi\`ere page comportera ~: \begin{itemize} \item un titre (mentionnant le sujet trait\'e) \item le num\'ero de votre groupe, par exemple G3 \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 encadrants auxquels le document est destin\'e \item la date \`a laquelle cette version du m\'emoire a \'et\'e imprim\'ee \end{itemize} % \subsection{Plan du m\'emoire} % Le m\'emoire proprement dit doit comporter les chapitres suivants : \begin{enumerate} \sloppy \item Une pr\'esentation g\'en\'erale du sujet \item L'analyse approfondie \fussy \item La liste compl\`ete des fonctionnalit\'es \item La conception architecturale (liste et description des modules et diagramme de d\'ependances) \item La conception d\'etaill\'ee. Vous pourrez fournir par exemple \begin{itemize} \item l'esquisse des algorithmes cruciaux \item la liste des en-t\^etes de proc\'edures ou fonctions class\'ees par module, \item la liste des donn\'ees partag\'ees et leurs structures \item la liste des fichiers comportant les donn\'ees ou les modules de programmes \item si vous programmez en java, un diagramme de classe et \'eventuellement la javadoc du code des principaux modules en annexe \item de mani\`ere g\'en\'erale, toute sp\'ecification logicielle (par exemple en format UML) que vous auriez utilis\'ee. Mais rien ne vous est impos\'e car certains d'entre vous n'ont pas eu de formation au G\'enie Logiciel \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 Le planning pr\'evisionnel initial d\'etaill\'e et le planning effectif \item Un manuel utilisateur qui inclura un manuel d'installation \item Une conclusion (bilan technique et humain du projet) \item Le cas \'ech\'eant, en annexe, 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. \end{itemize} \end{enumerate} 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. % \subsection{Planning pr\'evisionnel et planning effectif} Le planning fourni initialement sera pr\'esent\'e sur un diagramme de Gantt et on listera les t\^aches en indiquant les membres du groupes en charge de chacune. On fournira aussi le planning qui aura finalement \'et\'e r\'ealis\'e (planning effectif) en indiquant au besoin les raisons ayant conduit \`a sa modification. \subsection{Le manuel utilisateur et le manuel d'installation} Le manuel utilisateur doit contenir un manuel d'installation du logiciel. ~ Le manuel d'installation doit fournir toutes les informations n\'ecessaires pour installer le logiciel. En particulier il doit pr\'eciser l'environnement minimal requis pour pouvoir proc\'eder \`a l'installation du logiciel et indiquer \begin{itemize} \item la liste comment\'ee des fichiers n\'ecessaires pour ex\'ecuter le logiciel (librairies, utilitaires, programmes sources, ex\'ecutables) ; ne pas oublier de pr\'eciser les num\'eros de version des syst\`emes ou compilateurs ; tout l'environnement n\'ecessaire \`a l'ex\'ecution doit \^etre d\'ecrit et on donnera \'eventuellement les adresses internet o\`u le 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 quelle commande make doit \^etre tap\'ee pour lancer son ex\'ecution). \end{itemize} Faites tester l'installation par une personne d'un autre groupe pour v\'erifier que vous n'avez rien oubli\'e. ~ Le manuel utilisateur proprement dit d\'ecrit comment lancer le logiciel et comment l'utiliser. Il doit lister toutes les fonctionnalit\'es accessibles, et les contraintes devant \^etre respect\'ees. Il doit indiquer comment se d\'eroule le dialogue avec l'utilisateur (\'eventuellement, donner les \'ecrans de l'interface utilisateur) et pr\'eciser ce qui se passe en cas d'erreur (liste des messages d'erreur par exemple). Une bonne mani\`ere de proc\'eder pour cela est d'\'ecrire un premier chap\^itre pr\'esentant la session typique d'un utilisateur. Ce premier chapitre pr\'esentera de mani\`ere naturelle le "parcours" d'un utilisateur lors d'une premi\`ere session du logiciel. Ensuite, on peut d\'ecrire de mani\`ere plus syst\'ematique les diff\'erentes fontionnalit\'es dans les chapitres suivants. \section{La soutenance orale} Vous devez faire le bilan du projet dans une pr\'esentation PowerPoint (ou OpenOffice, ou un fichier de transparents au format pdf). \textbf{Votre pr\'esentation ne doit pas durer plus de 10 minutes} (il y aura 5 minutes suppl\'ementaires pour des questions). Cette pr\'esentation doit \^etre collective et vous vous passerez tour \`a tour la parole. Vous commencerez bien s\^ur par pr\'esenter le sujet. Vous pouvez ensuite reprendre certaines 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 aussi 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 et l'interface utilisateur, car ce sera fait dans la d\'emonstration de l'apr\`es-midi). Vous pouvez aussi parler de l'organisation du travail (r\'epartition des t\^aches 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'extension ou 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} % \textbf{La d\'emonstration ne doit pas exc\'eder 13 minutes}, et il y aura 7 minutes de questions. 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 n\'eanmoins montrer le fonctionnement correct de certaines fonctions ou modules). \item Pr\'eparer un sc\'enario d'utilisation permettant de satisfaire ces objectifs. Cela peut n\'ecessiter l'utilisation de fichiers pr\'epar\'es par 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). Pr\'eparer aussi 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 encore 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 vos encadrants). \chapter{Guide de r\'ealisation des projets} \label{cha:guide-de-realisation} \section{Pr\'eliminaires} \subsection{Formation du groupe} Vous devez vous pr\'eoccuper de former un groupe d\`es le d\'ebut du semestre. Il y a un cr\'eneau horaire et une salle pr\'evue dans votre emploi du temps pour que vous puissiez vous r\'eunir r\'eguli\`erement et facilement. Nous vous recommandons d'utiliser ce cr\'eneau d\`es la premi\`ere semaine pour vous rencontrer, discuter et former un groupe. Une fois votre groupe form\'e vous pourrez discuter des sujets qui vous attirent le plus. Mais avant toute chose, il faut que vous \'echangiez vos adresses mails et vos num\'eros de t\'el\'ephone personnels pour pouvoir vous joindre en cas d'urgence. ~ Vous pourrez \'eventuellement vous attribuer des r\^oles au sein du groupe (comme chef de Projet, charg\'e du planning, charg\'e de r\'edaction de documentation, charg\'e de l'interface graphique, etc.). Mais m\^eme si quelqu'un est charg\'e de la r\'edaction d'un document, il est tr\`es important que tous les membres du groupe relisent le document. Vos documents devront donc circuler entre vous par mail avant d'\^etre envoy\'es aux encadrants. \subsection{Sp\'ecification du logiciel} L'\'ecriture d'un programme sur machine doit \^etre imp\'erativement pr\'ec\'ed\'ee de l'analyse du probl\`eme et de la conception (papier) du logiciel. C'est la raison pour laquelle nous vous demandons de nous remettre un premier rapport avant de vous mettre \`a coder. Ce rapport nous permet de vous faire des remarques, et vous le corrigerez avant de vous mettre \`a la conception d\'etaill\'ee puis 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. ~ 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\`eque, 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, jouer un coup, pour un jeu d'\'echecs en r\'eseau). Le niveau de la t\^ache est assez g\'en\'eral et orient\'e "utilisateur", et celui des fonctionnalit\'es est plus pr\'ecis et d\'etaill\'e. Notez cependant que les fonctionnalit\'es sont ind\'ependantes de l'interface utilisateur (qui peut tout autant \^etre graphique que textuelle). ~ Pour bien fixer tout cela, nous vous demandons de nous rendre dans le premier rapport une pr\'esentation et une analyse approfondie de votre projet, ainsi que la 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 et la planification du projet. \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 est 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. \textbf{\underline{Recommandation}}: 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 (noms et verbes) 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 des termes utilis\'es pour les d\'esigner (la terminologie du domaine de l'application). 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 de votre texte, et les actions pouvant \^etre ex\'ecut\'ees correspondront \`a des verbes ou participes pass\'es. 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, en fixant le vocabulaire du domaine de l'application. \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 quelles occasions, 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 pourra 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 de pr\'esenter la liste des fonctionnalit\'es du logiciel en les regroupant par sections th\'ematiques. Ainsi par exemple, on regroupera ensemble les fonctionnalit\'es de sauvegarde (enregistrer sous, enregistrer, etc.) et de chargement dans une m\^eme section, les fonctionnalit\'es de connexion/d\'econnexions ou inscription d'un utilisateur, etc. %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 pourra \'etoffer la conception d\'etaill\'ee mais il ne fera pas 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 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 - les 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, et par des programmeurs diff\'erents. La personne qui, \`a l'\'etape du codage, programmera un module donn\'e 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. \item[Choix des langages de programmation correspondant \`a chaque module:] il se peut que l'on programme l'interface graphique dans un langage diff\'erent de celui avec lequel on d\'enveloppe l'application proprement dite, ou qu'on ait \`a utiliser une architecture particuli\`ere imposant l'usage de langages particuliers (html, javascript, etc.). \item[Choix de l'environnement de d\'eveloppement:] il faut d\'eterminer 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 seule 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. Si on a d\'ej\`a regroup\'e les fonctionnalit\'es en sections, chaque section donnera probablement lieu \`a un module. Pour chaque grande 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. Cela permettra de faire appara\^itre les d\'ependances entre les modules. %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. 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. Lors de ce travail, vous devez donner un nom le plus explicite possible \`a chaque module et aux donn\'ees (ou modules) qu'il utilise ou produit. Notez qu'il y a aujourd'hui des modules relativement classiques, comme un module d'Interface Graphique Utilisateur si vous avez une interface utilisateur clavier/souris; un module Gestion de Base de Donn\'ees (qui permettra de faire des requ\^etes sur une BD); un module Connexion/D\'econnexion pour un site web ou une application qui requiert une insciption ou un login; un module Sauvegarde/Enregistrement pour g\'erer la relation aux syst\`eme de fichiers. \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 cette analyse sera exprim\'e sous la forme d'un graphe de d\'ependances : chaque module est repr\'esent\'e par une bo\^{i}te rectangulaire, et les d\'ependances sont repr\'esent\'ees par des fl\`eches orient\'ees entre ces bo\^{i}tes. \fussy Pour d\'ecrire l'architecture du programme, on fournira donc dans le premier rapport un d\'ecoupage en modules (en choisissant soigneusement leurs noms). On donnera une liste avec une br\`eve description des modules, et on les repr\'esentera ensuite par des boites rectangulaires sur un graphe de d\'ependances. Remarque: Il se peut que le logiciel soit constitu\'e de plusieurs programmes, et qu'il existe une architecture particuli\`ere 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 un programme et un module, et on repr\'esentera cette architecture globale sur le m\^eme diagramme en indiquant les relations de d\'ependances entre les diff\'erents programmes ou 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\'evoira un module destin\'e \`a l'interface graphique. En effet le monde de l'interface est un monde \`a part de celui du domaine du logiciel. Il est constitu\'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 sera donc effectu\'ee dans le module de l'interface graphique, et ce dernier sera reli\'e au reste de l'application par des appels de fonctions, allant parfois dans les deux sens. De m\^eme, si l'on utilise une base de donn\'ees, on regroupera dans un m\^eme module tout ce qui concerne la gestion de cette base de donn\'ees (consultation, enregistrement, etc.). Ce module BD interagira alors avec le reste de l'application en permettant l'interrogation et la modification de la base de donn\'ees. (Si on ne veut pas que ce module BD interagisse directement avec le reste de l'application, on pourra d\'efinir un module suppl\'ementaire d'interface logicielle, charg\'e uniquement de la communication entre la BD et l'application proprement dite). \subsection{Conception de l'interface utilisateur} Bien que la description de l'interface utilisateur ne figure pas dans le premier rapport, vous devrez produire, \textbf{avant de vous lancer dans la conception d\'etaill\'ee et le codage}, les documents suivants : \begin{description} \item[Description d'une version pr\'eliminaire de l'interface:] les diff\'erents \'ecrans de l'interface utilisateur doivent \^etre pr\'ecis\'es, ainsi que la mani\`ere dont ils s'encha\^{i}nent en fonction des choix de l'utilisateur. Cette description peut rester relativement informelle (sous forme papier-brouillon mais relativement exhaustive). \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 sera constitu\'e en partie de la description des diff\'erents \'ecrans. Vous pouvez bien s\^ur l'\'ecrire avant de passer au codage, et il servira de document de sp\'ecification pour les programmeurs de l'interface. \end{description} Les diff\'erentes fonctionnalit\'es du logiciel sont accessibles via l'interface utilisateur. Notez bien qu'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 fera une version pr\'eliminaire de l'interface en dessinant les diff\'erents \'ecrans devant lesquels pourra se trouver l'utilisateur. \textbf{Pour la conception elle-m\^eme de l'interface, suivez soigneusement les recommandations qui figurent dans les sous-sections suivantes et en particulier celles de la section \ref{cha:conseils}.} % %\chapter{Conception de l'interface} % auteur Catherine Recanati \subsection{Distinction Interface/Application} Avant de r\'efl\'echir \`a 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 les avantages de 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 ou \`a l'interaction entre l'homme et la machine peuvent y appara\^itre, en particulier si le logiciel est graphique (comme un logiciel de dessin). 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 sous forme d'impression de caract\`eres (\`a l'\'ecran ou sur imprimante). 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 graphiques, et impliquent un dispositif 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, un damier, des pions, des joueurs dans le cas d'un jeu de dames, etc.), et des structures utilis\'ees pour organiser ou calculer sur ces donn\'ees (structures arborescentes, attributs d'objets, listes, tableaux, tables de BD). C'est un univers sur lequel on d\'efinit des 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 en utilisant des structures de donn\'ees et vous d\'efinissez 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 de notre interaction avec les \'ecrans actuels. Ce monde qui g\'ere l'interaction avec l'utilisateur est complexe mais bas\'e sur des conventions. 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 des gestionnaires d'affichage, des mod\`eles ou des vues d'objets complexes (par exemple les mod\`eles et les vues de tables ou de listes en Java Swing). 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. Avec les toolkits X11 ou les librairies graphiques, vous serez amen\'e \'egalement \`a suivre le mod\`ele de programmation par \'ev\'enements pr\'econis\'e par les concepteurs de la librairie. Ces mod\`eles pr\'evoient tous la communication entre ce monde de l'interface et celui de l'application. %mais on aura parfois un probl\`eme d'int\'egration si les langages de programmation utilis\'es dans le module de l'application et celui de l'interface graphiques sont diff\'erents. La solution consiste alors \`a avoir un module qui fait le lien entre les deux modules g\'en\'eralement au moyen d'un appel syst\`eme. \subsection{Conception de l'interface graphique} \label{cha:conseils} M\^eme si vous ne pouvez pas d\'evelopper une interface graphique, vous pouvez quand m\^eme en concevoir une - celle que vous auriez aim\'e programmer si vous en aviez eu le temps. Vous ne devez donc pas sauter cette \'etape, et vous pouvez fournir un manuel utilisateur d\'ecrivant l'interface graphique que vous aurez sp\'ecifi\'ee. Votre travail de conception sera pris en compte dans la notation finale. ~ 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. ~ \subsubsection{R\`egle n${}^o$1: D\'efinir les termes utilis\'es et l'iconographie} 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. 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. 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. \subsubsection{Etape suivante: concevoir les principaux \'ecrans} 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. ~ \textbf{S'appuyer sur les standards et 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. 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. ~ \textbf{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{R\`egle n${}^o$2: Donner le contr\^ole et du feed-back \`a l'utilisateur} 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). ~ \textbf{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 ces bo\^ites de messages, on utilisera les bo\^ites de dialogue toutes pr\^etes fournies par la biblioth\`eque utilis\'ee. ~ \textbf{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. ~ \textbf{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. Pour facilter la compr\'ehension, on utilisera aussi les boites de messages standards pr\^etes \`a l'emploi. \subsubsection{R\`egle n${}^o$3: Soigner la mise en page} il n'est pas toujours \'evident d'analyser pourquoi une interface est claire, mais la clart\'e de l'interface provient en grande partie de la disposition g\'eom\'etrique des \'el\'ements. ~ \textbf{Un regroupement d'objets dans une zone sp\'ecifique 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). De mani\`ere g\'en\'erale, vous devez concevoir vos \'ecrans par zones. ~ \textbf{Cr\'eer des zones et les nommer avec des titres:} 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 pour 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. ~ \textbf{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. ~ \textbf{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, on entend 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, par exemple, si on aligne les bords gauches des labels et les bords gauches des champs de texte situ\'es en vis-\`a-vis dans une boite de dialogue, 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 cette raison que l'on a choisi de griser les commandes inaccessibles dans un menu, plut\^ot que de les faire dispara\^itre dynamiquement, car les items du menu ne se seraient plus trouv\'es \`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 s'ils sont communs \`a plusieurs boites similaires. 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} \subsubsection{R\`egle n${}^o$4: veiller \`a la coh\'erence} Veiller partout \`a la coh\'erence. Par exemple, si vous avez plusieurs fa\c{c}ons de d\'eclancher une commande, la proc\'edure qui sera 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. Pour que la documentation soit correcte, il faut \'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. Il faut \'egalement avoir une utilisation coh\'erente 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. \section{Conception d\'etaill\'ee et Planning pr\'evisionnel} % \subsection{Conception d\'etaill\'ee} 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 \`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. \subsection{Planning pr\'evisionnel} \label{subsec:planning} Vous devez \'egalement \'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 travaille sur cette t\^ache, 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 cherche donc \`a \'etablir les d\'ependances entre les t\^aches, et on les ordonnera et parall\'elisera. On listera 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 coneption, 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 aussi souvent des surprises et demande parfois des corrections. Il est donc important de r\'eserver du temps pour la phase d'int\'egration des diff\'erents modules. On d\'efinira donc aussi des t\^aches d'int\'egration. Vous pouvez lister toutes les t\^aches sur un tableau. Les t\^aches pourront ainsi \^etre repr\'esent\'ees dans le temps en parall\`ele sur un sch\'ema appel\'e diagramme de Gantt. Dans un diagramme de Gantt on repr\'esente : \begin{itemize} \item en abscisse les unit\'es de temps (exprim\'ees en mois, en semaine ou en jours) \item en ordonn\'ee les diff\'erentes t\^aches. \end{itemize} Initialement, le diagramme de Gantt ne visualise que le temps : les dates (d\'ebut et fin) ainsi que la dur\'ee des t\^aches. Cependant il est fr\'equent de mat\'erialiser par des fl\`eches les liens de d\'ependance entre les t\`aches (la fl\`eche relie la t\`ache pr\'ec\'edente \`a la t\^ache suivante). Vous devez fournir un tel diagramme dans le premier rapport, et dans le m\'emoire vous y ajouterez le diagramme plus pr\'ecis correspondant au planning r\'eel effectivement suivi (avec des t\^aches plus d\'etaill\'ees) . \begin{center} \includefigtr{image009}{scale=.5}{scale=.5} %\includegraphics{image009.pdf} \\ Exemple de diagramme de Gantt \end{center} % \section{Codage} % C'est seulement apr\`es l'\'etape de conception d\'etaill\'ee 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 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} ~ Vous devrez vous r\'eunir r\'eguli\`erement pour faire le point sur l'avancement des diff\'erentes t\^aches. Le planning pr\'evisionnel \'evoluera donc en fonction de l'\'etat d'avancement et vous serez amen\'es \`a le modifier lorsque des \'ev\'enements impr\'evus surgiront. Ainsi, si quelqu'un n'arrive pas \`a r\'soudre un probl\`eme ou s'il programme trop lentement, vous pourrez lui adjoindre un membre du groupe pour l'\'epauler et modifier le planning ou la r\'epartition initialement pr\'evus. \section{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. 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. %\appendix \chapter{Liste des sujets propos\'es} \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 (un num\'ero de casier 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 la cave \item modification de vin r\'epertori\'e dans la cave \item ajout de vin \item suppression de vin \item sauvegarde d'une cave \item Recherche et affichage de vin 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 par avance). \item Vous pourrez stocker les informations relatives \`a la cave dans une base de donn\'ees. (Le langage Java poss\`edent des facilit\'es pour la cr\'eation et l'interrogation de base de donn\'ees). \item Si vous prenez la d\'ecision de stocker les informations relatives \`a la cave dans des fichiers (au lieu d'une base de donn\'ees) et que vous programmez en C, vous pourrez utiliser les outils Flex et Bison pour analyser ces fichiers. Si vous programmez en Java, vous pourrez alternativement d\'efinir vous-m\^eme un analyseur syntaxique de vos fichiers \`a l'aide de la classe StreamTokenizer. \end{itemize} % 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 dansle 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\^etesur 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 anc\^etres connus (parents, grands-parents, arri\`ere-grands-parents, etc.). Le programme doit permettre \`a l'utilisateur de s'inscrire en tant que personne et de cr\'eer son arbre g\'en\'ealogique. Pour chaque personne, on peut conna”tre son nom et son pr\'enom, sa date et son lieu de naissance, son sexe et \'eventuellement sa date et son lieu de d\'ec\`es. Initialement, l'utilisateur a un arbre g\'en\'ealogique vide (ou si on veut, r\'eduit \`a un noeud: contenant les informations sur sa propre personne, mais pas ses parents). Le programme doit permettre \`a l'utilisateur de modfier son arbre g\'en\'ea\-logique (entrer un nouvel ascendant, le supprimer ou le modifier). Un arbre g\'en\'ealogique est constitu\'e de noeuds contenant les m\^emes champs que ceux d'une personne, compl\'et\'es de deux ascendants : son p\`ere et sa m\`ere. Certains champs peuvent ne pas \^etre renseign\'es. L'utilisateur devra aussi avoir la possibilit\'e de sauvegarder son arbre g\'en\'ea\-logique de sorte qu'il le retrouve lors d'une nouvel session et il pourra aussi l'afficher sur l'\'ecran pour le visualiser. Il faudra maintenir les informations enregistr\'ees par les utilisateurs dans une m\^eme base de donn\'ees. Le logiciel devra aussi 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. Ces recherches pourront combiner plusieurs crit\`eres. L'utilisateur devra ainsi pouvoir charger les arbres g\'en\'ealogiques d'autres personnes que lui-m\^eme qu'il aura trouv\'e dans la base. \textsf{Extensions possibles}: le couple des parents d'une personne peut avoir d'autres enfants. On pourrai vouloir stocker les autres enfants d'un m\^eme couple, ce qui am\`enerait \`a introduire les notions de fr\`ere et s\oe ur. Le logiciel pourrait 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 pourrez sp\'ecifier des extensions du logiciel en indiquant les modifications qu'il faudrait apporter \`a votre logiciel initial pour qu'il comprenne de nouvelles notions. L'id\'eal \''etant que vos structures de donn\'ees soient pr\'evues pour faciliter ces extensions. \section{Gestion d'une biblioth\`eque} %\label{sec:biblio} 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. Le logiciel est destin\'e principalement au biblioth\'ecaire d'un petit coll\`ege de $12$ classes dont la biblioth\`eque contient environ un millier de livres. C'est le biblioth\'ecaire qui g\`erera les emprunts, les rendus d'ouvrages et les retards, ainsi que les inscriptions/desinscriptions des emprunteurs. Il g\'erera aussi le stock de livres et pourra ajouter, retirer un livre ou modifier l'\'etat d'un livre. Le logiciel permettra \'egalement \`a un utilisateur anonyme de rechercher un livre par auteur et/ou par titre, et de savoir s'il est disponible ou non en rayon. Si vous pensez g\'erer la biblioth\`eque avec des fichiers, 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} Vous pourrez utiliser les outils Flex et Bison pour analyser les fichiers stockant les informations relatives \`a la biblioth\`eque, ou encore utiliser une BD. %\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. %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 %epr\'esentent la matrice par des listes. %\newpage %\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. %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} %\section{Polyn\^omes} %\label{poly} %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{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) qui sera propri\'etaire de l'annonce, i.e. le seul \`a pouvoir la supprimer. 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. On peut aussi envisager de proposer ce service sur une page web. Vous pourrez aussi envisager de d\'evelopper d'autres fonctionnalit\'es. \section{Assembleur MAMIAS} MAMIAS est un mini-langage assembleur (pour une machine virtuelle) utilis\'e pour l'enseignement en premier cycle. Le logiciel lira un fichier source contenant un texte de programme \'ecrit en MAMIAS, et il g\'en\'erera un fichier binaire contenant le code machine de ce programme. On pourra alors simuler un chargement de ce programme en m\'emoire centrale. Les lignes d'instructions seront plac\'ees dans les registres et on pourra ex\'ecuter le programme pas \`a pas. ~ \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\'e par une "expression mn\'emonique'' (ce n'est pas ce que MAMIAS est cens\'e lire: il ne comprend que les codes des 3 bits, mais cela rendra le logiciel plus lisible). Les 8 op\'erations et l'effet des instructions correspondantes sont les suivants (o\`u le symbole $\leftarrow$ d\'esigne 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.15cm} Sauf avis contraire (sp\'ecifi\'e par l'op\'eration \texttt{SAUTE}), les instructions s'ex\'ecutent dans l'ordre des adresses croissantes, \`a partir de $0$. ~ 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\\ & ....\\ & STOP \end{tabular} \vskip 3mm o\`u les deux premi\`eres lignes d\'efinissent des 'variables', et dont les suivantes sont les instructions du programme \'ecrites ici dans une notation symbolique. Un tel programme sera d'au plus 31 lignes (les 31 mots m\'emoire de la m\'emoire centrale). ~ Le logiciel g\'en\'erera un fichier binaire contenant le code binaire de ce programme (on a substitu\'e \`a chaque op\'eration symbolique son Code sur 3 digits, remplac\'e les variables tenant lieu de mot m\'emoire par le code binaire de l'entier correspondant, et substitu\'e \`a l'adresse symbolique "suite" l'adresse 4 en binaire (soit 00100) puisque c'\'etait la cinqui\`eme ligne du programme (num\'erot\'ee \`a partir de 0) qui \'etait labelis\'e "suite". Ainsi, le programme pr\'ec\'edent aura pour code %\vskip 3mm \begin{tabular}{lll} \\ & 000 &00000\\ & 001 &11111\\ & 100 &00100\\ & 010 &11110\\ & 101 &11111\\ & ....\\ & 111 &10110\\ \end{tabular} %\vskip 3mm \vskip 5mm Vous \'ecrirez aussi un outil de visualisation de la m\'emoire centrale permettant d'ex\'ecuter un programme MAMIAS pas \`a pas. (La m\'emoire centrale est constitu\'ee de l'\'etat des 32 registres et de celui de l'accumulateur). \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. Le logiciel d\'evelopp\'e doit poss\'eder les fonctionnalit\'es suivantes: connexion d'un futur joueur, affichage des parties en cours, affichage des joueurs en attente de partie, mise en relation de deux joueurs en qu\^ete de jeu. On peut aussi pr\'evoir que les joueurs d\'eclarent un niveau d'expertise afin de jouer contre un joueur de m\^eme force. On doit pouvoir jouer une partie \`a distance, chaque joueur visualisant le m\^eme plateau que son adversaire sur son \'ecran. Le d\'eplacement des pi\`eces de l'\'echiquier pourra \^etre effectu\'e en cliquant avec la souris sur les cases du plateau. Seuls les mouvements autoris\'es pourront \^etre r\'ealis\'es. On doit \'egalement pouvoir sauvegarder une partie en cours, afin de la recharger plus tard si les deux joueurs participant sont connect\'es. \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\'ematicien 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 (car il y en a moins pour les cases situ\'ees sur les bords ou dans 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} 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 plus rapide dont la vitesse pourra \^etre fix\'ee. On doit \'egalement pouvoir \`a tout moment interrompre cette simulation et sauvegarder l'\'etat d'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. Le logiciel permettra le chargement et la lecture de tels fichiers. Vous pourrez d\'efinir un format naturel de fichier de sauvegarde sous forme de lignes constitu\'e de 0 et de 1(s\'epar\'es par des caract\`eres blancs) pour d\'efinir la pr\'esence ou l'absence de cellules sur la grille, et en permettre l'\'edition dans un \'editeur de texte normal. Mais vous permettrez aussi une \'edition et une interaction graphique (avec la souris) plus sophistiqu\'ee (vous pourrez vous inspirer de l'interface graphique de la commande bitmap) permettant de cr\'eer une grille et d'y placer des cellules. ~ 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 d'une simulation \item lancer une simulation en mode pas \`a pas ou automatique \item interrompre une simulation \item permettre \`a l'utilisateur de modifier l'\'etat du jeu pendant son d\'eroulement \item sauvegarder/recharger l'\'etat d'une grille \`a partir d'un fichier \end{itemize} \newpage ~ \begin{center} Exemple d'\'evolution d'une grille de dimension 11x11 \end{center} \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} } \begin{tabular}{cc} \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}\\ \'Etape 10&\'Etape 11\\ \end{tabular} \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. 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} Des circuits pouront \^etre 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} }\\ Un tel fichier pourra \^etre analys\'e par le logiciel, et la syntaxe v\'erifi\'ee. ~ Vous inclurez les fonctionnalit\'es suivantes~: \begin{itemize} \item produire la table de v\'erit\'e d'un circuit (tableau dont les colonnes contiennent les valeurs en entr\'ee et les valeurs en sortie) et l'afficher. La sauvegarder dans un fichier. \item \'editer un circuit avec le logiciel sous forme textuelle (fichier) ou sous forme graphique \item modifier un circuit: ajouter d'autres composants~: noeud1-2 (noeuds qui envoient sur leurs deux sorties la m\^eme chose que ce qu'ils ont en entr\'ee), multiplexeurs, etc. \item et animer les circuits (difficile) \end{itemize} %\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{Th\'ematiseur g\'en\'eral} %\label{sec:thematiseur} %\paragraph{Nombre d'\'etudiants maximum~: 3.} Un th\'ematiseur g\'en\'eral est un logiciel qui permet de cat\'egoriser un document en d\'eterminant les th\`emes dont il parle. il prend en entr\'ee un document et retourne une liste de th\`emes correspondants au contenu du document (par exemple : science, tourisme, humour, horoscope, etc.). Un document est un fichier texte. 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 ou des caract\`eres de ponctuation. Un th\'ematiseur g\'en\'eral fait appel \`a des th\'ematiseurs sp\'ecialis\'es (pour un th\`eme). Un th\'ematiseur sp\'ecialis\'e est initialis\'e pour un th\`eme particulier, par exemple "Science". Il a comme ressource une liste de mots (mots th\'ematiques) correspondant au th\`eme. Par exemple pour le th\`eme "Science" les mots 'informatique', 'physique', 'chimie', 'fonction', 'math\'ematique', 'd\'emonstration', 'preuve' etc. feront partie de sa liste de mots-cl\'es. Sa fonction principale, \'etant donn\'e un document, est de retourner le pourcentage de mots du document qui font partie de sa liste de mots th\'ematiques. Si ce pourcentage est sup\'erieur \`a un certain seuil, le document est consid\'er\'e comme rattach\'e \`a ce th\`eme. Un th\'ematiseur g\'en\'eral doit consulter tous les th\'ematiseurs sp\'ecialis\'es pour d\'ecouvrir les th\`emes correspondant au document, mais l'utilisateur pourra 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 dans un sous-ensemble de th\`emes initiaux. L'utilisateur doit aussi pouvoir interroger le th\'ematiseur sur l'appartenance d'un document \`a un th\`eme donn\'e, et modifier les seuils d\'efinis pour chaque th\`eme particulier. Il devrait aussi pouvoir d\'efinir de nouveaux th\`emes \`a partir d'une liste de mots-cl\'es et d'un seuil. Le logiciel aura une interface graphique permettant de charger le fichier d'un texte, de fixer des seuils, et de lancer la recherche de th\`emes. On pourra aussi entrer des listes de mots-cl\'es th\'ematiques permettant de cr\'eer ou d'enrichir de nouveaux th\'ematiseurs sp\'ecialis\'es. On peut imaginer diverses fonctionnalit\'es ayant trait aux th\'ematiseurs sp\'ecialis\'es comme au th\'ematiseur g\'en\'eral. Le logiciel pourra utiliser une base de donn\'ees pour enregistrer les mots-cl\'es associ\'es aux th\'ematiseurs sp\'ecialis\'es. On pourra pr\'evoir une interface graphique, ou encore un site web. A vous de sp\'ecifier clairement le logiciel et son architecture. \paragraph ~ Quelques id\'ees pour vous permettre d'impl\'ementer un jeu d'essais : ~ 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 \section{R\'eservation de chambres d'h\^otel} Le logiciel est destin\'e au directeur d'un h\^otel d'une vingtaine de chambres. Il doit pouvoir enregistrer des r\'eservations, afficher le planning des disponibilit\'es et proc\'eder \`a toute op\'eration. Le logiciel sera \'egalement accessible via un site web aux futurs clients qui pourront l'utiliser pour consulter les disponibilit\'es et faire des r\'eservations en ligne. Il y a tout un travail de conception et de sp\'ecification \`a faire pour r\'ealiser ce projet, et l'on s'inspirera des sites de r\'eservations d'h\^otels existants. %\section{Apprendre \`a r\'esoudre des \'equations lin\'eaires} %difficile ? %Il s'agit d'\'ecrire un logiciel p\'edagogique, destin\'e \`a des \'el\`eves de cinqui\`eme apprenant \`a r\'esoudre des \'equations et des syst\`emes d'\'equations du premier degr\'e. Le logiciel doit leur apprendre \`a manipuler une \'equation pour la r\'esoudre (en ajoutant de chaque c\^ot\'e du signe = une m\^eme constante ou combinaison de variables, ou en effectuant une m\^eme op\'eration de multiplication), et les entrainer ensuite \`a r\'esoudre des syst\`emes de plusieurs \'equations. %Certaines r\`egles comme "quand on passe un terme de l'autre c\^ot\'e du signe =, on change son signe, illustr\'ee ici par le passage de\\ %4x \textbf{+ 3} = 12 \ \ \ \`a \ \ \ % \ \ %4x = 12 \textbf{- 3} ,\\ %seront justifi\'ees d'abord math\'ematiquement, puis anim\'ee graphiquement pour aider l'\'el\`eve \`a appliquer des r\`egles finalement visuelles et graphiques. On pourra faire des exercices pour s'entrainer \`a appliquer ces r\`egles. %\section{Logiciel pour apprendre \`a taper \`a la machine} %Le logiciel propose \`a l'utilisateur de taper des mots simples, sans regarder son clavier, et en mettant le doigt\'e recommand\'e. Si l'utilisateur fait des fautes de frappe, l'ordinateur lui propose dans la s\'equence suivante de taper une s\'erie r\'ep\'etitive de mots appropri\'es, contenant en quelque sorte l'"erreur" (comme papa rapa papa rapa papa rapa, ....., papa rapa, si l'utilisateur avait fait une faute sur pa apr\`es un mot finissant par r). %Une fois l'utilisateur entrain\'e sur toutes les touches, le programme lui propose de taper un texte, et lui redonne une s\'erie d'exercices simples avec quelques mots correspondant aux fauxtes de frappe qu'il aura fait dans le texte initial. % \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{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. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %\section{Gestion de comptes bancaires} % \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\%$. On fera le calcul de ses int\'er\^ets sur l'ann\'ee, compte tenu de ses d\'ep\^ots et retraits. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Motus} % \label{sec:motus} % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Il s'agit de simuler le jeu t\'el\'evisuel, pour que les joueurs puissent s'entrainer. Le logiciel pourra \^etre livr\'e comme application, ou accessible sur une page web. A titre d'exemple on pourra s'inspirer du jeu en ligne sur //motus.france2.fr/. Le but du jeu Motus est la d\'ecouverte d'un mot cach\'e de 7 lettres, en au plus 6 tentatives. Les diff\'erentes tentatives (proposition de mots) seront plac\'ees sur une grille de 6 rang\'ees (6x7 cases). Une variante serait de chercher un mot de 8 lettres en au plus 7 tentatives. Initialement, la premi\`ere lettre du mot recherch\'e est donn\'ee, et plac\'ee sur la premi\`ere case en haut de la grille. Si cette lettre figure plusieurs fois dans le mot, les diff\'erentes occurrences de la lettre seront plac\'ees correctement sur cette ligne, les autres cases restant vides. Le joueur doit alors proposer un mot de 7 lettres dans un d\'elai maximum de 8 secondes. Son mot est quelconque et peut ne pas commencer par la premi\`ere lettre fournie. Mais ce mot doit contenir exactement 7 lettres et \^etre correctement orthographi\'e. Si le mot n'existe pas, il est refus\'e et le logiciel ne renseigne pas le joueur sur les lettres propos\'ees sur la ligne. Si le mot est correct, les lettres bien plac\'ees sont colori\'ees en rouge, et les lettres mal plac\'ees entour\'ees d'un cercle jaune. Toute lettre du mot propos\'e qui est aussi dans le mot recherch\'e est signal\'ee, soit comme bien plac\'ee (si elle se situe \`a la bonne place) et elle appara\^it alors en rouge, soit comme mal plac\'ee, et elle est alors entour\'ee d'un cercle jaune. Pour une lettre, on ne peut avoir au maximum que le nombre d'occurrences de cette lettre dans le mot qui se retrouvent colori\'ees (soit en jaune, soit en rouge si certaines sont bien plac\'ees). Les coups s'enchainent alors, le joueur devant proposer un nouveau mot sur la ligne suivante dans le d\'elai maximum suppos\'e (fix\'e par d\'efaut ici \`a 8 secondes). Si le joueur trouve le mot en moins de 6 tentatives, il a gagn\'e, sinon, il a perdu, et la bonne r\'eponse s'affiche. On permettra au logiciel de fixer initialement la taille des mots (ici 7 lettres, mais ce nombre pourra varier de 6 \`a 10), ainsi que le nombre de coups (tentatives) maximal autoris\'e (ici 6) et la dur\'ee du d\'elai donn\'e au joueur pour entrer une nouvelle proposition (ici 8 secondes). Pour v\'erifier l'orthographe des mots propos\'es, on devra faire des recherches sur les composants TALN gratuits disponibles, afin de r\'eutiliser l'un d'entre eux . % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Organiseur (Agenda)} % \label{sec:organiseur} % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Un organiseur est un logiciel qui permet \`a un utilisateur de g\'erer (stocker, consulter) son emploi du temps tout au long de l'ann\'ee (c'est un Agenda). Le logiciel doit au moins permettre de noter des rendez-vous sur un an, de 6h00 \`a 23h00, \`a raison d'un rendez-vous par heure. L'organiseur devra permettre de modifier, stocker, et consulter facilement son emploi du temps. L'interface sera graphique et devra offrir des facilit\'es de consultation (affichage par mois, avec des fl\`eches permettant d'avancer mois par mois, ou semaine par semaine). %\section{Gestionnaire d'occupation de salles} %Les salles de cours d'une universit\'e comme la n\^otre poss\`edent diverses caract\'eristiques %comme le nombre de places (ou nombre d'\'etudiants maximum), une localisation (b‰timent + nom ou num\'ero), un type (salle machines, salle TP, salle TD, amphi). Elles sont destin\'ees \`a \^etre occup\'ees par une formation (Licence d'informatique, Fili\`eres d'ing\'entiers, etc. voir la liste des formation propos\'ees sur le site de l'institut Galil\'ee) et un groupe, sur un certain cr\'eneau horaire. %Une salle ne peut \^etre occup\'ee que par un groupe d'une seule formation universitaire \`a la fois. %Le gestionnaire d'occupation des salles de l'Universit\'e doit permettre la consultation du planning d'occupation des salles, et sa modification (r\'eservation ou annulation de r\'eservation sur un cr\'eneau horaire et pour un groupe donn\'e). On souhaite aussi qu'il fasse des propositions de salles disponibles quand on lui soumet une demande (pour un groupe d'\'etudiants dont on connait le nombre, et un type de salle demand\'ee). %droits de consultation et droits de modification %affichage de l'emploi du temps d'une formation en fonction des salles que cette formation occupe %afficahge de l'occupation d'une salle pour une semaine ou un mois donne %recherche d'une salle d'un type donne pour une formation donn\'ee \section{Jeu de taquin} Le taquin est un jeu solitaire en forme de damier cr\'e\'e vers 1870 aux Etats-Unis. Il est compos\'e de 15 petits carreaux num\'erot\'es de 1 \`a 15 qui glissent dans un cadre pr\'evu pour 16. Il y a donc une case vide. Le jeu consiste \`a remettre dans l'ordre les 15 carreaux \`a partir d'une configuration initiale quelconque, en d\'epla\c{c}ant \`a chaque coup un carreau voisin de la case vide (horizontalement ou verticalement), et cela en un minimum de coups. L'interaction avec le damier pour d\'eplacer les carreaux se fera avec la souris. %En plusieurs version: chiffres, ou image. possibilit\'e de charger une image de fond. On consultera la page wikipedia https://fr.wikipedia.org/wiki/Taquin pour des informations sur les configurations solubles et insolubles. Sachez en tous cas que si vous g\'en\'erez une disposition al\'eatoire de nombres dans les cases, vous risquez de proposer un jeu sans solution. Mais votre jeu ne doit bien entendu soumettre que des probl\`emes ayant une solution. %\includegraphics{taquin.pdf} \begin{center} \includefigtr{taquin}{scale=0.5}{scale=0.5} \\ Exemple de Jeu de Taquin \end{center} L'utilisateur pourra \`a tout moment interrompre la partie et sauver la configuration du damier afin de la recharger plus tard. Am\'elioration : Le logiciel pourra proposer aussi une version dans laquelle on peut choisir une image de fond \`a reconstituer. L'image sera d\'ecoup\'ee en 16 morceaux et 15 d'entre eux seront dispos\'es sur les carreaux. Le jeu ressemblera alors \`a un puzzle. On pourra aussi proposer une variante dans laquelle le nombre de carreaux pourra \^etre choisi avant de commencer \`a jouer. \section{Borne de location de films} On s'int\'eresse \`a la programmation d'une application permettant d'emprunter des DVD de films (disponible sur des bornes de distribution semblables aux distributeurs de billets). On pourra interroger la borne concernant la disponibilit\'e d'un film donn\'e. Un film aura pour caract\'eristiques un titre, un (ou plusieurs) r\'ealisateur, des acteurs, une langue originale et une ann\'ee de sortie. A un film pourra correspondre plusieurs exemplaires de DVD aux caract\'eristiques de langues \'eventuellement diff\'erentes. Les DVD pourront \^etre disponibles ou en location avec une date de retour pr\'evue. L'utilisateur aura acc\`es aux informations concernant les langues audio disponibles, et les langues des sous-titres pr\'esentes sur un DVD. Il pourra effectuer des recherches multi crit\`eres, sur les films et les DVD disponibles associ\'es. Si un DVD est disponible, il pourra en obtenir la location pour un temps d\'etermin\'e, et sortir le DVD apr\`es communication de son num\'ero de carte bleue (qui permettra aussi de l'identifier comme emprunteur). Le logiciel comportera les fonctionnalit\'es suivantes: Recherche de film (avec un ou plusieurs crit\`eres, on pourra \'egalement rechercher un film par mot cl\'es apparaissant dans le titre), et Recherche de DVD associ\'es (langues); Affichage de l'\'etat des DVD associ\'es disponibles; Emprunt de DVD; Retour d'un DVD; Facturation (\'emission d'une facture indiquant le prix factur\'e en cas de retour dans les temps, et indication de la somme pr\'elev\'ee en cas de retard. En cas de retard, un certain montant - correspondant au prix de vente du DVD, sera en effet pr\'elev\'e automatiquement sur la carte bleue. On utilisera une base de donn\'ees pour inventorier les films et les DVD associ\'es, ainsi que g\'erer les emprunts des clients. Les clients seront r\'epertori\'es dans la base de donn\'ees par leur num\'ero de carte bleue, saisi automatiquement lorsqu'ils se connecteront \`a la borne. On ne d\'eveloppera pas l'interface de la borne proprement dite, mais on simulera une connexion d'utilisateur par l'entr\'ee d'un num\'ero l'identifiant (son num\'euro de carte bleue). L'interface sera ici une interface graphique permettant d'effectuer des recherches dans la base de donn\'ees, d'obtenir une locationn de DVD ou de rendre un DVD. On pourra aussi consulter l'\'etat de ses diff\'erents emprunts en cours. Pour la gestion des films, un utilisateur particulier (l'administrateur) pourra cr\'mer de nouveaux films et de nouveaux DVD. Il sera aussi habilit\'e \`a modifier lun film, ou \`a en supprimer de la base. %\section{Roulette} % \label{sec:roulette} % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Plusieurs 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. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Master Mind} %\label{sec:mastermind} %\paragraph{Nombre d'\'etudiants maximum~: 3.} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Le but du jeu est de retrouver une combinaison ordonn\'ee de 4 couleurs. Plus pr\'ecis\'ement, il s'agit de d\'ecouvrir une rang\'ee (cach\'ee) de 4 billes de couleurs (le nombre de billes d'une rang\'ee et le nombre de couleurs possibles pourra varier en fonction du niveau de difficult\'e souhait\'e). ~ D\'eroulement du jeu: Une rang\'ee secr\`ete (ou combinaison) est choisie par l'ordinateur. Le joueur qui cherche \`a la d\'ecouvrir propose alors sur une ligne une rang\'ee de 4 billes de couleurs. Le programme lui indique alors (sous forme de points noirs et de points blancs) combien de billes sont bien plac\'ees (i.e. sont de la bonne couleur et \`a la bonne place dans la rang\'ee), et combien de billes sont mal plac\'ees (i.e. sont d'une couleur appartenant \`a la combinaison, mais pas \`a la bonne place dans la rang\'ee). Pour cela il affiche des points, noir ou blanc en guise de r\'eponse, \`a c\^ot\'e de la rang\'ee propos\'ee. \begin{itemize} \item Un \textbf{point noir} indique la pr\'esence d'une bille bien plac\'ee (mais ne pr\'ecise pas laquelle, i.e. ne pr\'ecise ni sa couleur, ni son emplacement dans la rang\'ee) \item Un \textbf{point blanc} indique qu'il existe une bille d'une bonne couleur qui est mal plac\'ee (mais ne pr\'ecise ni la couleur, ni son emplacement sur la ligne) \end{itemize} ~ A l'aide de ces informations, le joueur peut proposer une nouvelle rang\'ee de billes de couleurs sur une deuxi\`eme ligne. L'ordinateur lui r\'epond \`a nouveau par un certain nombre de points noirs ou blancs, ce qui lui fournit encore d'autres informations, combinables avec les pr\'ec\'edentes. Le joueur peut alors entrer une nouvelle rang\'ee sur une nouvelle ligne, et ainsi de suite. Les lignes restent affich\'ees (avec leurs points blancs et noirs en vis-\`a-vis) sur un m\^eme plateau, et permettent au joueur de faire des hypoth\`eses sur l'appariement des points (noirs ou blancs) et des billes sur chaque ligne. Cela lui permet de raisonner avant de faire une nouvelle proposition. Au bout de 10 lignes propos\'ees sans d\'ecouvrir la bonne combinaison, le joueur a perdu, et la combinaison secr\`ete s'affiche. A l'inverse, s'il obtient sur une ligne une r\'eponse de 4 points noirs avant la dixi\`eme ligne, c'est qu'il a d\'ecouvert la bonne combinaison et qu'il a gagn\'e. %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. On pourra aussi pr\'evoir d'affecter un score au joueur. Dans ce cas, il y aura une base de donn\'ees de joueurs sauvegardant leurs scores et leur pseudonymes. On aura une architecture Client/Serveur permettant la connexion, l'inscription au jeu, l'enregistrement et la consultation des scores. On peut aussi pr\'evoir l'affichage des meilleurs scores. ~ Le jeu de Mastermind du site \url{http://www.litterales.com/jeux} devrait vous aider \`a comprendre le jeu et \`a pr\'eciser les fonctionnalit\'es du logiciel que vous souhaiterez d\'evelopper. Parmi celles-ci vous ajouterez la possibilit\'e de modifier le nombre de billes de la combinaison (5 billes aulieu de 4). Le joueur devrait \'egalement pouvoir choisir le nombre de couleurs avec lesquelles il doit jouer. (Vous fixerez par exemple un nombre de couleurs maximum, et l'utilisateur pourra choisir de jouer avec un nombre plus petit de couleurs. Une fois le nombre de couleurs fix\'e, les couleurs seront impos\'ees par le programme et affich\'ees pour que le joueur sache avec quelles couleurs jouer). Remarque: on peut aussi pr\'evoir un mode de jeu \`a deux joueurs. Dans ce cas, l'un des joueurs choisira la combinaison \`a d\'ecouvrir par l'autre. L'application aura une architecture Client/Serveur ce qui permettra \`a plusieurs joueurs de se connecter, et l'interface pourra \^etre une interface graphique classique, ou une page web. \section{Le jeu Othello} % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Le jeu Othello, appel\'e aussi Reversi, se joue sur un damier de 8$\times$8 cases. Les pions ont deux faces de couleurs diff\'erentes~: l'une blanche, l'autre noire. Chaque joueur choisit une couleur au d\'ebut du jeu, et le but est de colorier le plus de cases possible de l'\'echiquier avec sa couleur. Au d\'ebut du jeu, chaque joueur dispose deux de ses pions dans sa couleur en diagonale au centre du damier. Le joueur qui a les blancs commence alors \`a jouer en pla\c{c}ant un pion sur une case vide en respectant les conditions suivantes~: \begin{itemize} \item le pion est plac\'e de fa\c{c}on \`a former un alignement vertical, horizontal ou diagonal avec un autre pion de m\^eme couleur~; \item 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 de jouer. \item Si un joueur ne peut pas jouer, il passe son tour (autant de fois que n\'ecessaire). \end{itemize} Le jeu s'arr\^ete lorsque le damier est plein ou lorsque plus personne ne peut jouer. On compte alors le nombre de cases occup\'ees par chaque couleur. Le gagnant est le joueur dont les pions occupent le plus grand nombre de cases. Le logiciel d\'evelopp\'e aura une architecture client/serveur et permettra \`a deux joueurs connect\'es sur des machines diff\'erentes de jouer sur un m\^eme plateau. Le serveur g\'erera les connexion/inscription des joueurs, le lancement d'une partie, sa sauvegarde (en cours de partie, pour pouvoir la finir plus tard), le chargement de partie interrompue. L'interface utilisateur propos\'ee sera une interface graphique. %\section{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 %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. \section{Le compte est bon} Il s'agit dans un premier temps de permettre \`a un utilisateur de s'entrainer au jeu t\'el\'evis\'e "Des chiffres et des lettres" concernant la partie "chiffres" du jeu. Ensuite, on permettra \`a deux joueurs de s'affronter, en r\'eseau, sur une s\'erie de dix tirages constituant une partie. Les r\`egles du jeu sont de former un nombre approchant au mieux un nombre compris entre 0 et 999 tir\'e al\'eatoirement, en utilisant (au maximum une fois) 6 nombres, tir\'es \'egalement au hasard parmi les nombres suivants: 1, 2, 3, ..., 9, 10, 25, 50, 75 et 100. Les six nombres peuvent \^etre combin\'es \`a l'aide des op\'erations arithm\'etiques de base: addition, soustraction, multiplication et division (enti\`ere). Ainsi par exemple, pour atteindre le nombre 266 avec les six nombres: 3, 75, 10, 4, 25 et 2, on peut proposer le calcul en trois op\'erations : 25 + 2 = 27 27 x 10 = 270 270 - 4 = 266\\ Ce n'est pas la seule solution, car on peut aussi faire d'autres calculs, comme par exemple : 3 x 75 = 225 225 + 25 = 250 250 + 10 = 260 4 + 2 = 6 260 + 6 = 266\\ Une fois le tirage du nombre \`a atteindre et des 6 nombres \`a utilis\'es affich\'e, le ou les joueurs ont 45 secondes pour trouver une combinaison exacte, ou un calcul approch\'e. (En mode d'entrainement mono joueur, le joueur pourra modifier ce temps et b\'en\'eficier de plus de secondes). Si un joueur trouve le nombre exact dans le temps imparti, il marque 10 points. Il marque \'egalement 10 points si le nombre qu'il obtient est la meilleure approximation possible du nombre cherch\'e. En mode deux joueurs, s'il trouve un nombre approchant meilleur que celui trouv\'e par son adversaire, il marque seul 7 points. Si les deux joueurs trouvent la m\^eme approximation, ils marqueront tous les deux 7 points. L'ordinateur proposera dans tous les cas un "meilleur" calcul, c'est-\`a-dire un calcul d\'ecomposable en le minimum d'op\'erations possibles. L'interface devra \^etre plaisante et aussi conviviale que possible. On pourra s'inspirer de l'application disponible sur tablette intitul\'ee "DesChiffres&DesLettres" qui est tr\`es r\'eussie. On pourra aussi regarder l'application en ligne du site france3.fr pour apprendre les r\`egles du jeu, mais l'interface est moins agr\'eable. \section{Bataille navale} % \label{sec:batnav} % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Initialement, chaque joueur place des bateaux de diff\'erents types sur une grille. Puis, chacun son tour, chaque joueur essaie de tirer sur les bateaux ennemis en donnant les coordonn\'ees d'une case adverse. Si le tir tombe \`a proximit\'e d'une case d'un bateau, le programme le signale par un message ``bateau manqu\'e'' (sauf si la grille n'est pas suffisamment grande, auquel cas il n'y a aucun message). Si la case atteinte est occup\'ee par un bateau, le programme doit le signaler par un message ``bateau de type T touch\'e'' (et la case atteinte sera alors marqu\'ee sp\'ecialement). Si le bateau est enti\'erement touch\'e (toutes ses cases ont \'et\'e d\'ecouvertes), il est alors consid\'er\'e comme coul\'e, sa repr\'esentation sera modifi\'ee et un message affich\'e. Le joueur qui r\'eussit \`a couler tous les bateaux ennemis le premier gagne la partie. On d\'efinira plusieurs types de bateaux (occupant plus ou moins de cases): torpilleurs, sous-marins, fr\'egates, porte-avions, etc. Le plus simple \'etant d'avoir des bateaux occupant de une \`a quatre cases (horizontales ou verticales). On pourra aussi sp\'ecifier la taille de la grille, et cela d\'eterminera le nombre et le type de bateaux qu'un joueur devra disposer sur sa grille. Ces informations seront clairement indiqu\'ees sur l'interface. La taille de grille par d\'efaut sera de10x10 cases (les cases seront num\'erot\'ees de 1 \`a 10 et de A \`a J, en ligne/colonne). Le joueur devra valider sa configuration de bateaux avant de commencer \`a jouer. (Pour vous inspirez concernant l'interface utilisateur, vous pouvez consulter le jeu en ligne http://fr.battleship-game.org ou encore http://boomboomboat.com). Le logiciel proposera deux modes de jeu: en mode individuel, le joueur jouera contre l'ordinateur, qui tiendra lieu de second joueur; en mode 2 joueurs, le joueur se connectera sur un serveur dans l'attente d'un adversaire contre qui jouer. Le logiciel affichera initialement une interface comportant deux grilles: celle du joueur (sur laquelle il devra disposer ses bateaux) et celle de l'adversaire (initialement vide). Chaque joueur pourra voir les coups port\'es par son adversaire sur sa propre grille, et les coups qu'il porte lui-m\^eme sur la grille de l'adversaire. Lorsqu'un bateau est touch\'e, les cases touch\'ees apparaitront dans un marquage diff\'erent. En mode individuel (mono-utilisateur), le joueur pourra interrompre sa partie en cours contre l'ordinateur, et la sauvegarder pour la reprendre plus tard. Le logiciel peut \^etre une application lanc\'ee sur une machine potentiellement distante de la machine sur laquelle tourne le serveur (architecture client/serveur), ou pr\'esenter initialement son interface sur une page web. %\section{À la manière de} %Il s'agit d'\`ecrire un logiciel permettant de jouer au jeu "à la manière de". %Ce jeu se joue à plusieurs joueurs. %A chaque tour de jeu, chaque joueur peut voir un d\`ebut de citation, %ainsi que le nom de l'auteur et de l'oeuvre. %Chaque joueur doit proposer une fin de phrase plausible pour la citation. %Il se voit ensuite proposer les r\`eponses des autres joueurs %et la bonne r\`eponse sans indication de leur provenance, %et doit voter pour celle qu'il pense être de l'auteur. %Il marque un point si il devine juste, %et marque un point par joueur ayant vot\`e pour sa phrase. %Après un nombre de tour d\`ecid\`e au d\`ebut, le joueur avec le plus de points gagne. %Il faudra une architecture client serveur. Il faut penser à d\`efinir ce qu'il se passe si plusieurs joueurs donnent la même phrase, ou donnent la phrase de l'auteur. %Exemple : %Il y a 3 joueurs. %La phrase propos\`ee par le jeu est : \\ %"Les hommes vraiment g\`en\`ereux sont toujours prêts à devenir compatissants, lorsque...", Alexandre Dumas, {\it Le comte de Monte-cristo}. %Joueur 1 propose : "...l'on torture un petit chaton sous leurs yeux."\\ %Joueur 2 propose : "...leur femme leur lance un regard noir."\\ %Joueur 3 propose : "...leurs adversaires ont d\`ejà repay\`e leur dettes."\\ %La bonne r\`eponse est "...le malheur de leur ennemi d\`epasse les limites de leur haine."\\ %Donc si le joueur 1 et 3 votent pour la phrase de l'auteur, et le joueur 2 pour la phrase du joueur 3, %le joueur 1 marque 1 point, le joueur 2 marque 0 points, et le joueur 3 marque 2 points (il a devin\`e la phrase de l'auteur et on a vot\`e pour se phrase). % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % \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{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. \section{Appli Smartphone: Qui-est-ce ?} L'application permet de jouer au c\'el\`ebre jeu de soci\'et\'e 'Qui est ce ?' sur un t\'el\'ephone portable (dot\'e d'un syst\`eme Android), en se connectant au r\'eseau. Une partie de 'Qui-est-ce ?' se joue \`a deux joueurs. Chaque joueur dispose d'un plateau sur lequel sont repr\'esent\'es des personnages (normalement 24). Au d\'ebut de la partie, chaque joueur choisit secr\`etement l'un de ces personnages. Le but du jeu est alors de deviner le personnage choisi par l'adversaire, en posant des questions sur son apparence physique et sur sa personnalit\'e. Chaque joueur pose \`a tour de r\^ole une question \`a son adversaire, question pour laquelle il est possible de r\'epondre par oui ou par non. Le premier joueur \`a deviner l'identit\'e du personnage choisi par son adversaire gagne la partie. ~ Les principaux objets composant l'application sont : \begin{itemize} \item des joueurs, acteurs principaux du jeu \item des parties opposant deux joueurs \end{itemize} Chaque partie est constitu\'ee : \begin{itemize} \item d'un plateau contenant la liste des personnages \item d'une interface de dialogue permettant de poser les questions \`a l'autre joueur \end{itemize} Les t\^aches principales pouvant \^etre effectu\'ees par un utilisateur seront : \begin{itemize} \item s'inscrire (se connecter) sur le logiciel et ainsi devenir joueur \item jouer une partie, soit en choisissant un adversaire, soit en acceptant une partie propos\'ee par un autre joueur connect\'e. \end{itemize} Lors d'une partie, le joueur pourra : \begin{itemize} \item voir le plateau de jeu correspondant \`a sa partie et interagir avec (\'eliminer, choisir ou proposer un personnage) \item poser des questions \`a son adversaire et lui r\'epondre, quitter l'application. \end{itemize} \section{Appli Smartphone: Qu'est-ce qu'on mange ce soir ?} Cette application est une application Smartphone, et tourne sur un t\'el\'ephone muni d'un syst\`eme Andro\¬id. Elle permet de trouver des recettes ludiques utilisant des ingr\'edients particuliers (les restes du frigo ou des placards). On effectue des recherches de recettes (ou de video) en partant de la liste des ingr\'edients avec lesquels on souhaite cuisiner. On pourra dans cette recherche pr\'eciser \'eventuellement la nature du plat que l'on veut cuisiner: entr\'ee, plat ou dessert. \section{Appli Smartphone: Gestion de comptes} %%\paragraph{Nombre d'\`etudiants maximum~: 4.} Il s'agit d'\'ecrire une appli permettant de g\'erer les comptes d'une colocation ou de vacances entre amis. Il y a plusieurs utilisateurs, et chacun peut y ajouter une facture de frais collectif. Le logiciel devra utiliser une architecture client-serveur (pour que chacun puisse ajouter lui-m\^eme ses factures). On pourra s'inscrire sur l'appli initialement pour adh\'erer \`a un groupe, puis chacun y entrera ses frais, et on pourra aussi demander le calcul du solde des comptes, qui indiquera combien on doit d'argent et \`a qui si l'on a un solde n\'egatif, et dans le cas inverse, qui doit nous rembourser quelle somme.\\ Exemple : On a des vacances partag\'ees entre Albert, Bertrand, Christophe et Daniel. Daniel a pay\'e 150€ d'essence. Bertand a pay\'e 350€ de logement. Christophe a pay\'e 300€ de courses diverses. La balance totale est donc de -50€ pour Daniel, 150€ pour Bertrand, 100€ pour Christophe and -200€ pour Albert (la somme est bien entendu toujours 0). Donc Albert doit verser 200€ et Daniel 50€ pour rembourser Bertrand et Christophe. L'appli pourra proposer \`a Albert de donner 150€ \`a Bertrand et 50€ \`a Christophe, et \`a Daniel de donner 50€ \`a Christophe. \end{document}