I. Présentation▲
L'équipe Qt vous souhaite la bienvenue sur la page du deuxième défi Qt.
Les défis Qt sont des exercices à faire soi-même ou en équipe sur un sujet précis, à la manière des exercices de livres, dont le but principal est de s'amuser. Ces codes à écrire sont étudiés de sorte que tous y trouvent leur compte : parfois de l'algorithmique, mais pas uniquement, car Qt ne fait pas que dans ce domaine spécifique. Il s'agit d'un framework complet : les défis essayent d'exploiter cette richesse. Ceci ne signifie pas qu'aucune réflexion n'est nécessaire : il faut connaître Qt, il ne s'agit pas d'écrire quelques lignes sans y réfléchir.
Il y a plus d'un an, l'équipe Qt de Developpez.com vous proposait le premier défi Qt : un logiciel de génération de fractales. Ce défi vous a permis d'aborder les problématiques de la génération et de l'affichage d'images de grande taille, de travailler sur la création d'interface utilisateur et de gérer les threads.
Voici aujourd'hui le deuxième défi Qt : un logiciel de gestion de dossiers médicaux.
II. L'hôpital du futur▲
Imaginez l'hôpital du futur. L'ensemble des services, des appareils, des données des patients et des médecins reliés entre eux par un réseau. Le médecin n'aurait qu'à sortir sa tablette graphique pour avoir accès aux résultats biologiques de ses patients, recevoir des alertes lorsqu'un patient a un problème ou communiquer en vidéo avec le chirurgien de garde pour avoir un avis. De la haute technologie créée spécifiquement pour le domaine de la santé afin de sauver des vies.
Imaginez maintenant l'interface utilisateur associée...
III. Les données fournies▲
Pour vous éviter de rechercher des données graphiques pour illustrer votre application, nous vous proposons une archive de tels documents, disponibles sous licence Creative Common : data.7z ou data.zip.
Voici un petit descriptif des fichiers que vous pourrez y trouver, aussi en PDF dans l'archive.
III-A. 3D▲
Le répertoire " 3d " contient plusieurs fichiers " .trian ", chacun représentant un organe (os, peau, artères, etc.). Chaque fichier « .trian » est un fichier texte encodé selon le format suivant :
- la première ligne contient le nombre Np de points ;
- les Np lignes suivantes contiennent les points. Chaque ligne est constituée de trois nombres réels (x, y, z) séparés par des espaces. Le séparateur décimal utilisé est le point ;
- la ligne suivante contient le nombre Nt de triangles ;
- les Nt lignes suivantes contiennent les triangles. Chaque ligne est constituée de six nombres entiers : les trois premiers correspondent à l'index des trois points dans la liste de points formant le triangle, les trois derniers nombres ne sont pas utilisés.
Attention, l'objet 3D entier n'est pas normocentré (c'est-à-dire que son centre n'est pas en (0, 0, 0) et que qu'il n'est pas contenu dans une boîte (-1, -1, -1) et (1, 1, 1)). Il sera nécessaire d'adapter les paramètres de projection pour que l'objet soit correctement centré dans la vue 3D.
III-B. ECG▲
Le répertoire « ecg » contient un fichier texte représentant un électrocardiogramme. Chaque ligne contient un nombre, chaque nombre représente un point dans le graphe avec un intervalle de temps d'une milliseconde. Le séparateur décimal est la virgule.
III-C. Radio▲
Le répertoire « radio » contient une image radiographique. Plusieurs résolutions et découpages sont proposés :
- « radio.jpg » contient l'image originale ;
- les images « radio_y_x.jpg » contiennent les cent images issues du découpage de « height_resolution.jpg » par une grille de 10x10.
III-D. Scan▲
Le répertoire « scan » contient une animation d'un scanner. Les images de l'animation sont séparées dans des fichiers différents « scan_x.jpg ».
III-E. Sources▲
Les images sont issues de Wikipedia Common ou de http://www.websurg.com/softwares/vr-render/videos.php?lng=fr.
IV. Consignes▲
En laissant libre cours à votre imagination et en vous appuyant si vous le souhaitez sur les fichiers joints, vous devez créer le logiciel médical, divisé en deux programmes. Le premier est une application serveur. Le second est une application cliente, la « tablette » graphique.
Par « tablette », nous n'entendons pas les diverses technologies tactiles que l'on peut trouver de nos jours sur le marché. Ce mot-clé représente un concept qui caractérise une application fluide, flexible et esthétique.
Dans nos défis, nous aimons laisser une grande liberté aux participants afin de leur permettre d'exprimer pleinement leur créativité. Quoi de plus frustrant que d'être limité à devoir réaliser une interface utilisateur précise aux fonctionnalités données ? Certes, vous êtes libres, mais cette liberté va être atteinte par quelques restrictions détaillées dans la sous-partie suivante.
Le défi dure trois mois. Il débute le premier juin 2011 à minuit (00h00) et se termine le premier septembre à minuit (00h00). Les dernières participations pourront être rendues jusqu'à cette date, au-delà de laquelle elles ne seront pas acceptées. Toutefois, cette durée de réalisation est amplement suffisante pour avoir le temps d'élaborer une participation complète. En effet, elle est bien trop élevée pour la présentation d'une simple candidature, mais appropriée pour réaliser un logiciel complet, débordant de fonctionnalités, bien au-delà de ce qui est demandé ou proposé.
IV-A. Réalisation du logiciel médical▲
La réalisation du logiciel médical est une tâche importante. Toutefois, il est à noter qu'elle ne nécessite pas d'être un docteur diplômé en médecine pour être effectuée : la notation ne prendra bien entendu pas compte de l'absence d'une fonctionnalité disponible de nos jours dans les hôpitaux. Tout module imaginaire sera considéré comme un module existant, dans le sens où c'est l'aspect esthétique, la puissance des algorithmes et la qualité du code qui seront pris en compte à la notation.
En effet, l'objectif de ce défi est de vous exercer, de confronter et de joindre vos talents de développeurs à ceux des autres participants, non d'avoir à effectuer des recherches colossales sur le fonctionnement des appareils médicaux actuels.
IV-A-1. Restrictions▲
Bien entendu, certaines restrictions ont été posées sur la réalisation du logiciel. La première et la plus importante est que l'utilisation de Qt est obligatoire pour la réalisation des deux applications, cliente et serveur. De même, l'aspect multiplateforme doit être présent dans le logiciel final. À partir de ces deux points, vous êtes libres d'utiliser de divers langages, tant qu'ils ne les mettent pas en défaut (par exemple, le C++, le Java, Python sont autorisés, mais vous êtes libre d'utiliser tout autre langage, tant que le logiciel reste multiplateforme et que vous utilisez Qt, directement ou par un binding).
Nous souhaitons que l'utilisation d'une base de données (relationnelle ou non, SQL ou NoSQL, etc.) soit effectuée par le logiciel afin de donner des précisions sur le dossier médical d'un patient, le nom des employés, soit tout ce qui vous semble nécessaire. Ainsi, vous devrez vous appuyer sur le module QtSQL de Qt, que ce soit fait de manière directe ou non. Par « direct », nous entendons le fait que des bibliothèques basées sur Qt (par exemple, QxOrm) sont autorisées à condition, une fois de plus, de ne pas entraver la possibilité du logiciel de tourner sous plusieurs plateformes. L'autorisation de base de données non relationnelles nous oblige aussi à autoriser l'utilisation des API de ces bases de données.
Si vous souhaitez participer, il est hautement recommandé de vous présenter sur le forum du défi et de parler de votre participation. Cela vous permettra d'obtenir des avis, de l'aide et des idées.
Une dernière petite restriction déjà présente dans le précédent défi : la documentation de votre code. Vous n'aurez pas besoin d'effectuer une documentation exemplaire, mais un minimum est requis. Cette dernière pourra être rangée à la racine de l'archive à rendre si elle tient en un seul fichier (fichier texte, TEX, PDF, etc.), mais devra être dans un sous-dossier dans le cas contraire (par exemple, une documentation Doxygen). Se référer à la partie « Fichier à rendre » pour plus d'informations.
IV-A-2. Conseils▲
L'application cliente correspondant à l'application nécessitant le plus une ergonomie, de la fluidité et de la flexibilité, vous avez la possibilité d'utiliser Qt Quick pour sa réalisation. Si vous l'utilisez, ce sera un plus pour votre participation. Toutefois, son utilisation n'est pas obligatoire et, par conséquent, n'est incluse à la notation que dans les points bonus.
Commenter son code est conseillé. De là, il n'est pas nécessaire d'en abuser, car cela ne ferait qu'entraver la lisibilité du code. Il reste bon de garder en tête qu'un bon code n'a pas besoin d'être commenté, dans le sens où, combiné à la documentation, il est suffisamment explicite pour n'avoir pas besoin de commentaires.
IV-A-3. Suggestions de développement▲
Généralement, on préfère éviter de lâcher un développeur dans la nature sans aucune piste lorsqu'il s'agit de réaliser une application serveur et une application réseau. Les éléments qui suivent sont des suggestions et, en tant que telles, servent uniquement à vous orienter. Vous êtes libre d'en tenir compte ou de les ignorer.
Le serveur peut tout d'abord être configuré pour prendre en charge toutes les connections sur un port donné (par exemple, 45354). Dans ce cas, l'application cliente devrait créer un client TCP sur ce port sur l'adresse IP locale (127.0.0.1). À partir de là, la communication pourrait être faite.
On pourrait également partir du principe que le serveur vérifie à chaque message reçu que l'application cliente utilise un code de connexion valide. Ainsi, pour envoyer un message au serveur, il faudrait formater le message. Par exemple en le dotant :
- d'une chaîne de caractères contenant l'identifiant de connexion ;
- d'une chaîne de caractères contenant le mot de passe ;
- d'une chaîne de caractères contenant le message.
Selon le type de message, il serait possible d'ajouter d'autres paramètres.
En termes de modules disponibles dans l'application, on pourrait avoir une visionneuse de radios, un dispositif affichant les résultats d'analyses de sang, un autre permettant d'afficher le rythme cardiaque d'un patient, et ainsi de suite. Peu importe le fait que les données s'appuient sur des références réelles ou imaginaires. Si vous souhaitez mettre un taux de granulation du sang ou plutôt un taux de cholestérol, libre à vous !
Pour la base de données, nous n'avons pas de piste en particulier, étant donné la largeur des possibilités que vous offrent les différents types auxquels vous avez accès. À partir de là, vous pouvez la concevoir librement.
Des documents graphiques (images et modèles 3D) sont disponibles sous licence CC.
IV-B. Équipes▲
Vu l'ampleur du défi, il est recommandé de participer par équipes. Les équipes peuvent compter jusque trois personnes. Les présentations rendues par une équipe seront évaluées selon les mêmes critères, avec la même sévérité que les candidatures de personnes seules.
Afin de faciliter le travail en équipe pour ce défi, il est possible d'obtenir un dépôt Subversion ainsi qu'un espace Redmine. Ces outils sont principalement destinés aux équipes. Pour y avoir accès, il suffit d'en faire la demande à un membre organisateur.
IV-C. Fichier à rendre▲
Le fichier que vous rendrez au jury par l'intermédiaire de la page prévue à cet effet devra impérativement contenir un fichier de projet .pro. Si vous utilisez un EDI qui ne supporte pas ces fichiers, vous pouvez fournir le fichier de projet pour cet EDI en supplément.
Les fichiers source de votre application seront rangés dans un répertoire spécifique.
La documentation pourra être rangée à la racine de l'archive à rendre si elle tient en un seul fichier (fichier texte, TEX, PDF, etc.), mais devra être dans un sous-dossier dans le cas contraire (par exemple, une documentation Doxygen).
Aussi, vous fournirez un fichier de type README, dans lequel vous marquerez votre accord pour une éventuelle diffusion sur les pages Sources de Developpez.com. Vos sources seront libres de droits (open source). Vous y marquerez aussi votre environnement de développement (version de Qt, compilateur et version, système d'exploitation et version) pour en faciliter la correction.
Dans un autre fichier, vous décrirez brièvement votre projet et comment vous l'avez mené à bien (problèmes rencontrés, difficultés surmontées sans problème, recherche d'idées, idées abandonnées, le temps approximatif de développement, choix de tel algorithme, paradigme de conception...).
Toute proposition ne respectant pas ce point pourra être rejetée !
IV-D. Environnements cibles▲
Votre programme devra fonctionner avec Qt en version 4.6 ou 4.7. Vous devrez l'indiquer dans l'archive rendue afin de permettre au jury de tester les données avec la même configuration que vous.
Qt supportant par nature plusieurs compilateurs et systèmes d'exploitation, il est possible que votre code soit testé sous un autre environnement que celui que vous utilisez. Ceci ne doit changer en rien les parties qui utilisent directement Qt dans votre code.
Nous essayerons autant que possible de tester vos propositions avec la même configuration que vous, mais cela ne sera pas toujours possible.
V. Évaluation▲
V-A. Critères▲
Ces critères sont obligatoires : toute participation sera jugée selon ceux-qui au minimum.
- Qualité du code C++ (lisible, modulaire, commenté, bien présenté, respect des principes de la programmation orientée objet et de conception tels que SRP, OCP et Liskov, sans s'y limiter).
- Qualité du code Qt (exploitation de Qt, multiplateforme...).
- Qualité de la gestion mémoire (pas de fuite mémoire, mémoire bien gérée...).
- Documentation minimale.
- Gestion des données et conception de la base de données.
- Respect des consignes du défi (fonctionnement minimal attendu : fonctionnalités de base, esthétisme et fluidité, modules requis).
Le critère suivant est, quant à lui, optionnel : par paire, seul l'un des deux sera retenu pour la cote finale. En effet, tout le monde n'a pas les mêmes capacités, par exemple en design d'interface graphique : il ne serait pas juste de défavoriser ceux qui produisent facilement des interfaces ergonomiques sans design particulier, par exemple.
- Interface graphique : ergonomie ou design.
Il est aussi possible de dépasser le minimum demandé : évidemment, cela sera récompensé à sa juste valeur. Ces critères peuvent vous mettre sur la piste pour dépasser nos attentes.
- Autres modules.
- Documentation plus détaillée.
- Ajout de modules à chaud (plug-ins).
- Utilisation de Qt Quick.
V-B. Jury▲
Voici la constitution du jury. En cas de problème pour remettre votre candidature ou d'incompréhension des règles, vous pouvez les contacter.
V-C. Grille de cotation▲
| Critère | Points à accumuler (60 au total) |
|---|---|
| Fonctionnement minimal du programme | Total : 18 |
| Fonctionnement de base | 8 |
| Esthétisme | 5 |
| Fluidité | 5 |
| Qualité du code | Total : 13 |
| Qualité d'un point de vue du code | 4 |
| Qualité d'un point de vue Qt | 4 |
| Gestion de la mémoire | 2 |
| Gestion des données | 2 |
| Documentation minimale | 1 |
| Interface graphique (critère optionnel) | Total : 5 |
| Ergonomie | (5) |
| Design | (5) |
| Fonctionnalités obligatoires | Total : 24 |
| Utilisation d'une base de données distante (gestion de patients, des chambres, du planning des médecins...) | 4 |
| Affichage de graphiques et d'images (ECG, scanners, radios...) | 4 |
| Affichage 3D (IRM, squelette...) | 4 |
| Communication entre clients (envoi de messages, textuels ou vidéos, à une autre instance sur une autre machine) | 4 |
| Saisie d'informations (rapports médicaux, prescriptions, facturation...) | 4 |
| Organisation interne (allocation de chambres, de locaux, de membres du personnel, etc. en fonction des besoins) | 4 |
| Bonus (critères facultatifs) | Total : + 38 |
| Autres fonctionnalités (proposées) | 1 chaque, avec un maximum de 3 |
| Autres fonctionnalités (non proposées) | 2 chaque, avec un maximum de 6 |
| Documentation en suffisance | 3 |
| Ajout de modules à chaud | 4 |
| Conception préalable poussée, avec explications | 6 |
| Utilisation de Qt Quick | 8 |
| Surprenez-nous ! | 8 |
| Malus | Total : -16 |
| Utilisation d'un autre langage (sont autorisés tous les langages qui peuvent utiliser Qt directement (C++, Python, Java...) ainsi que tous les langages que Qt utilise (en ce compris ECMAScript/JavaScript, QML, (X)HTML, Lua via QtLua/LQt, etc.)) | -4 |
| Utilisation d'une autre bibliothèque non prévue pour Qt (GMP, GnuPlot...), sauf pour la base de données | -4 |
| Application peu robuste | -2 |
| Application semblant plantée | -2 |
| Erreurs à la compilation | -2 |
| Avertissements à la compilation (sauf si justification dans le README) | -1 |
| Fichiers inutiles dans l'archive | -1 |
Cette même grille sera utilisée pour tous les projets, qu'ils soient rendus par une seule personne ou par une équipe.