Wiki d'activités IMA - Contributions de l’utilisateur [fr]

IMA4 2016/2017 P10

2017-05-10T21:29:14Z

Mrohmer : /* Fichiers Rendus */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S10+ !! Total
|-
| Définition cahier des charges
|8
|
|4
|
|
|
|
|
|
|
|
|
|12
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
|
|
|4
|
|
|
|
|
|
|
|
|
|4
|-
| Prise en main d'Android Studio
|2
|4
|
|
|
|
|
|
|
|
|
|
|6
|-
| Création squelette de l'application
|
|
|2
|4
|
|
|
|
|
|
|
|
|6
|-
| Création d'une base de donnée (côte appli)
|
|
|
|2
|8
|
|
|
|
|
|
|
|10
|-
| Gestion de l'heure pour affichage des prises
|
|
|
|
|
|6
|
|
|
|
|
|
|6
|-
| Création de services pour vibrations et notifications
|
|
|
|
|
|
|6
|
|
|
|
|
|6
|-
| Création d'une alarme
|
|
|
|
|
|
|2
|8
|
|
|
|
|10
|-
| Remaniement complet de la structure interne et de l'interface
|
|
|
|
|
|
|
|
|12
|
|
|
|12
|-
| Mise en place du téléchargement des informations depuis le site
|
|
|
|
|
|
|
|
|
|8
|2
|
|10
|-
|Disposition d'une seconde langue
|
|
|
|
|
|
|
|
|
|6
|
|
|6
|-
|Tests et corrections (côté appli)
|
|
|
|
|4
|
|
|
|
|4
|12
|
|20
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|8
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|16
|-
|Codage du site internet
|
|
|
|
|
|
|4
|4
|8
|8
|4
|
|28
|-
|Gestion de la base de données des médicaments (côté site)
|
|
|
|
|
|4
|4
|
|
|
|
|
|8
|-
|Rédaction rapport
|
|
|
|
|
|
|
|
|
|
|
|8
|8
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''

Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique, et donc nécessaires à notre alarme).

===Semaine 7===

'''Partie application'''

Difficilement, nous avons enfin pu installer un système d'alarme. Néanmoins, celui-ci possède toujours un inconvénient important : l'alarme ne se déclenche pas si l'application est fermée. Pour qu'elle fonctionne, elle a besoin que l'application soit encore en fond, "en pause".

Quand elle se déclenche, nous avons choisi de faire vibrer le téléphone. Nous trouvons cela aussi efficace et plus discret qu'une sonnerie. En même temps, une notification est envoyée à l'appareil : elle apparait en haut du téléphone et permet rapidement de savoir ce qui a provoqué la vibration (on peut y voir un logo de médicament ainsi qu'une petite phrase incitant à prendre son médicament). Quand on clique sur la notification, celle-ci disparait et ouvre l'application affichant ainsi les prises à effectuer.

[[Fichier:notif.png|center]]

(Bien sûr, le texte et titre de la notification affichés ici n'étaient que des exemples temporaires. Nous en emploierons par la suite des plus appropriés, plus "pro".)

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

'''Partie application'''

Jusqu'à maintenant, les informations sur les médicaments étaient minimes et indiquées par nous-même dans le code de l'application. Afin d'intégrer au mieux les éléments qu'il sera possible de rentrer sur le site web, nous avons décider maintenant de "restructurer" l'application.

Voici les changements que cela a causé :

- là où avant nous affichions la totalité des prises que le patient prenait, nous affichons maintenant les médicaments qu'il prend pour son traitement.

- quand nous cliquons sur un médicament, ou bien quand nous voulons en ajouter un nouveau nous arrivons sur la page de ce médicament (premier screenshot ci-dessous). Sur cette page, il est possible de consulter l'intégralité des informations relatives au médicament en cliquant sur la loupe(deuxième screenshot ci-dessous) mais aussi d'ajouter / supprimer des prises.

- pour ajouter un médicament, un système d'auto-complétion permet à l'utilisateur de retrouver celui qu'il cherche parmi la liste de ceux enregistrés jusqu'alors (troisième screenshot ci-dessous).

Les boutons présents pour le moment sur l'application ont ou ont eu (pour certains) une fonction de test. Leur présence et rôle sera repensé par la suite.

[[Fichier:screens.png|800px|center|]]

===Semaine 9===

Pour cette partie, nous nous sommes concentrés cette semaine sur la récupération des informations du site Web sur l'application. Toutes les informations sont contenues à l'intérieur du code source des différentes pages du site, nous nous contentons donc de charger ce code source puis de récupérer les différentes informations.

L'image du médicament est stockée sur un fichier spécial dans la mémoire interne du téléphone. Pour le reste (nom du médicament, posologie, descriptif etc) tout cela est stocké dans une mini base de données à l'intérieur du téléphone.

La récupération des informations nécessite une connexion internet. Elle s'effectue suite à l'appui d'un bouton présent sur l'application. Pour l'instant, à chaque appui nous enregistrons les informations concernant les médicaments qui ne sont pas encore dans notre base de données. Il faudra pour la suite réfléchir au moyen d'effectuer nos mises à jour. La solution la plus simple étant de re-charger les informations de tous les médicaments. Ceci est possible puisque nous considérons que la somme des informations sera légère (moins d'une vingtaine de lignes de texte pour chaque médicament, qui ne seront pas plus d'une vingtaine a priori).

Remarque : les screenshots présents dans la section "semaine 8" ont été effectués avec les informations récoltées depuis le site par les méthodes décrites ici.

===Semaine 10===

L'alarme est maintenant fonctionnelle. L'un des modules de l'application s'occupe même de les réinitialiser après un reboot du téléphone si nécessaire.

Plusieurs langues ont été intégrées à l'application. Ainsi, si le téléphone est configuré en français l'application s'affichera en français. Sinon, la langue par défaut est l'anglais.
L'utilisateur n'ayant plus le choix de la langue, le bouton devant permettre ce choix initialement présent sur le menu de l'application a été retiré.

L'une des autres fonctionnalités ajoutées cette semaine est la possibilité de signaler des vomissements. Ceux-ci sont alors enregistrés dans l'historique, et tous les médicaments pris dans les deux dernières heures sont alors remis dans la liste des médicaments à prendre (on considère qu'ils n'ont pas eu le temps d'être assimilés par l'organisme du patient).

== Fichiers Rendus ==

Rapport de notre projet :

[[Fichier:rapportP10_2017.pdf]]

IMA4 2016/2017 P10

2017-05-10T21:28:38Z

Mrohmer : /* Fichiers Rendus */

IMA4 2016/2017 P10

2017-05-10T21:27:50Z

Mrohmer : /* Fichiers Rendus */

IMA4 2016/2017 P10

2017-05-10T21:26:39Z

Mrohmer : /* Fichiers Rendus */

IMA4 2016/2017 P10

2017-05-10T21:20:42Z

Mrohmer : /* Fichiers Rendus */

IMA4 2016/2017 P10

2017-05-10T21:18:58Z

Mrohmer : /* Fichiers Rendus */

IMA4 2016/2017 P10

2017-05-10T21:18:27Z

Mrohmer : /* Fichiers Rendus */

Fichier:GifProjet.gif

2017-05-10T21:16:30Z

Mrohmer :

IMA4 2016/2017 P10

2017-05-10T21:16:12Z

Mrohmer : /* Fichiers Rendus */

IMA4 2016/2017 P10

2017-05-10T19:45:48Z

Mrohmer : /* Fichiers Rendus */

Fichier:RapportP10 2017.pdf

2017-05-10T19:43:18Z

Mrohmer :

IMA4 2016/2017 P10

2017-05-10T19:42:42Z

Mrohmer : /* Fichiers Rendus */

IMA4 2016/2017 P10

2017-05-10T16:11:28Z

Mrohmer : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S10+ !! Total
|-
| Définition cahier des charges
|8
|
|4
|
|
|
|
|
|
|
|
|
|12
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
|
|
|4
|
|
|
|
|
|
|
|
|
|4
|-
| Prise en main d'Android Studio
|2
|4
|
|
|
|
|
|
|
|
|
|
|6
|-
| Création squelette de l'application
|
|
|2
|4
|
|
|
|
|
|
|
|
|6
|-
| Création d'une base de donnée (côte appli)
|
|
|
|2
|8
|
|
|
|
|
|
|
|10
|-
| Gestion de l'heure pour affichage des prises
|
|
|
|
|
|6
|
|
|
|
|
|
|6
|-
| Création de services pour vibrations et notifications
|
|
|
|
|
|
|6
|
|
|
|
|
|6
|-
| Création d'une alarme
|
|
|
|
|
|
|2
|8
|
|
|
|
|10
|-
| Remaniement complet de la structure interne et de l'interface
|
|
|
|
|
|
|
|
|12
|
|
|
|12
|-
| Mise en place du téléchargement des informations depuis le site
|
|
|
|
|
|
|
|
|
|8
|2
|
|10
|-
|Disposition d'une seconde langue
|
|
|
|
|
|
|
|
|
|6
|
|
|6
|-
|Tests et corrections (côté appli)
|
|
|
|
|4
|
|
|
|
|4
|12
|
|20
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|8
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|16
|-
|Codage du site internet
|
|
|
|
|
|
|4
|4
|8
|8
|
|
|24
|-
|Gestion de la base de données des médicaments (côté site)
|
|
|
|
|
|4
|4
|
|
|
|
|
|8
|-
|Rédaction rapport
|
|
|
|
|
|
|
|
|
|
|
|8
|8
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''

Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique, et donc nécessaires à notre alarme).

===Semaine 7===

'''Partie application'''

Difficilement, nous avons enfin pu installer un système d'alarme. Néanmoins, celui-ci possède toujours un inconvénient important : l'alarme ne se déclenche pas si l'application est fermée. Pour qu'elle fonctionne, elle a besoin que l'application soit encore en fond, "en pause".

Quand elle se déclenche, nous avons choisi de faire vibrer le téléphone. Nous trouvons cela aussi efficace et plus discret qu'une sonnerie. En même temps, une notification est envoyée à l'appareil : elle apparait en haut du téléphone et permet rapidement de savoir ce qui a provoqué la vibration (on peut y voir un logo de médicament ainsi qu'une petite phrase incitant à prendre son médicament). Quand on clique sur la notification, celle-ci disparait et ouvre l'application affichant ainsi les prises à effectuer.

[[Fichier:notif.png|center]]

(Bien sûr, le texte et titre de la notification affichés ici n'étaient que des exemples temporaires. Nous en emploierons par la suite des plus appropriés, plus "pro".)

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

'''Partie application'''

Jusqu'à maintenant, les informations sur les médicaments étaient minimes et indiquées par nous-même dans le code de l'application. Afin d'intégrer au mieux les éléments qu'il sera possible de rentrer sur le site web, nous avons décider maintenant de "restructurer" l'application.

Voici les changements que cela a causé :

- là où avant nous affichions la totalité des prises que le patient prenait, nous affichons maintenant les médicaments qu'il prend pour son traitement.

- quand nous cliquons sur un médicament, ou bien quand nous voulons en ajouter un nouveau nous arrivons sur la page de ce médicament (premier screenshot ci-dessous). Sur cette page, il est possible de consulter l'intégralité des informations relatives au médicament en cliquant sur la loupe(deuxième screenshot ci-dessous) mais aussi d'ajouter / supprimer des prises.

- pour ajouter un médicament, un système d'auto-complétion permet à l'utilisateur de retrouver celui qu'il cherche parmi la liste de ceux enregistrés jusqu'alors (troisième screenshot ci-dessous).

Les boutons présents pour le moment sur l'application ont ou ont eu (pour certains) une fonction de test. Leur présence et rôle sera repensé par la suite.

[[Fichier:screens.png|800px|center|]]

===Semaine 9===

Pour cette partie, nous nous sommes concentrés cette semaine sur la récupération des informations du site Web sur l'application. Toutes les informations sont contenues à l'intérieur du code source des différentes pages du site, nous nous contentons donc de charger ce code source puis de récupérer les différentes informations.

L'image du médicament est stockée sur un fichier spécial dans la mémoire interne du téléphone. Pour le reste (nom du médicament, posologie, descriptif etc) tout cela est stocké dans une mini base de données à l'intérieur du téléphone.

La récupération des informations nécessite une connexion internet. Elle s'effectue suite à l'appui d'un bouton présent sur l'application. Pour l'instant, à chaque appui nous enregistrons les informations concernant les médicaments qui ne sont pas encore dans notre base de données. Il faudra pour la suite réfléchir au moyen d'effectuer nos mises à jour. La solution la plus simple étant de re-charger les informations de tous les médicaments. Ceci est possible puisque nous considérons que la somme des informations sera légère (moins d'une vingtaine de lignes de texte pour chaque médicament, qui ne seront pas plus d'une vingtaine a priori).

Remarque : les screenshots présents dans la section "semaine 8" ont été effectués avec les informations récoltées depuis le site par les méthodes décrites ici.

===Semaine 10===

L'alarme est maintenant fonctionnelle. L'un des modules de l'application s'occupe même de les réinitialiser après un reboot du téléphone si nécessaire.

Plusieurs langues ont été intégrées à l'application. Ainsi, si le téléphone est configuré en français l'application s'affichera en français. Sinon, la langue par défaut est l'anglais.
L'utilisateur n'ayant plus le choix de la langue, le bouton devant permettre ce choix initialement présent sur le menu de l'application a été retiré.

L'une des autres fonctionnalités ajoutées cette semaine est la possibilité de signaler des vomissements. Ceux-ci sont alors enregistrés dans l'historique, et tous les médicaments pris dans les deux dernières heures sont alors remis dans la liste des médicaments à prendre (on considère qu'ils n'ont pas eu le temps d'être assimilés par l'organisme du patient).

== Fichiers Rendus ==

IMA4 2016/2017 P10

2017-05-09T07:37:34Z

Mrohmer : /* Semaine 9 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 8
|2
|
|
|
|
|
|
|
|
|
|
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
| 0
|0
|2
|
|
|
|
|
|
|
|
|
|-
|'''Partie application mobile'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|'''Partie site internet'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|-
|Codage du site internet
|
|
|
|
|
|4
|4
|8
|8
|
|
|
|-
|Gestion de la base de données des médicaments
|
|
|
|
|
|4
|4
|
|
|
|
|
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''

Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique, et donc nécessaires à notre alarme).

===Semaine 7===

'''Partie application'''

Difficilement, nous avons enfin pu installer un système d'alarme. Néanmoins, celui-ci possède toujours un inconvénient important : l'alarme ne se déclenche pas si l'application est fermée. Pour qu'elle fonctionne, elle a besoin que l'application soit encore en fond, "en pause".

Quand elle se déclenche, nous avons choisi de faire vibrer le téléphone. Nous trouvons cela aussi efficace et plus discret qu'une sonnerie. En même temps, une notification est envoyée à l'appareil : elle apparait en haut du téléphone et permet rapidement de savoir ce qui a provoqué la vibration (on peut y voir un logo de médicament ainsi qu'une petite phrase incitant à prendre son médicament). Quand on clique sur la notification, celle-ci disparait et ouvre l'application affichant ainsi les prises à effectuer.

[[Fichier:notif.png|center]]

(Bien sûr, le texte et titre de la notification affichés ici n'étaient que des exemples temporaires. Nous en emploierons par la suite des plus appropriés, plus "pro".)

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

'''Partie application'''

Jusqu'à maintenant, les informations sur les médicaments étaient minimes et indiquées par nous-même dans le code de l'application. Afin d'intégrer au mieux les éléments qu'il sera possible de rentrer sur le site web, nous avons décider maintenant de "restructurer" l'application.

Voici les changements que cela a causé :

- là où avant nous affichions la totalité des prises que le patient prenait, nous affichons maintenant les médicaments qu'il prend pour son traitement.

- quand nous cliquons sur un médicament, ou bien quand nous voulons en ajouter un nouveau nous arrivons sur la page de ce médicament (premier screenshot ci-dessous). Sur cette page, il est possible de consulter l'intégralité des informations relatives au médicament en cliquant sur la loupe(deuxième screenshot ci-dessous) mais aussi d'ajouter / supprimer des prises.

- pour ajouter un médicament, un système d'auto-complétion permet à l'utilisateur de retrouver celui qu'il cherche parmi la liste de ceux enregistrés jusqu'alors (troisième screenshot ci-dessous).

Les boutons présents pour le moment sur l'application ont ou ont eu (pour certains) une fonction de test. Leur présence et rôle sera repensé par la suite.

[[Fichier:screens.png|800px|center|]]

===Semaine 9===

Pour cette partie, nous nous sommes concentrés cette semaine sur la récupération des informations du site Web sur l'application. Toutes les informations sont contenues à l'intérieur du code source des différentes pages du site, nous nous contentons donc de charger ce code source puis de récupérer les différentes informations.

L'image du médicament est stockée sur un fichier spécial dans la mémoire interne du téléphone. Pour le reste (nom du médicament, posologie, descriptif etc) tout cela est stocké dans une mini base de données à l'intérieur du téléphone.

La récupération des informations nécessite une connexion internet. Elle s'effectue suite à l'appui d'un bouton présent sur l'application. Pour l'instant, à chaque appui nous enregistrons les informations concernant les médicaments qui ne sont pas encore dans notre base de données. Il faudra pour la suite réfléchir au moyen d'effectuer nos mises à jour. La solution la plus simple étant de re-charger les informations de tous les médicaments. Ceci est possible puisque nous considérons que la somme des informations sera légère (moins d'une vingtaine de lignes de texte pour chaque médicament, qui ne seront pas plus d'une vingtaine a priori).

Remarque : les screenshots présents dans la section "semaine 8" ont été effectués avec les informations récoltées depuis le site par les méthodes décrites ici.

===Semaine 10===

L'alarme est maintenant fonctionnelle. L'un des modules de l'application s'occupe même de les réinitialiser après un reboot du téléphone si nécessaire.

Plusieurs langues ont été intégrées à l'application. Ainsi, si le téléphone est configuré en français l'application s'affichera en français. Sinon, la langue par défaut est l'anglais.
L'utilisateur n'ayant plus le choix de la langue, le bouton devant permettre ce choix initialement présent sur le menu de l'application a été retiré.

L'une des autres fonctionnalités ajoutées cette semaine est la possibilité de signaler des vomissements. Ceux-ci sont alors enregistrés dans l'historique, et tous les médicaments pris dans les deux dernières heures sont alors remis dans la liste des médicaments à prendre (on considère qu'ils n'ont pas eu le temps d'être assimilés par l'organisme du patient).

== Fichiers Rendus ==

IMA4 2016/2017 P10

2017-04-20T14:16:18Z

Mrohmer : /* Avancement du Projet */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 8
|2
|
|
|
|
|
|
|
|
|
|
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
| 0
|0
|2
|
|
|
|
|
|
|
|
|
|-
|'''Partie application mobile'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|'''Partie site internet'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|-
|Codage du site internet
|
|
|
|
|
|4
|4
|8
|8
|
|
|
|-
|Gestion de la base de données des médicaments
|
|
|
|
|
|4
|4
|
|
|
|
|
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''

Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique, et donc nécessaires à notre alarme).

===Semaine 7===

'''Partie application'''

Difficilement, nous avons enfin pu installer un système d'alarme. Néanmoins, celui-ci possède toujours un inconvénient important : l'alarme ne se déclenche pas si l'application est fermée. Pour qu'elle fonctionne, elle a besoin que l'application soit encore en fond, "en pause".

Quand elle se déclenche, nous avons choisi de faire vibrer le téléphone. Nous trouvons cela aussi efficace et plus discret qu'une sonnerie. En même temps, une notification est envoyée à l'appareil : elle apparait en haut du téléphone et permet rapidement de savoir ce qui a provoqué la vibration (on peut y voir un logo de médicament ainsi qu'une petite phrase incitant à prendre son médicament). Quand on clique sur la notification, celle-ci disparait et ouvre l'application affichant ainsi les prises à effectuer.

[[Fichier:notif.png|center]]

(Bien sûr, le texte et titre de la notification affichés ici n'étaient que des exemples temporaires. Nous en emploierons par la suite des plus appropriés, plus "pro".)

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

'''Partie application'''

Jusqu'à maintenant, les informations sur les médicaments étaient minimes et indiquées par nous-même dans le code de l'application. Afin d'intégrer au mieux les éléments qu'il sera possible de rentrer sur le site web, nous avons décider maintenant de "restructurer" l'application.

Voici les changements que cela a causé :

- là où avant nous affichions la totalité des prises que le patient prenait, nous affichons maintenant les médicaments qu'il prend pour son traitement.

- quand nous cliquons sur un médicament, ou bien quand nous voulons en ajouter un nouveau nous arrivons sur la page de ce médicament (premier screenshot ci-dessous). Sur cette page, il est possible de consulter l'intégralité des informations relatives au médicament en cliquant sur la loupe(deuxième screenshot ci-dessous) mais aussi d'ajouter / supprimer des prises.

- pour ajouter un médicament, un système d'auto-complétion permet à l'utilisateur de retrouver celui qu'il cherche parmi la liste de ceux enregistrés jusqu'alors (troisième screenshot ci-dessous).

Les boutons présents pour le moment sur l'application ont ou ont eu (pour certains) une fonction de test. Leur présence et rôle sera repensé par la suite.

[[Fichier:screens.png|800px|center|]]

===Semaine 9===

'''Partie application'''

Pour cette partie, nous nous sommes concentrés cette semaine sur la récupération des informations du site Web sur l'application. Toutes les informations sont contenues à l'intérieur du code source des différentes pages du site, nous nous contentons donc de charger ce code source puis de récupérer les différents informations.

L'image du médicament est stocké sur une fichier spécial dans la mémoire interne du téléphone. Pour le reste (nom du médicament, posologie, descriptif etc) tout cela est stocké dans une mini base de données à l'intérieur du téléphone.

La récupération des informations nécessite une connexion internet. Elle s'effectue suite à l'appui d'un bouton présent sur l'application. Pour l'instant, à chaque appui nous enregistrons les informations concernant les médicaments qui ne sont pas encore dans notre base de données. Il faudra pour la suite réfléchir au moyen d'effectuer nos mises à jour. La solution la plus simple étant de re-charger les informations de tous les médicaments. Ceci est possible puisque nous considérons que la somme des informations sera légère (moins d'une vingtaine de lignes de texte pour chaque médicament, qui ne seront pas plus d'une vingtaine a priori). Néanmoins nous sommes conscients que cette solution n'est pas optimale.

Remarque : les screenshots présents dans la section "semaine 8" ont été effectués avec les informations récoltées depuis le site par les méthodes décrites ici.

== Fichiers Rendus ==

IMA4 2016/2017 P10

2017-04-20T14:00:03Z

Mrohmer : /* Semaine 8 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 8
|2
|
|
|
|
|
|
|
|
|
|
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
| 0
|0
|2
|
|
|
|
|
|
|
|
|
|-
|'''Partie application mobile'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|'''Partie site internet'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|-
|Codage du site internet
|
|
|
|
|
|4
|4
|8
|8
|
|
|
|-
|Gestion de la base de données des médicaments
|
|
|
|
|
|4
|4
|
|
|
|
|
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''

Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique, et donc nécessaires à notre alarme).

===Semaine 7===

'''Partie application'''

Difficilement, nous avons enfin pu installer un système d'alarme. Néanmoins, celui-ci possède toujours un inconvénient important : l'alarme ne se déclenche pas si l'application est fermée. Pour qu'elle fonctionne, elle a besoin que l'application soit encore en fond, "en pause".

Quand elle se déclenche, nous avons choisi de faire vibrer le téléphone. Nous trouvons cela aussi efficace et plus discret qu'une sonnerie. En même temps, une notification est envoyée à l'appareil : elle apparait en haut du téléphone et permet rapidement de savoir ce qui a provoqué la vibration (on peut y voir un logo de médicament ainsi qu'une petite phrase incitant à prendre son médicament). Quand on clique sur la notification, celle-ci disparait et ouvre l'application affichant ainsi les prises à effectuer.

[[Fichier:notif.png|center]]

(Bien sûr, le texte et titre de la notification affichés ici n'étaient que des exemples temporaires. Nous en emploierons par la suite des plus appropriés, plus "pro".)

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

'''Partie application'''

Jusqu'à maintenant, les informations sur les médicaments étaient minimes et indiquées par nous-même dans le code de l'application. Afin d'intégrer au mieux les éléments qu'il sera possible de rentrer sur le site web, nous avons décider maintenant de "restructurer" l'application.

Voici les changements que cela a causé :

- là où avant nous affichions la totalité des prises que le patient prenait, nous affichons maintenant les médicaments qu'il prend pour son traitement.

- quand nous cliquons sur un médicament, ou bien quand nous voulons en ajouter un nouveau nous arrivons sur la page de ce médicament (premier screenshot ci-dessous). Sur cette page, il est possible de consulter l'intégralité des informations relatives au médicament en cliquant sur la loupe(deuxième screenshot ci-dessous) mais aussi d'ajouter / supprimer des prises.

- pour ajouter un médicament, un système d'auto-complétion permet à l'utilisateur de retrouver celui qu'il cherche parmi la liste de ceux enregistrés jusqu'alors (troisième screenshot ci-dessous).

Les boutons présents pour le moment sur l'application ont ou ont eu (pour certains) une fonction de test. Leur présence et rôle sera repensé par la suite.

[[Fichier:screens.png|800px|center|]]

== Fichiers Rendus ==

Fichier:Screens.png

2017-04-20T13:59:43Z

Mrohmer :

IMA4 2016/2017 P10

2017-04-20T13:26:10Z

Mrohmer : /* Semaine 7 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 8
|2
|
|
|
|
|
|
|
|
|
|
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
| 0
|0
|2
|
|
|
|
|
|
|
|
|
|-
|'''Partie application mobile'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|'''Partie site internet'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|-
|Codage du site internet
|
|
|
|
|
|4
|4
|8
|8
|
|
|
|-
|Gestion de la base de données des médicaments
|
|
|
|
|
|4
|4
|
|
|
|
|
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''

Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique, et donc nécessaires à notre alarme).

===Semaine 7===

'''Partie application'''

Difficilement, nous avons enfin pu installer un système d'alarme. Néanmoins, celui-ci possède toujours un inconvénient important : l'alarme ne se déclenche pas si l'application est fermée. Pour qu'elle fonctionne, elle a besoin que l'application soit encore en fond, "en pause".

Quand elle se déclenche, nous avons choisi de faire vibrer le téléphone. Nous trouvons cela aussi efficace et plus discret qu'une sonnerie. En même temps, une notification est envoyée à l'appareil : elle apparait en haut du téléphone et permet rapidement de savoir ce qui a provoqué la vibration (on peut y voir un logo de médicament ainsi qu'une petite phrase incitant à prendre son médicament). Quand on clique sur la notification, celle-ci disparait et ouvre l'application affichant ainsi les prises à effectuer.

[[Fichier:notif.png|center]]

(Bien sûr, le texte et titre de la notification affichés ici n'étaient que des exemples temporaires. Nous en emploierons par la suite des plus appropriés, plus "pro".)

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

== Fichiers Rendus ==

Fichier:Notif.png

2017-04-20T13:23:20Z

Mrohmer :

IMA4 2016/2017 P10

2017-04-20T13:22:59Z

Mrohmer : /* Semaine 7 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 8
|2
|
|
|
|
|
|
|
|
|
|
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
| 0
|0
|2
|
|
|
|
|
|
|
|
|
|-
|'''Partie application mobile'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|'''Partie site internet'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|-
|Codage du site internet
|
|
|
|
|
|4
|4
|8
|8
|
|
|
|-
|Gestion de la base de données des médicaments
|
|
|
|
|
|4
|4
|
|
|
|
|
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''

Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique, et donc nécessaires à notre alarme).

===Semaine 7===

'''Partie application'''

Difficilement, nous avons enfin pu installer un système d'alarme. Néanmoins, celui-ci possède toujours un inconvénient important : l'alarme ne se déclenche pas si l'application est fermée. Pour qu'elle fonctionne, elle a besoin que l'application soit encore en fond, "en pause".

Quand elle se déclenche, nous avons choisi de faire vibrer le téléphone. Nous trouvons cela aussi efficace et plus discret qu'une sonnerie. En même temps, une notification est envoyée à l'appareil : elle apparait en haut du téléphone et permet rapidement de savoir ce qui a provoqué la vibration (on peut y voir un logo de médicament ainsi qu'une petite phrase incitant à prendre son médicament). Quand on clique sur la notification, celle-ci disparait et ouvre l'application affichant ainsi les prises à effectuer.

[[Fichier:notif.png|center]]

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

== Fichiers Rendus ==

IMA4 2016/2017 P10

2017-04-20T13:21:59Z

Mrohmer : /* Semaine 7 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 8
|2
|
|
|
|
|
|
|
|
|
|
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
| 0
|0
|2
|
|
|
|
|
|
|
|
|
|-
|'''Partie application mobile'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|'''Partie site internet'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|-
|Codage du site internet
|
|
|
|
|
|4
|4
|8
|8
|
|
|
|-
|Gestion de la base de données des médicaments
|
|
|
|
|
|4
|4
|
|
|
|
|
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''

Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique, et donc nécessaires à notre alarme).

===Semaine 7===

'''Partie application'''

Difficilement, nous avons enfin pu installer un système d'alarme. Néanmoins, celui-ci possède toujours un inconvénient important : l'alarme ne se déclenche pas si l'application est fermée. Pour qu'elle fonctionne, elle a besoin que l'application soit encore en fond, "en pause".

Quand elle se déclenche, nous avons choisi de faire vibrer le téléphone. Nous trouvons cela aussi efficace et plus discret qu'une sonnerie. En même temps, une notification est envoyée à l'appareil : elle apparait en haut du téléphone et permet rapidement de savoir ce qui a provoqué la vibration (on peut y voir un logo de médicament ainsi qu'une petite phrase incitant à prendre son médicament). Quand on clique sur la notification, celle-ci disparait et ouvre l'application affichant ainsi les prises à effectuer.

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

== Fichiers Rendus ==

IMA4 2016/2017 P10

2017-04-20T13:05:11Z

Mrohmer : /* Semaine 6 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 8
|2
|
|
|
|
|
|
|
|
|
|
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
| 0
|0
|2
|
|
|
|
|
|
|
|
|
|-
|'''Partie application mobile'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|'''Partie site internet'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|-
|Codage du site internet
|
|
|
|
|
|4
|4
|8
|8
|
|
|
|-
|Gestion de la base de données des médicaments
|
|
|
|
|
|4
|4
|
|
|
|
|
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''

Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique, et donc nécessaires à notre alarme).

===Semaine 7===

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

== Fichiers Rendus ==

IMA4 2016/2017 P10

2017-04-20T13:00:20Z

Mrohmer : /* Semaine 6 */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et description====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements, etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.

L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgés par exemple.

====Objectifs====
Voici un listing des tâches que devra être capable d'effectuer l'application :
*Choix de la langue : au minimum le français et l'anglais seront disponibles.
*Accès à des conseils, sans doute sous forme de fiches.
*Enregistrement d'un traitement :
:*médicaments associés ;
:*doses / quantités ;
:*durée prévue du traitement ;
:*horaires prévues des prises.
*Système de notifications aux horaires prévues pour les prises :
:*notification affichée sur l'écran de l'appareil, peut-être une alarme sonore / vibrante associée ;
:*suite à ce rappel : possibilité d'enregistrer l'heure de la prise ainsi que d'éventuelles notes.
*Possibilité d'enregistrer des prises hors traitement, avec le même principe d'enregistrement d'heures ou de remarques.
*Affichage anti-chronologique de toutes les prises effectuées ainsi des remarques notées.

====Choix techniques (matériel et logiciel)====
L'application sera développée sous Android grâce à l'environnement de développement Android Studio. Elle pourra être testée sur différents smartphones fonctionnant sous Android.

Nos seuls besoins en terme de matériel sont donc un accès à deux ordinateurs munis de l'environnement Android Studio ainsi que deux appareils différents fonctionnant sous Android (afin de tester notre application pour différents formats et versions d'Android). (Nous préférerions en avoir 2 afin de pouvoir travailler à deux de front, en nous répartissant les tâches.)

Afin de toucher le plus large public possible, nous prévoyons de pouvoir tourner sur les versions "Jelly Bean" et celles ultérieures. Cela nous permettrait de toucher près de 97% des utilisateurs d'Android ([http://www.frandroid.com/android/377031_pres-dun-an-apres-deploiement-marshmallow-reste-derriere-kitkat# source officielle récente]).

Les fiches conseils seront stockées sur un serveur avec un accès sécurisé.

===Liste des tâches à effectuer===

*Prise en main d'Android Studio.
*Développement de l'application sous Android Studio.
*Création d'un serveur sécurisé, stockage des fiches conseils.

==Feuille d'heures==
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 8
|2
|
|
|
|
|
|
|
|
|
|
|-
| Rendez vous avec nos tuteurs pour le cahier des charges
| 0
|0
|2
|
|
|
|
|
|
|
|
|
|-
|'''Partie application mobile'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|'''Partie site internet'''
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|X
|-
|Réalisation de la maquette du site
|
|4
|4
|
|
|
|
|
|
|
|
|
|-
|Approche du html/php
|
|
|
|8
|8
|
|
|
|
|
|
|
|-
|Codage du site internet
|
|
|
|
|
|4
|4
|8
|8
|
|
|
|-
|Gestion de la base de données des médicaments
|
|
|
|
|
|4
|4
|
|
|
|
|
|-

==Avancement du Projet==

===Semaine 1===

'''Organisation de la réunion préparatoire'''

Lors de cette première séance, nous avons envisagé les différentes vues utilisées dans l'application tout en relevant diverses questions à poser à nos tuteurs.
Dans le cahier des charges, il était spécifié d'avoir plusieurs langues disponibles pour l'application, on ne sait pas encore si on va utiliser un menu de sélection ou si le choix de la langue sera automatique en fonction de la langue du téléphone. Dans le cas de la sélection par le menu, la vue concernant le choix des langues sera constituée de X boutons (X étant le nombre de langues) avec un retour menu lors du choix.

Selon le premier cas, le menu principal de l'application sera composé de 4 à 5 boutons:

*Ajouter un traitement
*Voir les traitements en cours
*Enregistrer une prise de médicaments
*Voir mon historique de prise
*(Fiches informatives) // Éventuellement en fonction du reste des vues
*Choix de la langue

Dans un deuxième temps, on a travaillé sur les liaisons entre les différentes vues. Lorsque l'on clique sur le bouton "Enregistrer une prise de médicaments", on arrive sur une seconde vue.

'''Apparence de la vue concernant le menu principal et de la vue lors du clic sur le bouton "Enregistrer une prise de médicaments":'''

[[Fichier:16344215_1595515693797790_542610606_n.png]] [[Fichier:16343624_1595516480464378_2000770067_n.png]]

===Semaine 2===

'''Compte rendu de la réunion préparatoire'''

La réunion s'est déroulée le mercredi 1 Février à 15h00 au CHR de Lille, différentes parties du projet ont été étudiées, on peut ajouter les caractéristiques suivantes au cahier des charges :

*l'application doit être facile de compréhension : intuitive et très visuelle afin d'être compréhensible au maximum même par les personnes non francophones ou anglophones
*Une fonction de rappel des prises doit être utilisée
*Les traitements ajoutés peuvent être modifiés
*Le patient doit avoir la possibilité d'inscrire diverses informations comme un vomissement ; en retour, l'application doit prendre en compte l'heure des dernières prises afin d'indiquer s'il est nécessaire ou non de renouveler ces prises
*Enregistrer les oublis de prise
*Une intégration des rendez-vous médicaux dans un calendrier
*Le médecin doit avoir accès à un site internet permettant l'ajouter des fiches médicales pour les médicaments

Un aperçu de l'application sera à rendre aux alentours du 15 Février afin d'évaluer si les intentions de développement correspondent avec le rendu final souhaité.

'''Travail sur le site internet'''

*Une interface de connexion doit être utilisée pour sécuriser l’accès aux différentes fiches (via des identifiants donnés au préalable pour limiter l'inscription).

Le schéma d'utilisation du site sera la suivant :

[[Fichier:ff1.png]]

===Semaine 3===

Maintenant que le cahier des charges est complet et mieux cerné par notre binôme, on a pu se diviser le travail : l'un travaille sur les vues de l'application mobile et l'autre travaille sur la partie site internet.

Lors de cette semaine, l'application a été réadaptée au cahier des charges, en effet on a enlevé la plupart des textes pour les remplacer par des images afin de faciliter l'utilisation pour un patient non francophone. On a remplacé la plupart des boutons d'origine par des images.
Maintenant que nous maitrisons mieux l'agencement des vues en Android, nous nous intéressons plus aux fonctionnalités de l'application. L'application permet maintenant d'afficher les différentes prises que doit prendre le patient dans sa journée. En voici le visuel :

[[Fichier:appliMenu.png|450px]]

Le site internet est utilisé par le médecin pour ajouter des fiches pour les médicaments, le site se veut sobre et facile d'utilisation, pour le moment les vues sont réalisées et on peut passer d'une vue à l'autre.

Dans le cadre du site internet, un système de login / mot de passe a été mis en place pour restreindre l’accès uniquement aux médecins. Cependant, nous ne savons pas si les identifiants seront donnés au préalable pour les médecins, ou si nous allons utilisé un système d'inscription.

===Semaine 4===

Cette semaine, on a travaillé sur l'utilisation de l'application et du site afin de créer une vidéo d'utilisation pour un premier contrôle de nos tuteurs.
Un premier jet de la fiche médicale a été réalisée.
Concernant l'application, nous avons abordé la gestion d'une base de données interne (SQLite) qui nous permettra d'enregistrer les prises de manière pérenne ; en effet, nos précédentes versions n'enregistraient pas les changements une fois l'application fermée.

===Semaine 5===

'''Partie site internet'''

Nous avons réfléchis à la possibilité d'utiliser un système de base de données à la fois pour les médicaments et pour les utilisateurs médecins.
De ce fait, une interface web d'identification (login/password) à été mise en place pour les médecins, suite à cela, nous nous sommes demandés si il était judicieux de créer une interface d'inscription pour les médecins, ou si les identifiants étaient donnés au préalable à l'utilisateur car il y avait peu de médecins qui allait utiliser ce site web.

En parallèle, une base de données pour les médicaments étaient mise en place pour pouvoir gérer les fiches médicales, cependant le stockage d'image et de grosse zone de texte était compliqué.
Ainsi, la possibilité d'utiliser une zone de texte comme celle utilisée dans le wiki a été envisagée suite à la difficulté de gérer une simple "textarea" html, de plus le manque de mise en page des "textarea" était un problème pour réaliser des fiches propres.

'''Partie application'''

L'application est donc maintenant capable d'ajouter des prises de médicament à une heure choisie, de confirmer cette prise afin qu'elle soit enregistrée puis d'afficher dans un historique l'ensemble des prises déjà effectuées.

Cette semaine, nous commençons à nous intéresser à la gestion des heures des prises. Avant, toutes les prises s'affichaient dans l'activité principale de l'application sans considération de l'heure, tant qu'elles n'avaient pas déjà été effectuées.
Désormais, la prise ne s'affiche qu'à partir de l'horaire indiqué et pendant une heure. Ainsi pour un médicament devant être pris à 13 heures, il ne sera pas possible de le voir apparaitre avant 13 heures pile. Son affichage s'en ira une fois que l'utilisateur confirme l'avoir pris, ou à 14 heures dans le cas inverse. Nous partons ici du principe qu'après un laps de temps trop long, il n'est plus utile de prendre un médicament ; ceci nous évite en plus de voir s'accumuler les médicaments dans l'activité principale. Bien sûr, le laps de temps choisi est pour l'instant arbitraire mais pourra être changé pour un temps plus adapté selon les indications du commanditaire du projet.

La gestion de l'heure nous emmène vers ce qui va être notre prochaine étape : la création et la gestion d'une alarme se déclenchant automatiquement aux heures des prises.

===Semaine 6===
'''Partie application'''
Cette semaine, nous nous sommes concentrés sur la collecte d'informations afin de savoir les éléments nécessaires à programmer pour une alarme.
Nous avons ensuite commencé à prendre en main les "services" dans une application (permettant d'effectuer des actions sans associer de partie graphique).

===Semaine 7===

'''Partie site internet'''

Nous étions partis pour gérer les fiches médicales à partir d'une base de données, cependant le nombre de médicament utilisé n'étant pas élevé, nous allons enregistrer les fiches médicales sur des fichiers textes.

A partir d'une interface Web, on peut ajouter une fiche médicale , on y inscrit le nom du médicament, le nom générique (molécule) et les posologies concernant le médicament.
Dans un premier temps, le menu est le suivant :
[[Fichier:menull.png|center|]]

Pour ce médicament 1, de nom générique nom 1, nous décidons qu'il y a 6 posologies, dans ce cas 6 zones de texte apparaissent afin d'y noter les posologies, et nous obtenons donc au final le menu suivant où l'on peut remplir tous les champs

Le menu final est le suivant :
[[Fichier:deroulant.png|center|]]

===Semaine 8===

'''Partie site internet'''

[[Fichier:Menu59.png|center|]]

Le but de cette interface web est de créer un fichier texte contenant la fiche médicale, nous obtenons la page avec la mise en page suivante :
La fiche est créée lorsque l'on appuie sur le bouton valider.

[[Fichier:fiche.png|center|]]

Pour lister les fiches médicales que l'on possède dans notre dossier de fiches, je parcours le répertoire courant afin de récupérer les fichiers, je filtre les fichiers pour ne récupérer que les fichiers textes correspondant aux fiches médicales.
Sur l'interface web, la liste de fiches médicales est composée de lien afin d'accéder directement à la fiches de chaque médicament. La fiche a été réalisée auparavant, ici un exemple de liste de fichiers. Il serait préférable d'enlever l'extension '.txt' des fichiers, nous sommes à la recherche de ce moyen.

[[Fichier:liste59.png|center|]]

== Fichiers Rendus ==

IMA4 2016/2017 P10

2017-04-20T12:52:38Z

Mrohmer : /* Semaine 5 */

IMA4 2016/2017 P10

2017-04-20T12:52:06Z

Mrohmer : /* Semaine 5 */

IMA4 2016/2017 P10

2017-03-01T14:20:29Z

Mrohmer : /* Semaine 4 */

IMA4 2016/2017 P10

2017-03-01T14:14:54Z

Mrohmer : /* Semaine 4 */

IMA4 2016/2017 P10

2017-03-01T13:59:51Z

Mrohmer :

Fichier:AppliMenu.png

2017-03-01T13:56:25Z

Mrohmer :

IMA4 2016/2017 P10

2017-03-01T13:55:49Z

Mrohmer :

IMA4 2016/2017 P10

2017-01-23T13:52:04Z

Mrohmer : /* Cahier des charges */

IMA4 2016/2017 P10

2016-12-18T22:15:46Z

Mrohmer : /* Cahier des charges */

IMA4 2016/2017 P10

2016-12-18T22:14:41Z

Mrohmer : /* Cahier des charges */

IMA4 2016/2017 P10

2016-12-17T21:33:00Z

Mrohmer : /* Cahier des charges */

IMA4 2016/2017 P10

2016-12-17T21:30:45Z

Mrohmer : /* Choix techniques (matériel et logiciel) */

IMA4 2016/2017 P10

2016-12-17T21:25:40Z

Mrohmer : /* Choix techniques : matériel et logiciel */

IMA4 2016/2017 P10

2016-12-17T21:24:22Z

Mrohmer : /* Choix techniques : matériel et logiciel */

IMA4 2016/2017 P10

2016-12-17T21:23:54Z

Mrohmer : /* Choix techniques : matériel et logiciel */

IMA4 2016/2017 P10

2016-12-17T20:40:27Z

Mrohmer : /* Cahier des charges */

IMA4 2016/2017 P10

2016-12-17T19:46:38Z

Mrohmer : /* Cahier des charges */

__TOC__
 
==Cahier des charges==

===Présentation générale du projet===

====Contexte et objectifs====
Ce projet consiste en la création d'une application mobile permettant le suivi de prise de médicaments. Les utilisateurs de cette application bénéficieront de fiches conseils (lors d'une erreur de prise, de vomissements etc) ainsi que de rappels afin de ne pas oublier leurs médicaments. Ils pourront enregistrer leurs prises mais aussi toutes notes qu'ils jugeraient utiles.
L'enregistrement des prises et des remarques a pour but de faciliter l'accès à ces informations par un personnel médical (avec l'accord du patient). Ce sont des informations importantes puisqu'elles peuvent, à titre d'exemple, permettre de mieux comprendre certains résultats d'analyses. Disponible en plusieurs langues, une telle application peut faciliter la transmission de ces informations dans le cas de patients étrangers non francophones ou de patients âgées par exemple.

====Description du projet====

====Choix techniques : matériel et logiciel====

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

====Calendrier====

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===

== Fichiers Rendus ==

IMA4 2016/2017 P10

2016-12-17T19:45:36Z

Mrohmer : /* Cahier des charges */

Projet IMA3 P4, 2015/2016, TD1

2016-03-31T18:20:20Z

Mrohmer : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Podomètre =

== Cahier des charges ==

L'objectif de notre projet IMA3 est de créer un système qui mesure le nombre de pas effectués : un podomètre. L'utilisateur pourra choisir un nombre de pas à effectuer, et lorsque ce nombre sera atteint, une LED verte s'allumera. Sur l'application WEB, on trouvera l'affichage du nombre de pas, d'un bouton de remise à zéro des pas ainsi qu'une fenêtre pour saisir le nombre de pas à effectuer. Nous utiliserons une liaison filaire comme demandé, cependant, le système pourra être amélioré avec une liaison WI-FI.

Pour réaliser ce projet, nous aurons besoin du matériel suivant :

* Un accéléromètre dont nous nous servirons pour caractériser et repérer les pas de l'utilisateur
* Une LED qui signalera que le nombre de pas saisi est atteint
* Une Nanoboard
* Un PC
* Une Raspberry Pi

== Séance 1 ==

=== Partie électronique ===

Lors de cette séance, nous avons commencé à réfléchir à la manière dont notre projet allait fonctionner, nous voulions en quelque sorte découper notre cahier des charges en plusieurs parties pour le réaliser plus facilement. Au final, la partie électronique consistait principalement à la conversion annalogique-numérique des valeurs transmises par l’accéléromètre, ainsi qu'à choisi/câbler les composants, et enfin à transmettre le résultat de la conversion vers la Raspberry Pi. Après avoir été renseignés par les professeurs, nous avons choisi d'utiliser la MLI (modulation de largeur d'impulsion) pour effectuer notre conversion : ce sera l'objectif de la séance 2.

[[Fichier:projet-mtp.png|500px|thumb|center|Schéma du montage pour réaliser la MLI]]

=== Partie informatique ===

Durant la première séance, en informatique, nous avons "découvert" réellement ce qu'était l'accéléromètre. Cette séance a consisté à réaliser une série de tests sur Arduino afin de voir ce que notre capteur renvoyait et comment nous pourrions donc l'utiliser par la suite. Nous avons donc commencé par câbler l'accéléromètre (aide sur le site constructeur) comme on peut le voir ci-dessous :

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:test-arduino.JPG|300px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:adxl-cablage.png|300px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Câblage sur la plaque
| valign="center" | Plan donné sur le site
|}

À la suite du câblage de la plaque de test, nous devions réaliser un programme sous le logiciel Arduino qui correspondait à nos besoins : renvoyer les données acquises par le capteur suivant les 3 axes, x, y et z :
Pour affecter la bonne broche à chaque axe, on utilise (dans le cas de x) :
const int xpin = A0;
Afin d'imprimer les valeurs, nous utilisons (toujours dans le cas de x) :
Serial.print(analogRead(xpin));
Enfin, "delay" correspond au temps d'affichage entre deux valeurs.
[[Fichier:Projet_ard.png|400px|thumb|center|Programme Arduino pour afficher les axes x, y et z]]

Nous avons effectué 3 test d'emplacement pour notre podomètre. Pour chaque emplacement, nous avons tracé un graphique avec les valeurs obtenues afin de voir plus clairement comment faire la suite du projet. En fonction des tests effectués, nous nous sommes rendu compte que l'affichage de tout les axes n'étaient pas nécessaire. En effet :
* Sur le pieds, nous n'avons affichés que l'axe y. Cet emplacement n'a pas été retenu car les valeurs renvoyées sont trop difficiles à exploiter.
* Dans le cas parfait ou l'accéléromètre est sur la table et nous le bougeons par à-coups, nous n'affichons que l'axe y. Les résultats sont très bons.
* Dans le cas ou le capteur est tenu dans la main, nous n'affichons que l'axe x. Les résultats sont tout à fait exploitables et la situation étant plus proche de la réalité, c'est cet emplacement que nous avons choisi.

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-pieds.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-table.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-main.png|250px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | 5 pas réalisés avec le capteur sur le pieds
| valign="center" | 4 "pas" réalisés avec le capteur sur la table
| valign="center" | 7 pas réalisés avec le capteur dans la main
|}

L'objectif de la deuxième séance, au niveau informatique, sera de réaliser la liaison port-série.

== Séance 2 ==

=== Partie électronique ===

Le but de cette seconde séance dans la partie électronique, était de réaliser la conversion analogique-numérique grâce à la MLI. Nous nous sommes donc renseigné sur internet, ainsi que sur certains projets des années précédentes utilisant une conversion à l'aide de la MLI, afin de comprendre un peu mieux en quoi cela consistait. Premièrement, nous devons générer un signal (généralement triangulaire d'après nos recherches). Notre signal à synthétiser sera alors comparé à ce signal triangulaire que nous voulons générer. Le résultat de la MLI sera alors notre signal analogique, mais sous forme de signal tout ou rien ("0" ou "1"). Le schéma suivant illustre la MLI, on retrouve en haut en bleu, le signal triangulaire, et en rouge notre signal analogique (pour notre cas de l'accéléromètre) à synthétiser. Enfin en bas, le résultat :

[[Fichier:pwmproj.png|400px|thumb|center|Résultat d'une MLI]]

Nous avons donc dans un premier temps, réalisé sur Altium, le schéma à lire par la Nanoboard. Nous avons utilisé un compteur 8 bits, sur lequel nous avons connecté une horloge, ainsi qu'un module nous permettant de donner plusieurs valeurs à la MLI pour réaliser nos tests. Enfin, nous avons choisi d'utiliser simplement le bloc PWM proposé par le logiciel Altium :

[[Fichier:altium-mli.JPG|700px|thumb|center|Schéma Altium de la MLI]]

La sortie HA3 nous permet de visualiser le signal d'horloge, tandis que la sortie HA5 est la sortie de la MLI.

Nous obtenons comme prévu pour le moment, un signal carré que nous allons par la suite devoir filtrer pour qu'il "devienne" triangulaire. Le filtre passe-bas que nous allons utiliser, est constitué d'une résistance R=68kΩ et d'une capacité C=8,2nF ce qui nous donne un fréquence de coupure égale à <math>Fc = 1/(2*pi*RC) = 285 Hz</math>. Nous avons essayé plusieurs composant afin d'obtenir un signal triangulaire, qui redescend rapidement.

[[Fichier:mli-test1.JPG|500px|thumb|center|Premier signal obtenu pour une valeur quelconque]]

Ci dessous, la réalisation du filtre ainsi que les résultats obtenus (le signal n'est pas parfaitement triangulaire mais est utilisable pour la suite du projet).

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:filtre-rc.JPG|500px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:mli-test.JPG|500px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Filtre RC câblé sur notre plaque
| valign="center" | Signal obtenu après filtrage
|}

=== Partie informatique ===

Nous avons continué à utiliser notre capteur via l'Arduino afin de faire les simulations nécessaires à la liaison port-série.

Voici le code Arduino simplifié par rapport à la séance précédente, afin de recevoir uniquement les valeurs en X, Y et en Z du capteur :
(et ainsi de ne pas prendre en compte les tabulations et le retour à ligne)

[[Fichier:arduino2.png|500px|thumb|center]]

Plus tard, de légères modifications pourront encore être apportées : tous les axes ne nous sont peut-être pas nécessaires, et le délai entre 2 acquisitions devra être utile à notre application de podomètre.

'''Protocoles de communication'''

Cette partie assure la communication entre nos différents éléments, ici pour l'instant entre l'ordinateur et l'Arduino.
Elle est tirée du programme exemple, adapté afin de ne rien renvoyer et pour lire 3 valeurs les unes à la suite des autres.

int main(void){
int i=0;
int intm;
int x,y,z;
int sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
if(read(sd,&intm,sizeof(int))!=1){
perror("main.read"); exit(-1); }
if(i%3==0){
x=intm;
printf("%d ",x%20);
}
if(i%3==1){
y=intm;
printf("%d ",y%20);
}
if(i%3==2){
z=intm;
printf("%d\n",z%20);
}
i++;
sleep(0.5);//attendre
}
serialClose(sd);
exit(0);
}

L'entier i utilisé avec ''modulo 3'' nous sert à savoir quelle valeur est actuellement lue entre X, Y et Z.
Les ''modulo 20'' sont ici parce que les valeurs lues sont beaucoup trop grandes par rapport à leur variation. Ils servent donc à avoir des valeurs qui seront plus facilement exploitables par la suite.

Lors de la prochaine séance, dans la partie informatique il faudra nous pencher sur la liaison WebSocket. Ensuite nous pourrons mettre l'ensemble des fichiers en association, afin que les valeurs transmises soient exploitées, et affichées sur notre interface Web.

== Séance 3 (+ séances supplémentaires)==

=== Partie électronique ===

Lors de cette dernière séance, notre objectif dans un premier temps était de faire la comparaison entre notre signal MLI et les données envoyées par le capteur. A l'aide d'une datasheet trouvée sur internet, nous avons câblé l'AOP en comparateur de la manière suivante :

[[Fichier:montage_projet.png|700px|thumb|center|Montage de comparaison]]

Sur l'entrée Vin(+), on trouve le signal envoyé par notre capteur, et sur l'entrée Vin(-) notre signal MLI. La sortie de l'AOP (Vout) est sur la photo relié à l'oscilloscope afin de visualiser la résultat de notre comparaison. Par la suite, il sera renvoyé vers la FPGA.

Nous obtenons donc un signal rectangulaire, qui correspond à notre conversion. Nous avons pu observer que ce signal est bien modifié lorsque nous bougeons le capteur.

[[Fichier:result-mli.JPG|700px|thumb|center|Signal final, résultat de la conversion grâce à la MLI]]

La dernière partie (hormis la liaison série) était donc de renvoyer ces données de conversion dans la FPGA, pour les stocker temporairement, et ensuite les transmettre à la liaison série. Pour stocker les valeurs, nous avons décidé d'utiliser une bascule. La sortie de cette bascule sera relié à la partie "envoie" de notre liaison série. Nous ne recevons rien, nous allons donc couper les sorties du module de réception de la liaison série. Après avoir demandé les .Vhd, nous les avons inclus dans notre schéma FPGA :

[[Fichier:fpga-projet.png|700px|thumb|center|Schéma Altium final]]

Finalement, la compilation du programme ne fonctionne plus et nous n’arrivons pas à régler le problème provenant de la liaison série.

=== Partie informatique ===

Il nous fallait maintenant établir la liaison sur le serveur WebSocket. Nous avons repris et modifié les exemples qui nous ont été donnés, voici ce que l'on a obtenu :

Pour le fichier .c nous avons fait en sorte de recevoir les données envoyées par le capteur. Nous ne recevons les données ne venant que de l'un des trois axes, car nous pensons cela satisfaisant pour savoir quand un pas est fait.

case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(write(sd,&d,sizeof(char))!=1){perror("main.write"); exit(-1);}
int i;
if(read(sd,i,sizeof(char))!=1){perror("main.read"); exit(-1);}
sprintf(out,"%d",i);
libwebsocket_write(wsi,(unsigned char*)out,strlen(out),LWS_WRITE_TEXT);
libwebsocket_callback_on_writable(this,wsi);
break;

Quant à la page HTML, voici le résultat obtenu ainsi que son code source :

[[Fichier:aperçu.png|900px|thumb|center]]
[[Fichier:codeSource.png|800px|thumb|center]]

Notre problème est que nous avons travailler cette partie plus tard, sans possibilité de tester si chacune des parties fonctionnait correctement et de la manière voulue.
Nous n'avons donc pas effectué les tests qui nous auraient été nécessaires afin de corriger les fautes possibles.

== Démonstration ==

== Conclusion ==

Fichier:CodeSource.png

2016-03-31T18:14:10Z

Mrohmer : a téléversé une nouvelle version de « Fichier:CodeSource.png »

Projet IMA3 P4, 2015/2016, TD1

2016-03-31T18:11:35Z

Mrohmer : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Podomètre =

== Cahier des charges ==

L'objectif de notre projet IMA3 est de créer un système qui mesure le nombre de pas effectués : un podomètre. L'utilisateur pourra choisir un nombre de pas à effectuer, et lorsque ce nombre sera atteint, une LED verte s'allumera. Sur l'application WEB, on trouvera l'affichage du nombre de pas, d'un bouton de remise à zéro des pas ainsi qu'une fenêtre pour saisir le nombre de pas à effectuer. Nous utiliserons une liaison filaire comme demandé, cependant, le système pourra être amélioré avec une liaison WI-FI.

Pour réaliser ce projet, nous aurons besoin du matériel suivant :

* Un accéléromètre dont nous nous servirons pour caractériser et repérer les pas de l'utilisateur
* Une LED qui signalera que le nombre de pas saisi est atteint
* Une Nanoboard
* Un PC
* Une Raspberry Pi

== Séance 1 ==

=== Partie électronique ===

Lors de cette séance, nous avons commencé à réfléchir à la manière dont notre projet allait fonctionner, nous voulions en quelque sorte découper notre cahier des charges en plusieurs parties pour le réaliser plus facilement. Au final, la partie électronique consistait principalement à la conversion annalogique-numérique des valeurs transmises par l’accéléromètre, ainsi qu'à choisi/câbler les composants, et enfin à transmettre le résultat de la conversion vers la Raspberry Pi. Après avoir été renseignés par les professeurs, nous avons choisi d'utiliser la MLI (modulation de largeur d'impulsion) pour effectuer notre conversion : ce sera l'objectif de la séance 2.

[[Fichier:projet-mtp.png|500px|thumb|center|Schéma du montage pour réaliser la MLI]]

=== Partie informatique ===

Durant la première séance, en informatique, nous avons "découvert" réellement ce qu'était l'accéléromètre. Cette séance a consisté à réaliser une série de tests sur Arduino afin de voir ce que notre capteur renvoyait et comment nous pourrions donc l'utiliser par la suite. Nous avons donc commencé par câbler l'accéléromètre (aide sur le site constructeur) comme on peut le voir ci-dessous :

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:test-arduino.JPG|300px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:adxl-cablage.png|300px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Câblage sur la plaque
| valign="center" | Plan donné sur le site
|}

À la suite du câblage de la plaque de test, nous devions réaliser un programme sous le logiciel Arduino qui correspondait à nos besoins : renvoyer les données acquises par le capteur suivant les 3 axes, x, y et z :
Pour affecter la bonne broche à chaque axe, on utilise (dans le cas de x) :
const int xpin = A0;
Afin d'imprimer les valeurs, nous utilisons (toujours dans le cas de x) :
Serial.print(analogRead(xpin));
Enfin, "delay" correspond au temps d'affichage entre deux valeurs.
[[Fichier:Projet_ard.png|400px|thumb|center|Programme Arduino pour afficher les axes x, y et z]]

Nous avons effectué 3 test d'emplacement pour notre podomètre. Pour chaque emplacement, nous avons tracé un graphique avec les valeurs obtenues afin de voir plus clairement comment faire la suite du projet. En fonction des tests effectués, nous nous sommes rendu compte que l'affichage de tout les axes n'étaient pas nécessaire. En effet :
* Sur le pieds, nous n'avons affichés que l'axe y. Cet emplacement n'a pas été retenu car les valeurs renvoyées sont trop difficiles à exploiter.
* Dans le cas parfait ou l'accéléromètre est sur la table et nous le bougeons par à-coups, nous n'affichons que l'axe y. Les résultats sont très bons.
* Dans le cas ou le capteur est tenu dans la main, nous n'affichons que l'axe x. Les résultats sont tout à fait exploitables et la situation étant plus proche de la réalité, c'est cet emplacement que nous avons choisi.

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-pieds.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-table.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-main.png|250px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | 5 pas réalisés avec le capteur sur le pieds
| valign="center" | 4 "pas" réalisés avec le capteur sur la table
| valign="center" | 7 pas réalisés avec le capteur dans la main
|}

L'objectif de la deuxième séance, au niveau informatique, sera de réaliser la liaison port-série.

== Séance 2 ==

=== Partie électronique ===

Le but de cette seconde séance dans la partie électronique, était de réaliser la conversion analogique-numérique grâce à la MLI. Nous nous sommes donc renseigné sur internet, ainsi que sur certains projets des années précédentes utilisant une conversion à l'aide de la MLI, afin de comprendre un peu mieux en quoi cela consistait. Premièrement, nous devons générer un signal (généralement triangulaire d'après nos recherches). Notre signal à synthétiser sera alors comparé à ce signal triangulaire que nous voulons générer. Le résultat de la MLI sera alors notre signal analogique, mais sous forme de signal tout ou rien ("0" ou "1"). Le schéma suivant illustre la MLI, on retrouve en haut en bleu, le signal triangulaire, et en rouge notre signal analogique (pour notre cas de l'accéléromètre) à synthétiser. Enfin en bas, le résultat :

[[Fichier:pwmproj.png|400px|thumb|center|Résultat d'une MLI]]

Nous avons donc dans un premier temps, réalisé sur Altium, le schéma à lire par la Nanoboard. Nous avons utilisé un compteur 8 bits, sur lequel nous avons connecté une horloge, ainsi qu'un module nous permettant de donner plusieurs valeurs à la MLI pour réaliser nos tests. Enfin, nous avons choisi d'utiliser simplement le bloc PWM proposé par le logiciel Altium :

[[Fichier:altium-mli.JPG|700px|thumb|center|Schéma Altium de la MLI]]

La sortie HA3 nous permet de visualiser le signal d'horloge, tandis que la sortie HA5 est la sortie de la MLI.

Nous obtenons comme prévu pour le moment, un signal carré que nous allons par la suite devoir filtrer pour qu'il "devienne" triangulaire. Le filtre passe-bas que nous allons utiliser, est constitué d'une résistance R=68kΩ et d'une capacité C=8,2nF ce qui nous donne un fréquence de coupure égale à <math>Fc = 1/(2*pi*RC) = 285 Hz</math>. Nous avons essayé plusieurs composant afin d'obtenir un signal triangulaire, qui redescend rapidement.

[[Fichier:mli-test1.JPG|500px|thumb|center|Premier signal obtenu pour une valeur quelconque]]

Ci dessous, la réalisation du filtre ainsi que les résultats obtenus (le signal n'est pas parfaitement triangulaire mais est utilisable pour la suite du projet).

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:filtre-rc.JPG|500px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:mli-test.JPG|500px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Filtre RC câblé sur notre plaque
| valign="center" | Signal obtenu après filtrage
|}

=== Partie informatique ===

Nous avons continué à utiliser notre capteur via l'Arduino afin de faire les simulations nécessaires à la liaison port-série.

Voici le code Arduino simplifié par rapport à la séance précédente, afin de recevoir uniquement les valeurs en X, Y et en Z du capteur :
(et ainsi de ne pas prendre en compte les tabulations et le retour à ligne)

[[Fichier:arduino2.png|500px|thumb|center]]

Plus tard, de légères modifications pourront encore être apportées : tous les axes ne nous sont peut-être pas nécessaires, et le délai entre 2 acquisitions devra être utile à notre application de podomètre.

'''Protocoles de communication'''

Cette partie assure la communication entre nos différents éléments, ici pour l'instant entre l'ordinateur et l'Arduino.
Elle est tirée du programme exemple, adapté afin de ne rien renvoyer et pour lire 3 valeurs les unes à la suite des autres.

int main(void){
int i=0;
int intm;
int x,y,z;
int sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
if(read(sd,&intm,sizeof(int))!=1){
perror("main.read"); exit(-1); }
if(i%3==0){
x=intm;
printf("%d ",x%20);
}
if(i%3==1){
y=intm;
printf("%d ",y%20);
}
if(i%3==2){
z=intm;
printf("%d\n",z%20);
}
i++;
sleep(0.5);//attendre
}
serialClose(sd);
exit(0);
}

L'entier i utilisé avec ''modulo 3'' nous sert à savoir quelle valeur est actuellement lue entre X, Y et Z.
Les ''modulo 20'' sont ici parce que les valeurs lues sont beaucoup trop grandes par rapport à leur variation. Ils servent donc à avoir des valeurs qui seront plus facilement exploitables par la suite.

Lors de la prochaine séance, dans la partie informatique il faudra nous pencher sur la liaison WebSocket. Ensuite nous pourrons mettre l'ensemble des fichiers en association, afin que les valeurs transmises soient exploitées, et affichées sur notre interface Web.

== Séance 3 (+ séances supplémentaires)==

=== Partie électronique ===

Lors de cette dernière séance, notre objectif dans un premier temps était de faire la comparaison entre notre signal MLI et les données envoyées par le capteur. A l'aide d'une datasheet trouvée sur internet, nous avons câblé l'AOP en comparateur de la manière suivante :

[[Fichier:montage_projet.png|700px|thumb|center|Montage de comparaison]]

Sur l'entrée Vin(+), on trouve le signal envoyé par notre capteur, et sur l'entrée Vin(-) notre signal MLI. La sortie de l'AOP (Vout) est sur la photo relié à l'oscilloscope afin de visualiser la résultat de notre comparaison. Par la suite, il sera renvoyé vers la FPGA.

Nous obtenons donc un signal rectangulaire, qui correspond à notre conversion. Nous avons pu observer que ce signal est bien modifié lorsque nous bougeons le capteur.

[[Fichier:result-mli.JPG|700px|thumb|center|Signal final, résultat de la conversion grâce à la MLI]]

La dernière partie (hormis la liaison série) était donc de renvoyer ces données de conversion dans la FPGA, pour les stocker temporairement, et ensuite les transmettre à la liaison série. Pour stocker les valeurs, nous avons décidé d'utiliser une bascule. La sortie de cette bascule sera relié à la partie "envoie" de notre liaison série. Nous ne recevons rien, nous allons donc couper les sorties du module de réception de la liaison série. Après avoir demandé les .Vhd, nous les avons inclus dans notre schéma FPGA :

[[Fichier:fpga-projet.png|700px|thumb|center|Schéma Altium final]]

Finalement, la compilation du programme ne fonctionne plus et nous n’arrivons pas à régler le problème provenant de la liaison série.

=== Partie informatique ===

Il nous fallait maintenant établir la liaison sur le serveur WebSocket. Nous avons repris et modifié les exemples qui nous ont été donnés, voici ce que l'on a obtenu :

Pour le fichier .c nous avons fait en sorte de recevoir les données envoyées par le capteur. Nous ne recevons les données ne venant que de l'un des trois axes, car nous pensons cela satisfaisant pour savoir quand un pas est fait.

case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(write(sd,&d,sizeof(char))!=1){perror("main.write"); exit(-1);}
int i;
if(read(sd,i,sizeof(char))!=1){perror("main.read"); exit(-1);}
sprintf(out,"%d",i);
libwebsocket_write(wsi,(unsigned char*)out,strlen(out),LWS_WRITE_TEXT);
libwebsocket_callback_on_writable(this,wsi);
break;

Quant à la page HTML, voici le résultat obtenu ainsi que son code source :

[[Fichier:aperçu.png|800px|thumb|center]]
[[Fichier:codeSource.png|800px|thumb|center]]

== Démonstration ==

== Conclusion ==

Projet IMA3 P4, 2015/2016, TD1

2016-03-31T18:10:56Z

Mrohmer : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Podomètre =

== Cahier des charges ==

L'objectif de notre projet IMA3 est de créer un système qui mesure le nombre de pas effectués : un podomètre. L'utilisateur pourra choisir un nombre de pas à effectuer, et lorsque ce nombre sera atteint, une LED verte s'allumera. Sur l'application WEB, on trouvera l'affichage du nombre de pas, d'un bouton de remise à zéro des pas ainsi qu'une fenêtre pour saisir le nombre de pas à effectuer. Nous utiliserons une liaison filaire comme demandé, cependant, le système pourra être amélioré avec une liaison WI-FI.

Pour réaliser ce projet, nous aurons besoin du matériel suivant :

* Un accéléromètre dont nous nous servirons pour caractériser et repérer les pas de l'utilisateur
* Une LED qui signalera que le nombre de pas saisi est atteint
* Une Nanoboard
* Un PC
* Une Raspberry Pi

== Séance 1 ==

=== Partie électronique ===

Lors de cette séance, nous avons commencé à réfléchir à la manière dont notre projet allait fonctionner, nous voulions en quelque sorte découper notre cahier des charges en plusieurs parties pour le réaliser plus facilement. Au final, la partie électronique consistait principalement à la conversion annalogique-numérique des valeurs transmises par l’accéléromètre, ainsi qu'à choisi/câbler les composants, et enfin à transmettre le résultat de la conversion vers la Raspberry Pi. Après avoir été renseignés par les professeurs, nous avons choisi d'utiliser la MLI (modulation de largeur d'impulsion) pour effectuer notre conversion : ce sera l'objectif de la séance 2.

[[Fichier:projet-mtp.png|500px|thumb|center|Schéma du montage pour réaliser la MLI]]

=== Partie informatique ===

Durant la première séance, en informatique, nous avons "découvert" réellement ce qu'était l'accéléromètre. Cette séance a consisté à réaliser une série de tests sur Arduino afin de voir ce que notre capteur renvoyait et comment nous pourrions donc l'utiliser par la suite. Nous avons donc commencé par câbler l'accéléromètre (aide sur le site constructeur) comme on peut le voir ci-dessous :

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:test-arduino.JPG|300px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:adxl-cablage.png|300px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Câblage sur la plaque
| valign="center" | Plan donné sur le site
|}

À la suite du câblage de la plaque de test, nous devions réaliser un programme sous le logiciel Arduino qui correspondait à nos besoins : renvoyer les données acquises par le capteur suivant les 3 axes, x, y et z :
Pour affecter la bonne broche à chaque axe, on utilise (dans le cas de x) :
const int xpin = A0;
Afin d'imprimer les valeurs, nous utilisons (toujours dans le cas de x) :
Serial.print(analogRead(xpin));
Enfin, "delay" correspond au temps d'affichage entre deux valeurs.
[[Fichier:Projet_ard.png|400px|thumb|center|Programme Arduino pour afficher les axes x, y et z]]

Nous avons effectué 3 test d'emplacement pour notre podomètre. Pour chaque emplacement, nous avons tracé un graphique avec les valeurs obtenues afin de voir plus clairement comment faire la suite du projet. En fonction des tests effectués, nous nous sommes rendu compte que l'affichage de tout les axes n'étaient pas nécessaire. En effet :
* Sur le pieds, nous n'avons affichés que l'axe y. Cet emplacement n'a pas été retenu car les valeurs renvoyées sont trop difficiles à exploiter.
* Dans le cas parfait ou l'accéléromètre est sur la table et nous le bougeons par à-coups, nous n'affichons que l'axe y. Les résultats sont très bons.
* Dans le cas ou le capteur est tenu dans la main, nous n'affichons que l'axe x. Les résultats sont tout à fait exploitables et la situation étant plus proche de la réalité, c'est cet emplacement que nous avons choisi.

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-pieds.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-table.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-main.png|250px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | 5 pas réalisés avec le capteur sur le pieds
| valign="center" | 4 "pas" réalisés avec le capteur sur la table
| valign="center" | 7 pas réalisés avec le capteur dans la main
|}

L'objectif de la deuxième séance, au niveau informatique, sera de réaliser la liaison port-série.

== Séance 2 ==

=== Partie électronique ===

Le but de cette seconde séance dans la partie électronique, était de réaliser la conversion analogique-numérique grâce à la MLI. Nous nous sommes donc renseigné sur internet, ainsi que sur certains projets des années précédentes utilisant une conversion à l'aide de la MLI, afin de comprendre un peu mieux en quoi cela consistait. Premièrement, nous devons générer un signal (généralement triangulaire d'après nos recherches). Notre signal à synthétiser sera alors comparé à ce signal triangulaire que nous voulons générer. Le résultat de la MLI sera alors notre signal analogique, mais sous forme de signal tout ou rien ("0" ou "1"). Le schéma suivant illustre la MLI, on retrouve en haut en bleu, le signal triangulaire, et en rouge notre signal analogique (pour notre cas de l'accéléromètre) à synthétiser. Enfin en bas, le résultat :

[[Fichier:pwmproj.png|400px|thumb|center|Résultat d'une MLI]]

Nous avons donc dans un premier temps, réalisé sur Altium, le schéma à lire par la Nanoboard. Nous avons utilisé un compteur 8 bits, sur lequel nous avons connecté une horloge, ainsi qu'un module nous permettant de donner plusieurs valeurs à la MLI pour réaliser nos tests. Enfin, nous avons choisi d'utiliser simplement le bloc PWM proposé par le logiciel Altium :

[[Fichier:altium-mli.JPG|700px|thumb|center|Schéma Altium de la MLI]]

La sortie HA3 nous permet de visualiser le signal d'horloge, tandis que la sortie HA5 est la sortie de la MLI.

Nous obtenons comme prévu pour le moment, un signal carré que nous allons par la suite devoir filtrer pour qu'il "devienne" triangulaire. Le filtre passe-bas que nous allons utiliser, est constitué d'une résistance R=68kΩ et d'une capacité C=8,2nF ce qui nous donne un fréquence de coupure égale à <math>Fc = 1/(2*pi*RC) = 285 Hz</math>. Nous avons essayé plusieurs composant afin d'obtenir un signal triangulaire, qui redescend rapidement.

[[Fichier:mli-test1.JPG|500px|thumb|center|Premier signal obtenu pour une valeur quelconque]]

Ci dessous, la réalisation du filtre ainsi que les résultats obtenus (le signal n'est pas parfaitement triangulaire mais est utilisable pour la suite du projet).

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:filtre-rc.JPG|500px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:mli-test.JPG|500px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Filtre RC câblé sur notre plaque
| valign="center" | Signal obtenu après filtrage
|}

=== Partie informatique ===

Nous avons continué à utiliser notre capteur via l'Arduino afin de faire les simulations nécessaires à la liaison port-série.

Voici le code Arduino simplifié par rapport à la séance précédente, afin de recevoir uniquement les valeurs en X, Y et en Z du capteur :
(et ainsi de ne pas prendre en compte les tabulations et le retour à ligne)

[[Fichier:arduino2.png|500px|thumb|center]]

Plus tard, de légères modifications pourront encore être apportées : tous les axes ne nous sont peut-être pas nécessaires, et le délai entre 2 acquisitions devra être utile à notre application de podomètre.

'''Protocoles de communication'''

Cette partie assure la communication entre nos différents éléments, ici pour l'instant entre l'ordinateur et l'Arduino.
Elle est tirée du programme exemple, adapté afin de ne rien renvoyer et pour lire 3 valeurs les unes à la suite des autres.

int main(void){
int i=0;
int intm;
int x,y,z;
int sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
if(read(sd,&intm,sizeof(int))!=1){
perror("main.read"); exit(-1); }
if(i%3==0){
x=intm;
printf("%d ",x%20);
}
if(i%3==1){
y=intm;
printf("%d ",y%20);
}
if(i%3==2){
z=intm;
printf("%d\n",z%20);
}
i++;
sleep(0.5);//attendre
}
serialClose(sd);
exit(0);
}

L'entier i utilisé avec ''modulo 3'' nous sert à savoir quelle valeur est actuellement lue entre X, Y et Z.
Les ''modulo 20'' sont ici parce que les valeurs lues sont beaucoup trop grandes par rapport à leur variation. Ils servent donc à avoir des valeurs qui seront plus facilement exploitables par la suite.

Lors de la prochaine séance, dans la partie informatique il faudra nous pencher sur la liaison WebSocket. Ensuite nous pourrons mettre l'ensemble des fichiers en association, afin que les valeurs transmises soient exploitées, et affichées sur notre interface Web.

== Séance 3 (+ séances supplémentaires)==

=== Partie électronique ===

Lors de cette dernière séance, notre objectif dans un premier temps était de faire la comparaison entre notre signal MLI et les données envoyées par le capteur. A l'aide d'une datasheet trouvée sur internet, nous avons câblé l'AOP en comparateur de la manière suivante :

[[Fichier:montage_projet.png|700px|thumb|center|Montage de comparaison]]

Sur l'entrée Vin(+), on trouve le signal envoyé par notre capteur, et sur l'entrée Vin(-) notre signal MLI. La sortie de l'AOP (Vout) est sur la photo relié à l'oscilloscope afin de visualiser la résultat de notre comparaison. Par la suite, il sera renvoyé vers la FPGA.

Nous obtenons donc un signal rectangulaire, qui correspond à notre conversion. Nous avons pu observer que ce signal est bien modifié lorsque nous bougeons le capteur.

[[Fichier:result-mli.JPG|700px|thumb|center|Signal final, résultat de la conversion grâce à la MLI]]

La dernière partie (hormis la liaison série) était donc de renvoyer ces données de conversion dans la FPGA, pour les stocker temporairement, et ensuite les transmettre à la liaison série. Pour stocker les valeurs, nous avons décidé d'utiliser une bascule. La sortie de cette bascule sera relié à la partie "envoie" de notre liaison série. Nous ne recevons rien, nous allons donc couper les sorties du module de réception de la liaison série. Après avoir demandé les .Vhd, nous les avons inclus dans notre schéma FPGA :

[[Fichier:fpga-projet.png|700px|thumb|center|Schéma Altium final]]

Finalement, la compilation du programme ne fonctionne plus et nous n’arrivons pas à régler le problème provenant de la liaison série.

=== Partie informatique ===

Il nous fallait maintenant établir la liaison sur le serveur WebSocket. Nous avons repris et modifié les exemples qui nous ont été donnés, voici ce que l'on a obtenu :

Pour le fichier .c nous avons fait en sorte de recevoir les données envoyées par le capteur. Nous ne recevons les données ne venant que de l'un des trois axes, car nous pensons cela satisfaisant pour savoir quand un pas est fait.

case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(write(sd,&d,sizeof(char))!=1){perror("main.write"); exit(-1);}
int i;
if(read(sd,i,sizeof(char))!=1){perror("main.read"); exit(-1);}
sprintf(out,"%d",i);
libwebsocket_write(wsi,(unsigned char*)out,strlen(out),LWS_WRITE_TEXT);
libwebsocket_callback_on_writable(this,wsi);
break;

Quant à la page HTML, voici le résultat obtenu ainsi que son code source :

[[Fichier:aperçu.png|thumb|center]]
[[Fichier:codeSource.png|thumb|center]]

== Démonstration ==

== Conclusion ==

Projet IMA3 P4, 2015/2016, TD1

2016-03-31T18:10:20Z

Mrohmer : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Podomètre =

== Cahier des charges ==

L'objectif de notre projet IMA3 est de créer un système qui mesure le nombre de pas effectués : un podomètre. L'utilisateur pourra choisir un nombre de pas à effectuer, et lorsque ce nombre sera atteint, une LED verte s'allumera. Sur l'application WEB, on trouvera l'affichage du nombre de pas, d'un bouton de remise à zéro des pas ainsi qu'une fenêtre pour saisir le nombre de pas à effectuer. Nous utiliserons une liaison filaire comme demandé, cependant, le système pourra être amélioré avec une liaison WI-FI.

Pour réaliser ce projet, nous aurons besoin du matériel suivant :

* Un accéléromètre dont nous nous servirons pour caractériser et repérer les pas de l'utilisateur
* Une LED qui signalera que le nombre de pas saisi est atteint
* Une Nanoboard
* Un PC
* Une Raspberry Pi

== Séance 1 ==

=== Partie électronique ===

Lors de cette séance, nous avons commencé à réfléchir à la manière dont notre projet allait fonctionner, nous voulions en quelque sorte découper notre cahier des charges en plusieurs parties pour le réaliser plus facilement. Au final, la partie électronique consistait principalement à la conversion annalogique-numérique des valeurs transmises par l’accéléromètre, ainsi qu'à choisi/câbler les composants, et enfin à transmettre le résultat de la conversion vers la Raspberry Pi. Après avoir été renseignés par les professeurs, nous avons choisi d'utiliser la MLI (modulation de largeur d'impulsion) pour effectuer notre conversion : ce sera l'objectif de la séance 2.

[[Fichier:projet-mtp.png|500px|thumb|center|Schéma du montage pour réaliser la MLI]]

=== Partie informatique ===

Durant la première séance, en informatique, nous avons "découvert" réellement ce qu'était l'accéléromètre. Cette séance a consisté à réaliser une série de tests sur Arduino afin de voir ce que notre capteur renvoyait et comment nous pourrions donc l'utiliser par la suite. Nous avons donc commencé par câbler l'accéléromètre (aide sur le site constructeur) comme on peut le voir ci-dessous :

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:test-arduino.JPG|300px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:adxl-cablage.png|300px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Câblage sur la plaque
| valign="center" | Plan donné sur le site
|}

À la suite du câblage de la plaque de test, nous devions réaliser un programme sous le logiciel Arduino qui correspondait à nos besoins : renvoyer les données acquises par le capteur suivant les 3 axes, x, y et z :
Pour affecter la bonne broche à chaque axe, on utilise (dans le cas de x) :
const int xpin = A0;
Afin d'imprimer les valeurs, nous utilisons (toujours dans le cas de x) :
Serial.print(analogRead(xpin));
Enfin, "delay" correspond au temps d'affichage entre deux valeurs.
[[Fichier:Projet_ard.png|400px|thumb|center|Programme Arduino pour afficher les axes x, y et z]]

Nous avons effectué 3 test d'emplacement pour notre podomètre. Pour chaque emplacement, nous avons tracé un graphique avec les valeurs obtenues afin de voir plus clairement comment faire la suite du projet. En fonction des tests effectués, nous nous sommes rendu compte que l'affichage de tout les axes n'étaient pas nécessaire. En effet :
* Sur le pieds, nous n'avons affichés que l'axe y. Cet emplacement n'a pas été retenu car les valeurs renvoyées sont trop difficiles à exploiter.
* Dans le cas parfait ou l'accéléromètre est sur la table et nous le bougeons par à-coups, nous n'affichons que l'axe y. Les résultats sont très bons.
* Dans le cas ou le capteur est tenu dans la main, nous n'affichons que l'axe x. Les résultats sont tout à fait exploitables et la situation étant plus proche de la réalité, c'est cet emplacement que nous avons choisi.

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-pieds.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-table.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-main.png|250px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | 5 pas réalisés avec le capteur sur le pieds
| valign="center" | 4 "pas" réalisés avec le capteur sur la table
| valign="center" | 7 pas réalisés avec le capteur dans la main
|}

L'objectif de la deuxième séance, au niveau informatique, sera de réaliser la liaison port-série.

== Séance 2 ==

=== Partie électronique ===

Le but de cette seconde séance dans la partie électronique, était de réaliser la conversion analogique-numérique grâce à la MLI. Nous nous sommes donc renseigné sur internet, ainsi que sur certains projets des années précédentes utilisant une conversion à l'aide de la MLI, afin de comprendre un peu mieux en quoi cela consistait. Premièrement, nous devons générer un signal (généralement triangulaire d'après nos recherches). Notre signal à synthétiser sera alors comparé à ce signal triangulaire que nous voulons générer. Le résultat de la MLI sera alors notre signal analogique, mais sous forme de signal tout ou rien ("0" ou "1"). Le schéma suivant illustre la MLI, on retrouve en haut en bleu, le signal triangulaire, et en rouge notre signal analogique (pour notre cas de l'accéléromètre) à synthétiser. Enfin en bas, le résultat :

[[Fichier:pwmproj.png|400px|thumb|center|Résultat d'une MLI]]

Nous avons donc dans un premier temps, réalisé sur Altium, le schéma à lire par la Nanoboard. Nous avons utilisé un compteur 8 bits, sur lequel nous avons connecté une horloge, ainsi qu'un module nous permettant de donner plusieurs valeurs à la MLI pour réaliser nos tests. Enfin, nous avons choisi d'utiliser simplement le bloc PWM proposé par le logiciel Altium :

[[Fichier:altium-mli.JPG|700px|thumb|center|Schéma Altium de la MLI]]

La sortie HA3 nous permet de visualiser le signal d'horloge, tandis que la sortie HA5 est la sortie de la MLI.

Nous obtenons comme prévu pour le moment, un signal carré que nous allons par la suite devoir filtrer pour qu'il "devienne" triangulaire. Le filtre passe-bas que nous allons utiliser, est constitué d'une résistance R=68kΩ et d'une capacité C=8,2nF ce qui nous donne un fréquence de coupure égale à <math>Fc = 1/(2*pi*RC) = 285 Hz</math>. Nous avons essayé plusieurs composant afin d'obtenir un signal triangulaire, qui redescend rapidement.

[[Fichier:mli-test1.JPG|500px|thumb|center|Premier signal obtenu pour une valeur quelconque]]

Ci dessous, la réalisation du filtre ainsi que les résultats obtenus (le signal n'est pas parfaitement triangulaire mais est utilisable pour la suite du projet).

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:filtre-rc.JPG|500px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:mli-test.JPG|500px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Filtre RC câblé sur notre plaque
| valign="center" | Signal obtenu après filtrage
|}

=== Partie informatique ===

Nous avons continué à utiliser notre capteur via l'Arduino afin de faire les simulations nécessaires à la liaison port-série.

Voici le code Arduino simplifié par rapport à la séance précédente, afin de recevoir uniquement les valeurs en X, Y et en Z du capteur :
(et ainsi de ne pas prendre en compte les tabulations et le retour à ligne)

[[Fichier:arduino2.png|500px|thumb|center]]

Plus tard, de légères modifications pourront encore être apportées : tous les axes ne nous sont peut-être pas nécessaires, et le délai entre 2 acquisitions devra être utile à notre application de podomètre.

'''Protocoles de communication'''

Cette partie assure la communication entre nos différents éléments, ici pour l'instant entre l'ordinateur et l'Arduino.
Elle est tirée du programme exemple, adapté afin de ne rien renvoyer et pour lire 3 valeurs les unes à la suite des autres.

int main(void){
int i=0;
int intm;
int x,y,z;
int sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
if(read(sd,&intm,sizeof(int))!=1){
perror("main.read"); exit(-1); }
if(i%3==0){
x=intm;
printf("%d ",x%20);
}
if(i%3==1){
y=intm;
printf("%d ",y%20);
}
if(i%3==2){
z=intm;
printf("%d\n",z%20);
}
i++;
sleep(0.5);//attendre
}
serialClose(sd);
exit(0);
}

L'entier i utilisé avec ''modulo 3'' nous sert à savoir quelle valeur est actuellement lue entre X, Y et Z.
Les ''modulo 20'' sont ici parce que les valeurs lues sont beaucoup trop grandes par rapport à leur variation. Ils servent donc à avoir des valeurs qui seront plus facilement exploitables par la suite.

Lors de la prochaine séance, dans la partie informatique il faudra nous pencher sur la liaison WebSocket. Ensuite nous pourrons mettre l'ensemble des fichiers en association, afin que les valeurs transmises soient exploitées, et affichées sur notre interface Web.

== Séance 3 (+ séances supplémentaires)==

=== Partie électronique ===

Lors de cette dernière séance, notre objectif dans un premier temps était de faire la comparaison entre notre signal MLI et les données envoyées par le capteur. A l'aide d'une datasheet trouvée sur internet, nous avons câblé l'AOP en comparateur de la manière suivante :

[[Fichier:montage_projet.png|700px|thumb|center|Montage de comparaison]]

Sur l'entrée Vin(+), on trouve le signal envoyé par notre capteur, et sur l'entrée Vin(-) notre signal MLI. La sortie de l'AOP (Vout) est sur la photo relié à l'oscilloscope afin de visualiser la résultat de notre comparaison. Par la suite, il sera renvoyé vers la FPGA.

Nous obtenons donc un signal rectangulaire, qui correspond à notre conversion. Nous avons pu observer que ce signal est bien modifié lorsque nous bougeons le capteur.

[[Fichier:result-mli.JPG|700px|thumb|center|Signal final, résultat de la conversion grâce à la MLI]]

La dernière partie (hormis la liaison série) était donc de renvoyer ces données de conversion dans la FPGA, pour les stocker temporairement, et ensuite les transmettre à la liaison série. Pour stocker les valeurs, nous avons décidé d'utiliser une bascule. La sortie de cette bascule sera relié à la partie "envoie" de notre liaison série. Nous ne recevons rien, nous allons donc couper les sorties du module de réception de la liaison série. Après avoir demandé les .Vhd, nous les avons inclus dans notre schéma FPGA :

[[Fichier:fpga-projet.png|700px|thumb|center|Schéma Altium final]]

Finalement, la compilation du programme ne fonctionne plus et nous n’arrivons pas à régler le problème provenant de la liaison série.

=== Partie informatique ===

Il nous fallait maintenant établir la liaison sur le serveur WebSocket. Nous avons repris et modifié les exemples qui nous ont été donnés, voici ce que l'on a obtenu :

Pour le fichier .c nous avons fait en sorte de recevoir les données envoyées par le capteur. Nous ne recevons les données ne venant que de l'un des trois axes, car nous pensons cela satisfaisant pour savoir quand un pas est fait.

case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(write(sd,&d,sizeof(char))!=1){perror("main.write"); exit(-1);}
int i;
if(read(sd,i,sizeof(char))!=1){perror("main.read"); exit(-1);}
sprintf(out,"%d",i);
libwebsocket_write(wsi,(unsigned char*)out,strlen(out),LWS_WRITE_TEXT);
libwebsocket_callback_on_writable(this,wsi);
break;

Quant à la page HTML, voici le résultat obtenu ainsi que son code source :

[[Fichier:aperçu.png|500px|thumb|center]]
[[Fichier:codeSource.png|500px|thumb|center]]

== Démonstration ==

== Conclusion ==

Projet IMA3 P4, 2015/2016, TD1

2016-03-31T18:09:41Z

Mrohmer : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : Podomètre =

== Cahier des charges ==

L'objectif de notre projet IMA3 est de créer un système qui mesure le nombre de pas effectués : un podomètre. L'utilisateur pourra choisir un nombre de pas à effectuer, et lorsque ce nombre sera atteint, une LED verte s'allumera. Sur l'application WEB, on trouvera l'affichage du nombre de pas, d'un bouton de remise à zéro des pas ainsi qu'une fenêtre pour saisir le nombre de pas à effectuer. Nous utiliserons une liaison filaire comme demandé, cependant, le système pourra être amélioré avec une liaison WI-FI.

Pour réaliser ce projet, nous aurons besoin du matériel suivant :

* Un accéléromètre dont nous nous servirons pour caractériser et repérer les pas de l'utilisateur
* Une LED qui signalera que le nombre de pas saisi est atteint
* Une Nanoboard
* Un PC
* Une Raspberry Pi

== Séance 1 ==

=== Partie électronique ===

Lors de cette séance, nous avons commencé à réfléchir à la manière dont notre projet allait fonctionner, nous voulions en quelque sorte découper notre cahier des charges en plusieurs parties pour le réaliser plus facilement. Au final, la partie électronique consistait principalement à la conversion annalogique-numérique des valeurs transmises par l’accéléromètre, ainsi qu'à choisi/câbler les composants, et enfin à transmettre le résultat de la conversion vers la Raspberry Pi. Après avoir été renseignés par les professeurs, nous avons choisi d'utiliser la MLI (modulation de largeur d'impulsion) pour effectuer notre conversion : ce sera l'objectif de la séance 2.

[[Fichier:projet-mtp.png|500px|thumb|center|Schéma du montage pour réaliser la MLI]]

=== Partie informatique ===

Durant la première séance, en informatique, nous avons "découvert" réellement ce qu'était l'accéléromètre. Cette séance a consisté à réaliser une série de tests sur Arduino afin de voir ce que notre capteur renvoyait et comment nous pourrions donc l'utiliser par la suite. Nous avons donc commencé par câbler l'accéléromètre (aide sur le site constructeur) comme on peut le voir ci-dessous :

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:test-arduino.JPG|300px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:adxl-cablage.png|300px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Câblage sur la plaque
| valign="center" | Plan donné sur le site
|}

À la suite du câblage de la plaque de test, nous devions réaliser un programme sous le logiciel Arduino qui correspondait à nos besoins : renvoyer les données acquises par le capteur suivant les 3 axes, x, y et z :
Pour affecter la bonne broche à chaque axe, on utilise (dans le cas de x) :
const int xpin = A0;
Afin d'imprimer les valeurs, nous utilisons (toujours dans le cas de x) :
Serial.print(analogRead(xpin));
Enfin, "delay" correspond au temps d'affichage entre deux valeurs.
[[Fichier:Projet_ard.png|400px|thumb|center|Programme Arduino pour afficher les axes x, y et z]]

Nous avons effectué 3 test d'emplacement pour notre podomètre. Pour chaque emplacement, nous avons tracé un graphique avec les valeurs obtenues afin de voir plus clairement comment faire la suite du projet. En fonction des tests effectués, nous nous sommes rendu compte que l'affichage de tout les axes n'étaient pas nécessaire. En effet :
* Sur le pieds, nous n'avons affichés que l'axe y. Cet emplacement n'a pas été retenu car les valeurs renvoyées sont trop difficiles à exploiter.
* Dans le cas parfait ou l'accéléromètre est sur la table et nous le bougeons par à-coups, nous n'affichons que l'axe y. Les résultats sont très bons.
* Dans le cas ou le capteur est tenu dans la main, nous n'affichons que l'axe x. Les résultats sont tout à fait exploitables et la situation étant plus proche de la réalité, c'est cet emplacement que nous avons choisi.

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-pieds.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-table.png|250px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:capteur-main.png|250px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | 5 pas réalisés avec le capteur sur le pieds
| valign="center" | 4 "pas" réalisés avec le capteur sur la table
| valign="center" | 7 pas réalisés avec le capteur dans la main
|}

L'objectif de la deuxième séance, au niveau informatique, sera de réaliser la liaison port-série.

== Séance 2 ==

=== Partie électronique ===

Le but de cette seconde séance dans la partie électronique, était de réaliser la conversion analogique-numérique grâce à la MLI. Nous nous sommes donc renseigné sur internet, ainsi que sur certains projets des années précédentes utilisant une conversion à l'aide de la MLI, afin de comprendre un peu mieux en quoi cela consistait. Premièrement, nous devons générer un signal (généralement triangulaire d'après nos recherches). Notre signal à synthétiser sera alors comparé à ce signal triangulaire que nous voulons générer. Le résultat de la MLI sera alors notre signal analogique, mais sous forme de signal tout ou rien ("0" ou "1"). Le schéma suivant illustre la MLI, on retrouve en haut en bleu, le signal triangulaire, et en rouge notre signal analogique (pour notre cas de l'accéléromètre) à synthétiser. Enfin en bas, le résultat :

[[Fichier:pwmproj.png|400px|thumb|center|Résultat d'une MLI]]

Nous avons donc dans un premier temps, réalisé sur Altium, le schéma à lire par la Nanoboard. Nous avons utilisé un compteur 8 bits, sur lequel nous avons connecté une horloge, ainsi qu'un module nous permettant de donner plusieurs valeurs à la MLI pour réaliser nos tests. Enfin, nous avons choisi d'utiliser simplement le bloc PWM proposé par le logiciel Altium :

[[Fichier:altium-mli.JPG|700px|thumb|center|Schéma Altium de la MLI]]

La sortie HA3 nous permet de visualiser le signal d'horloge, tandis que la sortie HA5 est la sortie de la MLI.

Nous obtenons comme prévu pour le moment, un signal carré que nous allons par la suite devoir filtrer pour qu'il "devienne" triangulaire. Le filtre passe-bas que nous allons utiliser, est constitué d'une résistance R=68kΩ et d'une capacité C=8,2nF ce qui nous donne un fréquence de coupure égale à <math>Fc = 1/(2*pi*RC) = 285 Hz</math>. Nous avons essayé plusieurs composant afin d'obtenir un signal triangulaire, qui redescend rapidement.

[[Fichier:mli-test1.JPG|500px|thumb|center|Premier signal obtenu pour une valeur quelconque]]

Ci dessous, la réalisation du filtre ainsi que les résultats obtenus (le signal n'est pas parfaitement triangulaire mais est utilisable pour la suite du projet).

{| style="float: center; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:filtre-rc.JPG|500px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:mli-test.JPG|500px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Filtre RC câblé sur notre plaque
| valign="center" | Signal obtenu après filtrage
|}

=== Partie informatique ===

Nous avons continué à utiliser notre capteur via l'Arduino afin de faire les simulations nécessaires à la liaison port-série.

Voici le code Arduino simplifié par rapport à la séance précédente, afin de recevoir uniquement les valeurs en X, Y et en Z du capteur :
(et ainsi de ne pas prendre en compte les tabulations et le retour à ligne)

[[Fichier:arduino2.png|500px|thumb|center]]

Plus tard, de légères modifications pourront encore être apportées : tous les axes ne nous sont peut-être pas nécessaires, et le délai entre 2 acquisitions devra être utile à notre application de podomètre.

'''Protocoles de communication'''

Cette partie assure la communication entre nos différents éléments, ici pour l'instant entre l'ordinateur et l'Arduino.
Elle est tirée du programme exemple, adapté afin de ne rien renvoyer et pour lire 3 valeurs les unes à la suite des autres.

int main(void){
int i=0;
int intm;
int x,y,z;
int sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
while(1){
if(read(sd,&intm,sizeof(int))!=1){
perror("main.read"); exit(-1); }
if(i%3==0){
x=intm;
printf("%d ",x%20);
}
if(i%3==1){
y=intm;
printf("%d ",y%20);
}
if(i%3==2){
z=intm;
printf("%d\n",z%20);
}
i++;
sleep(0.5);//attendre
}
serialClose(sd);
exit(0);
}

L'entier i utilisé avec ''modulo 3'' nous sert à savoir quelle valeur est actuellement lue entre X, Y et Z.
Les ''modulo 20'' sont ici parce que les valeurs lues sont beaucoup trop grandes par rapport à leur variation. Ils servent donc à avoir des valeurs qui seront plus facilement exploitables par la suite.

Lors de la prochaine séance, dans la partie informatique il faudra nous pencher sur la liaison WebSocket. Ensuite nous pourrons mettre l'ensemble des fichiers en association, afin que les valeurs transmises soient exploitées, et affichées sur notre interface Web.

== Séance 3 (+ séances supplémentaires)==

=== Partie électronique ===

Lors de cette dernière séance, notre objectif dans un premier temps était de faire la comparaison entre notre signal MLI et les données envoyées par le capteur. A l'aide d'une datasheet trouvée sur internet, nous avons câblé l'AOP en comparateur de la manière suivante :

[[Fichier:montage_projet.png|700px|thumb|center|Montage de comparaison]]

Sur l'entrée Vin(+), on trouve le signal envoyé par notre capteur, et sur l'entrée Vin(-) notre signal MLI. La sortie de l'AOP (Vout) est sur la photo relié à l'oscilloscope afin de visualiser la résultat de notre comparaison. Par la suite, il sera renvoyé vers la FPGA.

Nous obtenons donc un signal rectangulaire, qui correspond à notre conversion. Nous avons pu observer que ce signal est bien modifié lorsque nous bougeons le capteur.

[[Fichier:result-mli.JPG|700px|thumb|center|Signal final, résultat de la conversion grâce à la MLI]]

La dernière partie (hormis la liaison série) était donc de renvoyer ces données de conversion dans la FPGA, pour les stocker temporairement, et ensuite les transmettre à la liaison série. Pour stocker les valeurs, nous avons décidé d'utiliser une bascule. La sortie de cette bascule sera relié à la partie "envoie" de notre liaison série. Nous ne recevons rien, nous allons donc couper les sorties du module de réception de la liaison série. Après avoir demandé les .Vhd, nous les avons inclus dans notre schéma FPGA :

[[Fichier:fpga-projet.png|700px|thumb|center|Schéma Altium final]]

Finalement, la compilation du programme ne fonctionne plus et nous n’arrivons pas à régler le problème provenant de la liaison série.

=== Partie informatique ===

Il nous fallait maintenant établir la liaison sur le serveur WebSocket. Nous avons repris et modifié les exemples qui nous ont été donnés, voici ce que l'on a obtenu :

Pour le fichier .c nous avons fait en sorte de recevoir les données envoyées par le capteur. Nous ne recevons les données ne venant que de l'un des trois axes, car nous pensons cela satisfaisant pour savoir quand un pas est fait.

case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(write(sd,&d,sizeof(char))!=1){perror("main.write"); exit(-1);}
int i;
if(read(sd,i,sizeof(char))!=1){perror("main.read"); exit(-1);}
sprintf(out,"%d",i);
libwebsocket_write(wsi,(unsigned char*)out,strlen(out),LWS_WRITE_TEXT);
libwebsocket_callback_on_writable(this,wsi);
break;

Quant à la page HTML, voici le résultat obtenu ainsi que son code source :

[[Fichier:aperçu.png|500px|thumb|center]] [[Fichier:codeSource.png|500px|thumb]]

== Démonstration ==

== Conclusion ==

Fichier:CodeSource.png

2016-03-31T18:08:34Z

Mrohmer :

Projet IMA3 P4, 2015/2016, TD1

2016-03-31T18:06:02Z

Mrohmer : /* Partie informatique */

Fichier:Aperçu.png

2016-03-31T17:59:12Z

Mrohmer :