Phoenix Suite

L’analyse de la prochaine version de Phoenix est terminée! Il y a deux petites surprises par rapport au planning initial: le gestionnaire d’indices BMI sera de la partie avec le gestionnaire de liens familiaux. Mais faisons sans plus attendre une liste des nouvelles fonctionalités:

• Ajout d’un patient.
• Ajout rapide d’un patient. En d’autres termes, il suffit d’ajouter le nom, le prénom, la date de naissance et la date d’inscription du patient pour l’ajouter. En interne, cette fiche sera notée comme incomplète et l’utilisateur pourra la mettre à jour quand il aura plus de temps.
• Modification des données d’un patient.
• Gestion des données BMI (Body/Mass index) d’un patient avec affichage graphique des données et possibilité de les ajouter/modifier/supprimer.
• Gestion des liens familiaux d’un patient. Il y a moyen d’enregistrer le fait que le patient A est le frère du patient B qui est le père du patient C. Comme pour la gestion BMI on peut ajouter/supprimer/supprimer des données.

Voici quelques liens pour avoir quelques informations supplémentaire:

• Le document d’analyse est téléchargeable ICI (Document en anglais).
• Vous pouvez laisser un commentaire pour formuler une requête ou poser une question.

Je viens de terminer l’analyse des fonctionnalités qui seront implémentées dans le prochain sprint.

Commençons par énoncer le but de cette version: créer un point d’entrée pour Phoenix Suite. Ce point d’entrée peut être subdivisé en trois parties: le “Phoenix’s Nest”, le module de recherche et la “session”.

Passons donc en revue ces concepts:

• Phoenix’s Nest: Ce concept, qui se traduit par “nid du phoenix“, est la partie de l’interface graphique qui supportera tout, ce sont les fondations de l’application. Il est responsable  de mettre à disposition de l’utilisateur toutes les fonctionnalités et d’afficher toutes les informations importantes .  Ci-dessous, un croquis de ce à quoi il ressemblera:

• Module de recherche: Est un module qui permet de chercher un patient sur différents critères. La sélection d’un patient permettra de charger une session. Voici un croquis de ce que devrait donner le module de recherche:

• Session: Une session est constituée d’un patient et propose l’accès à tous les services de gestion d’un patient. Par exemple, gestion des rendez-vous, des prescriptions etc.

Voici quelques liens pour avoir quelques informations supplémentaire:

• Le document d’analyse est téléchargeable ICI (Document en anglais).
• La liste des tests de validations se trouve ICI (Document en anglais).
• Vous pouvez laisser un commentaire pour formuler une requête ou poser une question.

Il m’arrive, en temps qu’informaticien, d’utiliser des mots totalement incompréhensibles qui pourrait me faire paraître pour un extra-terrestre. Pour que vous continuiez à me comprendre, j’ai commencé à lister tous ces mots barbare dans un glossaire que je mettrai à jour régulièrement. Pour l’heure, c’est ICI que ça se passe…

Étant donné que je suis en plein dans la phase d’analyse de la couche métier, il est normal que cela change. Voici donc les modifications apportées ces derniers jours…

Deux petites choses:

• Les pathologies sont maintenant classifiées par type.
• Les factures ont temporairement disparues.

Après discussion avec un ostéopathe, nous somme arrivé à la conclusion qu’il est inutile de relier une facture à un rendez-vous. De plus, Phoenix se concentre d’abord sur la gestion des patients.

Veuillez noter que, de part la phase d’analyse du module métier, je reste ouvert à toute proposition relative à la gestion des patients.  Puisque je suis en train de travailler dans ce module, tout demande à ce sujet sera implémentée quasi en temps réel Pour ce faire, il suffit de laisser un commentaire sur ce billet.

Ci dessous, le schéma modifié:

(Cliquez sur l’image pour la voir en grand)

Hier soir, j’étais au téléphone avec ma belle et tendre fiancée quand elle me dit que cela faisait un long moment que je n’écrivais plus rien au sujet de Phoenix Suite.  J’écris donc ce billet pour corriger cette erreur!

Cette fois-ci, je ne pourrais pas montrer de jolis  screenshots de l’interface graphique puisque le code que j’ai écris fait partie de la partie dite de “sous le capot“. J’ai fais quelques ajouts dans la logique métier, j’ai implémenté deux nouveaux modules et  j’ai reciblé les différentes technologies utilisées afin de rendre Phoenix le plus stable et adaptable possible.

Voici un résumer des derniers changements:

• Module de Log:
  J’ai rafraîchi toute la partie liée au logging afin de pouvoir cibler le plus facilement possible toutes les erreur et les bugs.  Une fois en production, c’est le dernier lien que j’aurais avec Phoenix pour chasser les bugs… C’est donc un module très sensible et qui doit être bien écrit!
• Module de Traduction:
  Initialement Phoenix est écrit en anglais mais il contient déjà un module de traduction qui comprendra au moins trois langues (peut-être quatre) dès sa sortie: Anglais, Français, Espagnole et peut-être Néerlandais. Ce module est finalisé et est prêt à subir la batterie de test avant d’être apte à la mise en production.
• Phoenix Core:
  C’est le cœur de Phoenix, c’est lui qui contient toute la logique métier. Après une discussion avec un ostéopathe,  j’ai ajouté un lien familial entre les patients. En d’autres termes, il sera possible de refaire un arbre généalogique de vos patients.  Ce module est toujours en travaux et peut donc subir quelques changements, mais ils resteront subtiles. Vous pourrez voir ci-dessous la schéma du module:

(Cliquez sur l’image pour la voir en grand)

Pour conclure  je vais rappeler les différents but que Phoenix 2 cible

• Versatilité du point de vue de son interface graphique, il sera donc très facile de créer de nouvelles interface graphique voire même laisser la possibilité à l’utilisateur de choisir laquelle il désire.
• Indépendance par rapport à la base de données. Une fois mature, Phoenix suivra la mode des systèmes distribués: une base de données centrale et des clients qui accède cette base de données. Bref une optique ou l’ostéopathe ne sera plus seul mais accompagné d’une secrétaire ou de collègues. La base de données de ce nouveau système ne sera plus SQLite mais probablement MySQL (ou n’importe quelle base de données qui gère les connexion multiples).

Je viens de terminer le code du moteur de recherche de Phoenix 2. Je vais en profiter pour donner quelques mots d’explication sur celui-ci.

Comme vous pouvez le voir sur l’image ci-dessous, l’interface graphique est sobre et complète.  La fenêtre se divise en deux parties. La moitié supérieure comprend les critères de recherche, il suffit de cocher les critères désirés et ensuite cliquer sur le bouton “rechercher“. Le moitié inférieure contient les résultats de la recherche et pour sélectionner un élément du résultat, il suffit de le double-cliquer ou de le sélectionner à la souris et de confirmer par le bouton “sélectionner“. L’utilisateur peut également changer à tout moment la taille des deux parties de la fenêtre.

J’ai programmé ce module pour le rendre adaptable facilement à n’importe quelle partie de la base de données (même celle qui n’existe pas encore!). Je pourrais très facilement donner la main à l’utilisateur pour qu’il choisisse lui même, via une interface de configuration, les critères qu’il souhaite utiliser pour ses recherche. Donc si je rencontre une demande dans cette voie, j’implémenterai cette fonctionnalité!

(Cliquez sur l’image pour la voir en grand)