Dans cette section, est réservée à la présentation des outils logiciels nécessaires à la mise en place e l'application. Ensuite, il sera nécessaire de détailler les différents diagrammes utiliser pour modéliser notre application.

1. Méthodes et outils de modélisation

1.1. Langage de modélisation (UML)
Pour la conception de notre système nous avons adopté une méthode orientée objet. En effet cette dernière est une approche incontournable dans le cadre du développement des applications. 
Pour mieux présenter l’architecture de notre système, on va choisir le langage de modélisation le plus adopté UML:
C'est un langage de modélisation, défini comme une norme de modélisation objet qui sert à décrire et à documenter un système d'information.
En utilisant ce langage, les objectifs de la modélisation objet suivant sont assurés :

• Formaliser la conception d’application.
• Faciliter la communication entre les différents intervenants au sein d’un projet informatique.
• Coordonner les activités entre les différents intervenants.
• Gérer l’évolution d’un projet informatique.
• Proposer des outils standardisés prenant en compte de nombreux aspects de la conception.

1.2.  L’outil de modélisation
StarUML est un logiciel de modélisation UML, cédé comme open source par son éditeur, à la fin de son exploitation commerciale, sous une licence modifiée de GNU GPL.
StarUML gère la plupart des diagrammes spécifiés dans la norme UML 2.0, il est écrit en Delphi, et dépend de composants Delphi propriétaires.
1.3. Identification des acteurs et des cas d’utilisation 
Les acteurs sont les entités externes qui interagissent directement avec le système et communiquent avec ce dernier par émission et réception de messages
Les acteurs et les cas d’utilisation sont résumés dans le tableau suivant :

Tableau 2:Identification des acteurs et des cas d'utilisations

2. Diagrammes de cas d’utilisation

Un diagramme de cas d’utilisation est un graphe d’acteurs, un ensemble de cas d’utilisation englobés par la limite du système, des relations de communication entre les acteurs et les cas d’utilisation, et des généralisations de ces cas d’utilisation.
2.1. Diagramme de cas d’utilisation de l'administrateur
L’administrateur du système peut gérer les spécialités, en ajoutant une nouvelle spécialité ou/et en modifiant une qui existe déjà.
De plus l’administrateur est le seul qui a le droit d’accepter ou rejeter un médecin. 
En effet, après la vérification de la carte d’identité envoyée par le médecin, l’administrateur a la possibilité de valider ou bien de refuser l’inscription de ce dernier. 

Figure : Diagramme de cas d'utilisation de l’administrateur
2.2.1. Description du cas d’utilisation gestion des spécialités

Tableau : Description du cas d’utilisation Gestion des spécialités

2.2. Diagramme de cas d'utilisation du patient
 
Figure : Diagramme de cas d'utilisation du patient
Pour pouvoir accéder aux différentes fonctionnalités de l’application, le patient doit se connecter s’il possède déjà un compte, sinon il doit créer un compte.
Un patient peut chercher un médecin directement à partir de la carte où chaque médecin enregistré dans le système a un marqueur, de plus il peut chercher un médecin par son nom ou par sa spécialité.
Une fois le médecin a été sélectionné, le patient peut prendre un rendez-vous selon la disponibilité du médecin.
Après avoir pris un rendez-vous, le patient peut consulter la liste de ses rendez-vous (acceptés, refusés et en attente). Tant que le rendez-vous est encore en attente, le patient a la possibilité de l’annuler.
Le patient peut aussi changer les informations de son compte.
Si un rendez-vous a été accepté par le médecin et le patient rate la consultation plusieurs fois son compte sera supprimé.  
2.3.1. Description du cas d’utilisation de prise de rendez-vous

 Tableau 4: description du cas d’utilisation de prise de rendez-vous

2.3.2. Description du cas d’utilisation de recherche de médecin

Tableau 5: description du cas d’utilisation de recherche de médecin

2.3.3. Description du cas d’utilisation de création du compte patient

Tableau 6: description de cas de création du compte patient

2.3. Diagramme de cas d'utilisation du médecin
 
Figure 7: Diagramme de cas d'utilisation du médecin
Le médecin dans le système peut gérer ses disponibilités, il peut ajouter ou modifier ses jours et heure de travail.
De plus, le médecin peut accepter ou refuser un rendez-vous.
Si un rendez-vous est accepté, le médecin peut gérer le dossier du patient: il peut ajouter une ordonnance, ajouter une observation ou télécharger une fiche médicale.
Le médecin peut aussi consulter les statistiques des rendez-vous. 
  
3.  Etude de quelques diagrammes des séquences 

3.1. Diagramme de séquence de prise de rendez-vous 
 
Figure 8: Diagramme de séquence prendre rendez-vous
Pour prendre un rendez-vous, le patient sélectionne la date et l’heure du rendez-vous souhaité. Après la vérification de la disponibilité du médecin, le rendez-vous est enregistré dans la base de données et un message de confirmation s’affiche au patient. Si la date et/ou l’heure sélectionnée ne correspondent pas à la disponibilité du médecin, le système envoie un message d’erreur au patient pour lui informer que son rendez-vous n’a pas été enregistré et lui demande de choisir une autre date. 
3.2. Diagramme de séquence de recherche du médecin
 
Figure 9: Diagramme de séquence de recherche du médecin
Le patient peut chercher un médecin par son nom, sa spécialité ou par sa localisation sur la carte. La localisation des médecins sur la carte est disponible en deux modes : terrain et satellite.  
Le patient peut choisir celui qui lui convient le mieux, c’est une fonctionnalité gérée par l’API de Google adaptée pour un usage facile et rapide. 
Le patient peut choisir un médecin directement en cliquant sur son marqueur sur la carte. Pour chercher un médecin par spécialité, il suffit de choisir une des spécialités existantes dans la base de données et le système affiche la liste des médecins de cette spécialité.
En plus, le patient a la possibilité de chercher un médecin par son nom. Pour cela,  il suffit de saisir un nom et le système affiche la liste des médecins avec ce nom.
3.3 Diagramme de séquence de création du compte patient
 
Figure 10: Diagramme de séquence de création du compte patient
Pour accéder à l’application, le patient doit avoir un compte.
 Pour crée un compte, le patient doit saisir les informations demandées correctement puis le système vérifie ces informations et si n’a pas des erreurs le compte sera créé et les informations seront enregistrées dans la base de données.

3.4 Diagramme de séquence de l’administrateur
 
Figure 11: diagramme de séquence de l'administrateur
Une fois authentifié, l’administrateur a le droit de gérer les spécialités :

• Il peut consulter la liste de toutes les spécialités existantes dans la base de données
• Il peut ajouter une nouvelle spécialité 
• Il peut modifier une spécialité qui existe déjà. 

De plus, l’administrateur peut consulter la liste des médecins. Si le compte du médecin est inactif, il vérifie la copie de la carte d’identité nationale envoyée par ce dernier. Suite à cette vérification, il peut soit activer le compte du médecin soit annuler son inscription.
L’administrateur de système peut changer son mot de passe. 
4. Diagramme de classes
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce diagramme fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et dynamiques.
Dans notre diagramme de classes on a trois classes (administrateur, médecin et patient) qui hérite d’une classe mère nommé utilisateur.
Un patient peut prendre un rendez-vous avec un médecin, et ce dernier peut accepter ou refuser le rendez-vous selon son horaire de travail, si le rendez-vous est accepté il faut avoir un dossier patient qui contient les observations et les ordonnances de rendez-vous.
Un médecin admet une spécialité gérée par l’administrateur du système.
L’administrateur valide le compte d’un médecin après la vérification de sa carte d’identité nationale.    
 
 
Figure 12: Diagramme de classes

5.  Schéma de la base de données
Nous avons utilisé le système de gestion de base de données relationnel MySQL pour enregistrer les tables de notre système.
 Nous avons choisi ce SGBD vu qu’il est très léger et simple à utiliser et configurer, de plus il est open source et tous les hébergeurs web le fournie avec leurs packs d’hébergement. 
La figure ci-dessous montre les relations entre les différentes tables de notre système.
 
 
Figure 14: Schéma relationnel de la base de données
 
6. Conception architecturale
Le pattern modèle-vue-contrôleur(en abrégé MVC, de l'anglais model-view-controller), est un modèle destiné à répondre aux besoins des applications interactives en séparant les problématiques liées aux différents composants au sein de leur architecture respective.
Ses avantages :

• Séparation des compétences (design, base de données, application)
• Simplicité de mise à jour
• Vitesse de création de pages.

Ce paradigme regroupe les fonctions nécessaires en trois catégories :

• Un modèle (Modèle de données) ;
• Une vue (présentation, interface utilisateur) ;
• Un contrôleur (logique de contrôle, gestion des événements, synchronisation).

Nous expliquons ces trois parties l'une après l'autre :

• Le modèle (ou Model) :

Le modèle représente les structures de données. Typiquement, les classes modèles contiennent des fonctions qui aident à récupérer, à insérer et à mettre à jour des informations de la base de données.
Par exemple, lorsque nous disons« le contrôleur récupère les données d’un outil», il va en fait, faire appel au modèle Outil (« Tool »). C'est le modèle qui peut récupérer les données de cet outil, généralement via une requête au serveur SQL. Au final, il permet au contrôleur de manipuler les outils mais sans savoir comment ils sont stockés, gérés, etc. C'est une couche d'abstraction.

• La vue (ou View) :

La vue correspond à l'interface avec laquelle l'utilisateur interagit. Elle se présente sous la forme d'une Template représentant l'interface.
Reprenons l'exemple de l’outil. Ce n'est pas le contrôleur qui affiche le formulaire, il ne fait qu'appeler la bonne vue. Si nous avons une vue formulaire, les balises HTML du formulaire d'édition de l’outil y seront et finalement le contrôleur ne fera qu'afficher cette vue sans savoir vraiment ce qu'il y a dedans.
Donc en pratique, c'est le « designer » d'un projet qui travaille sur les vues. La séparation de vues et contrôleurs permet aux designers et aux développeurs PHP de travailler ensemble sans besoin de contact direct.

• Le contrôleur (ou Controller) :

Il gère l'interface entre le modèle et le client. Il va interpréter la requête de ce dernier pour lui envoyer la vue correspondante. Il effectue la synchronisation entre le modèle et les vues.
Il est la couche qui se charge d'analyser et de traiter la requête de l'utilisateur. Le contrôleur contient la logique de notre application et va se contenter « d'utiliser » les autres composants : les modèles et les vues. Concrètement, un contrôleur va récupérer, par exemple, les informations sur l'utilisateur courant, vérifier qu'il a le droit de modifier un tel outil, récupérer les données de cet outil et demander la page du formulaire d'édition de l’outil.

Figure 15: Pattern MVC

7. Charte graphique 
7.1.  Le logotype 
7.1.1. Les données colo-métriques :

• Le logotype apparaît toujours avec le texte, qui se compose du nom « Allo Doc» (référence typo :Rakoon Medium ).
• Le logotype se compose de 3 couleurs et une valeur, il se compose de trois nuances de colure bleu. 

figure : les 3 nuance de bleu dans le logo

Le bleu symbolise la relaxation, la confiance, la fiabilité,  la satisfaction, le calme, la passivité, la propreté c’est pour quoi on a utilisé ce colleur pour notre logo.

8. Prototypes d’interface
Dans cette section nous listons quelques prototypes d’interfaces de notre système.
 
Figure 17: Prototype d’interface d'accueil
La figure ci-dessus montre le prototype d’interface d’accueil de l’application du médecin.
Dans cette interface nous trouvons un calendrier qui contient les rendez-vous acceptés et des liens vers la page de statistiques et la page de gestion des rendez-vous.
La figure ci-dessous montre le prototype du page d’inscription dans l’application web, cette interface est très importante car elle est la première interaction du médecin avec notre système, alors nous choisissons une interface très simple qui contient quelques champs de texte à remplir par des informations du médecin comme son nom, son prénom, son email, son mot de passe, son prix de visite …
Cette interface doit être anti-spam alors nous aurons mis un système de vérification de type ReCAPTCHA pour éliminer les inscriptions des rebout.
Pour compléter l’inscription, le médecin doit accepter les termes d’utilisation du système. 
 
Figure : prototype d'interface d'inscription