Rapportpfe

REPUBLIQUE TUNISIENNE
MINESTRE DE L’ENSEIGNEMENT SUPERIEURE
ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE TUNIS EL MANAR
FACULTE DES SCIENCES DE TUNIS
DEPARTEMENT DES SCIENCES DE L’INFORMATIQUE
Projet de Fin d’Etudes
Pour l’obtention du Diplôme de
Licence Fondamentale en Sciences Informatiques
Conception et Réalisation d’une application mobile
De diagnostic automobile à l’aide de l’Elm 327
Présenté par :
TLILI Bilel
SAADALAH Med Amir
Encadré par :
Mr. HIZEM Moez
Mr. GARA Samir
Organisme d’accueil : Canadian Software Technology (CST)
Adresse : 4,4 Bloc I espace de Tunis Mon plaisir, Tunis, Tunisie
Tél :(+216)71905101 – Fax :(+216)71905407
Email : info@cst.com.tn
Année Universitaire 2015/2016

Rapport de projet de fin d’études
2 | P a g e
Table des matières
INTRODUCTION GENERALE........................................................................................................................................7
CADRE GENERAL DU PROJET......................................................................................................................................9
INTRODUCTION...........................................................................................................................................................10
I. PRESENTATION DEL’ORGANISMED’ACCUEIL.......................................................................................................10
1. Présentation générale............................................................................................................................10
2. Les étapes clés de la société .................................................................................................................11
3. Organisation Structurelle ......................................................................................................................11
II. ETUDEDEL’EXISTANT ........................................................................................................................................12
III. PRESENTATION DU PROJET.................................................................................................................................13
1. Problématique abordée .........................................................................................................................13
2. Solution proposée ...................................................................................................................................13
3. Objectif du projet....................................................................................................................................13
IV. METHODOLOGIEADOPTEE.................................................................................................................................14
1. Le formalisme UML ................................................................................................................................14
2. Processus de développement itératif et adaptatif............................................................................15
2.1 Processus de développement logiciel............................................................................................. 15
2.2 Développement itératif et incrémental.......................................................................................... 15
2.3 Définition des termes...................................................................................................................... 16
CONCLUSION..............................................................................................................................................................16
ANALYSE DES BESOINS..............................................................................................................................................17
INTRODUCTION...........................................................................................................................................................17
I. IDENTIFICATION DES ACTEURS ............................................................................................................................18
II. SPECIFICATIONS DES BESOINS.............................................................................................................................19
1. Besoins fonctionnels...............................................................................................................................19
2. Besoins non fonctionnels .......................................................................................................................23
III. DIAGRAMMEDECAS D’UTILISATION GENERALE ...................................................................................................25
CONCLUSION..............................................................................................................................................................26
CONCEPTION ...............................................................................................................................................................27
INTRODUCTION...........................................................................................................................................................28
I. RAFFINEMENTDECAS D’UTILISATION..................................................................................................................28

3 | P a g e
1. Gérer Profile.............................................................................................................................................28
1.1 S’authentifier.................................................................................................................................. 29
1.2 S’inscrire.......................................................................................................................................... 31
1.3 Consulter profile utilisateur............................................................................................................ 33
1.4 Consulter profile voiture................................................................................................................. 34
2. Diagnostic ................................................................................................................................................36
2.1 Lancer diagnostic............................................................................................................................ 37
2.2 Consulter logs.................................................................................................................................. 40
3. Estimation & localisation ......................................................................................................................41
4. Gérer Centre de Notifications ...............................................................................................................44
4.1 Gérer évènements de l’utilisateur.................................................................................................. 44
4.2 Consulter évènements du système................................................................................................. 46
5. Gérer préférences ...................................................................................................................................48
6. Consulter Tableau de Bord....................................................................................................................50
II. DIAGRAMMEDECLASSE.....................................................................................................................................53
CONCLUSION .............................................................................................................................................................53
REALISATION ...............................................................................................................................................................54
INTRODUCTION...........................................................................................................................................................55
I. ETUDE TECHNIQUE ............................................................................................................................................55
1. Environnement de travail matériel......................................................................................................55
2. Environnement de travail logiciel ........................................................................................................56
2.1 Logiciels utilisés............................................................................................................................... 56
2.2 Technologies utilisées..................................................................................................................... 60
II. ARCHITECTURE DEL’APPLICATION.......................................................................................................................63
III. INTERFACES & MAQUETTES DEL’APPLICATION....................................................................................................65
3. Interface « Home » .................................................................................................................................65
4. Interface « Diagnostic ».........................................................................................................................66
5. Interface « Notifications Center »........................................................................................................67
6. Interface « Logs » ...................................................................................................................................67
7. Interface « Estimation & GPS » ............................................................................................................67
8. Interface « Settings & Preferences » ...................................................................................................67
.............................................................................................................................................................................68
9. Interface « Dashboard »........................................................................................................................69
CONCLUSION..............................................................................................................................................................70
CONCLUSION GENERALE...........................................................................................................................................71

4 | P a g e
Liste des figures
Figure 1:Logo du Canadian Software Technology .........................................................10
Figure 2:Diagramme de cas d'utilisation général ............................................................25
Figure 3:Diagramme de cas d'utilisation « gérer profile »........................................28
Figure 4:Diagramme de séquences « s'authentifier »......................................................30
Figure 5: Diagramme de séquences « s'inscrire » ...........................................................32
Figure 6:Diagramme de séquences « consulter profile utilisateur » ...............................34
Figure 7:Diagramme de séquences « consulter profile voiture »....................................36
Figure 8:Diagramme de cas d'utilisation « lancer diagnostic » ................................37
Figure 9:Diagramme de séquences « lancer diagnostic » ...............................................39
Figure 10:Diagramme de cas d'utilisation « consulter logs «..........................................40
Figure 11:Diagramme de séquences « consulter logs » ..................................................41
Figure 12:Diagramme de cas d'utilisation « estimation et localisation »........................41
Figure 13:Diagramme de séquences « estimation et localisation ».................................43
Figure 14:Diagramme de cas d'utilisation « gérer centre de notifications »............44
Figure 15:Diagramme de cas d'utilisation « gérer évènements utilisateur »...................44
Figure 16:Diagramme de séquences « gérer évènements de l'utilisateur ».....................46
Figure 17:Diagramme de cas d'utilisation « consulter évènement système ».................46
Figure 18:Diagramme de séquences « consulter évènements system »..........................48
Figure 19:Diagramme de cas d'utilisation « gérer préférences »..............................49
Figure 20:Diagramme de séquences « gérer préférences ».............................................50
Figure 21:Diagramme de cas d'utilisation « consulter tableau de bord »................51
Figure 22:Diagramme de séquences « consulter tableau du bord »................................52
Figure 23:Diagramme de classe ......................................................................................53
Figure 24:Logo « Microsoft Word »...............................................................................57
Figure 25:Logo « PowerAMC »......................................................................................57
Figure 26:Logo « Intel XDK »........................................................................................58
Figure 27:Logo « Intel App Preview »............................................................................58
Figure 28:Logo « LAMP »..............................................................................................59
Figure 29:Logo « Debian »..............................................................................................59

5 | P a g e
Figure 30:Logo « Apache ».............................................................................................59
Figure 31:Logo « MySQL »............................................................................................59
Figure 32:Logo PHP 5.....................................................................................................60
Figure 33:Logo « HTML 5 »...........................................................................................60
Figure 34:Logo CSS 3.....................................................................................................61
Figure 35:Logo « Cordova » ...........................................................................................61
Figure 36:Logo « JavaScript » ........................................................................................61
Figure 37:Logo jQuery....................................................................................................62
Figure 38:Logo « JSON »................................................................................................62
Figure 39:Logo Ajax .......................................................................................................63
Figure 40:Architecture de l'application ...........................................................................64
Figure 41:Interface « Menu principal »...........................................................................65
Figure 42:Interface « Diagnostic »..................................................................................66
Figure 43:Interface » Notifications Center »...................................................................67
Figure 44:Interface « Estimation »..................................................................................67
Figure 45:Interface » User »............................................................................................68
Figure 46:Interface « Car »..............................................................................................69
Figure 47:Interface « Help »............................................................................................69
Figure 48:Interface « Preferences ».................................................................................69
Figure 49:Interface » Dashboard »..................................................................................70

6 | P a g e
Liste des tableaux
Tableau 1: Description du cas d'utilisation « s'authentifier »..........................................29
Tableau 2:Description du cas d'utilisation « s'inscrire » .................................................31
Tableau 3:Description du cas d'utilisation « consulter profile utilisateur » ....................33
Tableau 4:Description du cas d'utilisation « consulter profile voiture ».........................35
Tableau 5:Description de cas d'utilisation « lancer diagnostic ».....................................38
Tableau 6:Description du cas d'utilisation « consulter logs » .........................................40
Tableau 7:Description du cas d'utilisation « estimation et localisation »........................42
Tableau 8:Description du cas d'utilisation gérer « évènements de l'utilisateur »............45
Tableau 9:Description du cas d’utilisation « consulter évènements système »...............47
Tableau 10:Description du cas d'utilisation « gérer préférences »..................................49
Tableau 11:Description du cas d'utilisation « consulter tableau du bord ».....................51

7 | P a g e
INTRODUCTION
GENERALE

8 | P a g e
Dans un domaine très important dans la vie humaine marqué par l’évolution, la
concurrence devient de plus en plus forte afin de développer une solution plus performante
pour le diagnostic des véhicules. En fait certains critères jugent quelle solution domine le
marché du diagnostic électromécanique. Donc faire mieux dans moins du temps avec moins
du coût est un défi qui suggère le comment répondre aux besoins clientes.
Dans le cadre de réalisation de notre projet de fin d’études nous avons choisi d’aller le
plus loin possible dans ce défi au sein de la société Canadian Software Technology en
espérant de développer une application mobile cross-plateforme pour diagnostic de voitures
qui soit une solution concurrente.
A travers ce rapport nous allons détailler les différentes phases nécessaires tout au long
de réalisation de l’application. Ce rapport s’articule autour de quatre chapitres :
Le premier chapitre nommé « Cadre général du projet » présentera l’organisme d’accueil
et divulguera une étude sur l’existant. Aussi, ce chapitre introduira une présentation de projet
ainsi que le choix méthodologique.
Le deuxième chapitre nommé « Analyse des besoins » détaillera la spécification générale
de futur système après l’identification de ses acteurs tout en finira par un diagramme de cas
d’utilisation général préparant au chapitre suivant.
Le troisième chapitre nommé « Conception » sera destiné à la modélisation des différents
modules de l’application développée
Le quatrième chapitre nommé « Réalisation » présentera la dernière phase de projet, en
identifiant les deux environnements de développement matériel et logiciel ainsi que
l’architecture adoptée. Ce chapitre finira par mettre l’accent sur le résultat de
l’implémentation obtenu par le biais de quelques imprimes écran des différentes
fonctionnalités.
Finalement, ce rapport se terminera par une conclusion générale qui sert à présenter le
bilan de ce projet.

9 | P a g e
Chapitre I

10 | P a g e
Introduction
Dans ce premier chapitre, il est important de définir le contexte du projet, identifier
les objectifs de notre application et les solutions que ne proposons afin de résoudre les
problématiques posées, ainsi que de bien présenter l’organisation d’accueil.
I. Présentation de l’organisme d’accueil
1. Présentation générale
Figure 1:Logo du Canadian Software Technology
Canadian Software Technology (anciennement nommée GIC : Gara Informatique &
Communication) est spécialisée dans les services en Technologie de l’Information.
Fondée à Montréal en 1989 par Mr. GARA Samir et implantée en Tunisie depuis 1997.
CST est spécialisée dans le développement de systèmes de conseils en gestion et les
services informatiques associés à une technologie de pointe. Ses secteurs de prédilection
regroupent la gestion de la production, la gestion commerciale intégrée, la mobilité et les
finances.
CST dont le souci est la satisfaction de sa clientèle et de ses collaborateurs, remporte de
plus en plus de succès grâce à la qualité de ses services, la dynamique de son personnel et
de l’architecture évolutive de ses systèmes.

11 | P a g e
Renforcé par un partenariat efficace établi avec des firmes américains & européens, CST
a connu une expérience rapide, Ses activités dépassent aujourd’hui le cadre national et la
société a plusieurs projets à l’étranger notamment en Afrique du Nord.
Avec l’émergence de nouveau prestataire de service informatique, des clients de mieux
en mieux informés et de plus en plus exigeants, le succès de CST réside dans sa rapidité à
identifier et à exploiter les opportunités, sa capacité à développer de nouveaux produits à
moindre coût et à les personnaliser en fonction des besoins spécifiques des différents
segments du marché et des clients individuels.
Les solutions développées par CST permettent à sa clientèle de créer un environnement
intégré et souple qui réagit rapidement à l’évolution de leur gestion et les aides à améliorer
leur rentabilité et relever leurs défis.
2. Les étapes clés de la société
 1989 à Montréal :
Fondation de la société sous le nom Gara Informatique & Communication (GIC)
 1997 à Tunisie :
Implantation de la société en Tunisie par Mr. GARA Samir avec le nom Canadian
Software Technology (CST)
3. Organisation Structurelle
Figure 2:Organigramme du CST

12 | P a g e
II. Etude de l’existant
Malgré l’importance de ce type d’applications, on a trouvé que les solutions existantes ne
sont pas nombreuses, en fait celles d’OBD étaient les seules solutions trouvées dans ce
domaine.
OBD a développé des applications DESKTOP (client lourd) ainsi que des applications
mobiles en Android.
Afin de développer notre part du marché et être un vrai conçurent on va se concentrer sur
trois critères essentiels :
Ergonomie de l’application :
« Torque » est la meilleure application Android en termes de design dans le domaine de
diagnostic automobile, elle est bien conçue en respectant les règles ergonomiques mais sa
facilité d’utilisation est à discuter.
On va donc s’intéresser à concevoir des interfaces riches et simple à utiliser.
Indépendance de la plateforme :
L’existant est mono plateforme seulement les utilisateurs du smartphone Android peuvent
bénéficier d’un diagnostic.
Pour cela on a choisi de développer une application hybride indépendante de la plateforme
en fait ceux qui ont des IPhones ou des smartphones Windows phone vont être capables
d’utiliser l’application.
Services offerts :
L’utilisateur cherche toujours des extras fonctionnalités pour décider quelle application
va utiliser, Torque n’offre pas à ses utilisateurs un grand choix appart les fonctionnalités de
base ce qui nous inspirons d’ajouter quelques services dans notre application tel que le
service d’estimation ainsi que l’ajout d’un centre de notification qui semble une option mais
il présente un besoin pour les conducteurs.

13 | P a g e
III. Présentation du projet
1. Problématique abordée
Une voiture n’est pas un moyen de transport seulement en fait elle représente une
nécessité vitale pour l’être humain donc il est nécessaire de la garder en bonne état pour
qu’elle soit toujours disponible et performante et répond aux besoins de ses utilisateurs mais
le problème que la diagnostique et les réparations des véhicules coutent cher et nécessitent
parfois plus de temps qu’on avait. En Tunisie, la plupart des conducteurs ne découvrent l’état
critique de leurs véhicules que si elles tombent en panne et à cet instant la maintenance ou
la réparation est trop tard.
Comment prévoit les pannes ?
Comment élimine les risques de maintenance retard ?
Quelle est la solution pour rendre notre véhicule toujours performant ?
Est-il possible de contrôler nos véhicules nos mêmes ?
Sous quelles conditions peut-on contrôler nos véhicules ?
2. Solution proposée
Les problèmes rencontrés dans le domaine de diagnostique automobile nous a mène à
penser à une application mobile indépendante de la plateforme qui est à la fois fiable et
répond bien aux besoins pour lesquelles elle est conçu.
Afin d’établir une meilleure interaction entre l’utilisateur et sa voiture pour un
fonctionnement stable et plus performant de la voiture « Car Self Care » semble une bonne
solution.
3. Objectif du projet
L’objectif de notre projet va se porter sur 3 phases principales :
 La conception
 La réalisation
 La mise en place et le déploiement

14 | P a g e
Afin de permettre aux utilisateurs de gérer leurs véhicules à travers leurs smartphones
indépendamment de système d’exploitation installé.
« Car Self Care » va permettre aux utilisateurs de bien interagir avec leurs véhicules et
assure leurs bons fonctionnements, ainsi qu’être informer sur les pannes et les problèmes qui
peuvent s’engendrent.
« Car Self Care » coute moins cher que les diagnostiques ordinaires …..
IV. Méthodologie adoptée
1. Le formalisme UML
“Unified Modeling Language” (UML), qu’on peut traduire en français par « langage de
modélisation unifié » est un langage de modélisation graphique conçu pour fournir une
méthode normalisée pour visualiser la conception d'un système. Il est couramment utilisé
en développement logiciel et en conception orientée objet.
Ce langage est conçu pour spécifier, visualiser, modifier et construire les documents
nécessaires au bon développement d'un logiciel orienté objet. UML offre un standard de
modélisation, pour représenter l'architecture logicielle. Les différents éléments
représentables sont :
 Activité d'un objet/logiciel
 Acteurs
 Processus
 Schéma de base de données
 Composants logiciels
 Réutilisation de composants
UML propose 14 diagrammes qui montrent l’évolution du système et les interactions
entre les objets. Ces diagrammes sont dépendants hiérarchiquement et se complètent, de
façon à permettre la modélisation d'un projet tout au long de son cycle de vie. Dans notre
projet on va se concentrer seulement sur certains diagrammes comme :
 Diagramme de Classes
 Diagramme des Cas d’Utilisation

15 | P a g e
 Diagramme de Séquences
 Diagrammes D’Activité
 Diagramme de Déploiement
Le diagramme de classes est un diagramme statique qui sert à identifier la structure du
système à l’aide des classes identifiées par leurs propriétés, méthodes et l’association qui les
relient entre eux. Le diagramme de classes est éventuellement le diagramme le plus
important dans la modélisation orientée objet c’est pourquoi il est obligatoire.
Le diagramme de cas d’utilisation présente les fonctionnalités fournis par le système en
identifiant son interaction avec les acteurs. Dont chaque cas d’utilisation représente un
enchainement d’événements définissant un système fonctionnel, ainsi que décrire comment
le système doit interagir avec ses acteurs (utilisateurs).
Le diagramme de séquences appartient à la classe des diagrammes dynamiques, pour ce
fait il sert à représenter d’une manière dynamique et séquentielle le déroulement des
traitements et des interactions entre les objets du système et/ou de ses acteurs à l’aide des
messages (synchrones / asynchrones).
2. Processus de développement itératif et adaptatif
2.1 Processus de développement logiciel
Un processus de développement décrit une méthode qui permet de construire, déployer
et éventuellement maintenir un logiciel. Un processus de développement définit une
séquence d'étapes, partiellement ordonnées, qui permettent d'obtenir un système logiciel ou
faire évoluer un système existant. L’objectif d’un processus de développement est de
produire des logiciels de qualité qui répondent bien aux besoins de leurs utilisateurs dans des
temps et couts prévisibles, en conséquence le processus de développement est une
méthodologie permet de donner un cadre au développement logiciel.
2.2 Développement itératif et incrémental
Le développement itératif s’organise en une série de développement très courts de durées
fixe nommée itérations. Le résultat de chaque itération est un système partiellement
exécutable, testé et intégré (mais incomplet).
Chaque itération comprend ses propres activités :

16 | P a g e
 Analyse de besoins
 Conception
 Implémentation
 Test
Le résultat d’une itération n’est pas un prototype expérimental ou « jetable ».
Comme le système croît avec le temps de façon incrémentale, cette méthode de
Développement est nommé développement itératif et incrémental.
2.3 Définition des termes
 Itératif : une itération est un cycle de développement complet
 Incrémental : chaque développement s'ajoute et enrichit l'existant. Un incrément e
st donc une avancée dans les stades de développement.
.
Conclusion
Dans ce premier chapitre on est arrivé à définir le cadre général de notre projet tout
en présentant l’organisme d’accueil ainsi que le contexte du projet. C’est le temps pour
aller en profondeur du projet tout en passant par l’analyse des besoins qui sera le sujet
du chapitre suivant.

17 | P a g e
Chapitre II
Introduction
Avant qu’un système soit complètement conçu, des contraintes doivent être prises en
considération, ces contraintes vont définir les besoins attendus par l’utilisateur et les
spécifications qui forment une fondation sur laquelle l’architecture de système est
construite.
Tout au long de ce deuxième chapitre, on va s’intéressé sur l’identification des
besoins qui tournent autour de système ainsi que ses acteurs.

18 | P a g e
I. Identification des acteurs
Acteur : producteur ou consommateur de flux d'information pouvant correspondre à
une entité administrative ou de gestion dans l'organisation. Il représente le rôle joué par l’une
des entités physiques qui interagissent avec le système en question.
Dans notre système de diagnostic automatisé des véhicules, trois types d’acteurs sont
identifiés :
 L’utilisateur :
C’est une personne physique pour laquelle le système est conçu, l’utilisateur de l’application
c’est celui qui veut gérer son véhicule a le droit de consulter tous les services offerts par
l’application qui apparaissent sur l’écran de son smartphone, En fait il peut lancer un
diagnostic, faire une estimation pour un voyage, consulter le centre de notification afin d’être
informé sur les événements prévus , ainsi que gérer son profil et paramétrer l’application , il
peut aussi consulter son tableau de bord et voir l’historique des diagnostic.
 Le serveur :
C’est une machine dédiée à l'administration et la gestion de l’accès aux ressources. Le
serveur dans notre système gère les connexions des différents utilisateurs à l’application.
Il est équipé d'un logiciel de gestion de réseau : un serveur de fichiers prépare la place
mémoire pour des données relatives aux connexions ainsi que les logs et l’historique des
diagnostic.
 L’ELM 327 :
ELM327 est un microcontrôleur programmé produit par ELM Electronique pour traduire
le diagnostic embarqué.
Notre système est basé sur cet appareil en fait c’est l’acteur principal qui présente
L’intermédiaire entre la voiture et les autres composants du système en fait il sert à
interroger la voiture et récupère un flux de données transmis par les senseurs et les différents

19 | P a g e
composants (moteur, tableau de bord, etc. …) de la véhicule et le transmet à l’application
et/ou au serveur sous forme des trames réseaux afin d’être analyser et traiter par la suite.
II. Spécifications des besoins
Tout système est la réponse à un besoin et une adaptation aux capacités de ses utilisateurs.
Donc le projet sur lequel on est en train de travailler doit s’adapter aux besoins fonctionnels
et non fonctionnels comme il doit correspondre aux capacités d’utilisateurs pour lesquels il
est destiné. En fait pour réussir à l’expression précise des besoins il est recommandé la prise
en considération la vision de l’utilisateur envers le système ainsi qu’être proche le plus
possible de lui.
La première difficulté de l’analyse de ces besoins est de se rappeler à chaque phase de
développement de ce qui est réellement le système. Pour cela on va s’adresser aux experts
du domaine, aux utilisateurs afin de bien exprimer les besoins et être sûre que le produit final
soit acceptable.
1. Besoins fonctionnels
Cette partie concerne l’ensemble des services obligatoirement soient offerts par
l’application à ses utilisateurs.
 Diagnostic :
C’est le premier service désiré par l’utilisateur parce qu’il lui offre la possibilité de
vérifier à tout moment l’état de sa voiture à travers 2 types de diagnostiques possible ainsi
que lui informe via les notifications des erreurs survenues au niveau de son véhicule.
 Notifications sur l’état de véhicule :
On distingue 2 types de notifications :
 Alertes :
Ce type de notifications s’affiche en cas des pannes ou problèmes qui n’empêchent pas
le fonctionnement normal du véhicule.

20 | P a g e
 Alertes critiques :
Ce type de notification s’affiche en cas des pannes ou problèmes qui empêchent le
fonctionnement normal du véhicule et s’accompagne parfois par l’envoie d’une notification
(mail / SMS) au centre de maintenance ou mécanicien.
 Types de diagnostic :
Afin de savoir l’état de sa voiture l’utilisateur peut choisir l’un de ces trois types
 Diagnostic rapide :
Ce diagnostic se fait la plupart du temps automatiquement et peut être lancé par
l’utilisateur sert à examiner les composants les plus importants du véhicule.
 Diagnostic complet :
Le diagnostic complet comme il indique son nom est un diagnostic qui examine tous les
composants possibles de la voiture et vérifie leur fonctionnement, Ce dernier peut prendre
quelques minutes mais ça n’empêche pas l’utilisation normale de l’application car il
s’exécute en arrière-plan.
 Paramètres et Préférences :
Ce service permet à l’utilisateur de changer les paramètres de l’application, ainsi que
changer les préférences d’utilisation qui lui concerne, Il constitue
Les fonctionnalités suivantes :
 Système d’unités (System Unit) :
 Température : F°/C°
 Distance : Mile/km
 Volume : Galon/L
 Langues(Langages) :
 Français
 Anglais

21 | P a g e
 Gestion des Connexions (Connection Management) :
 BT : On/Off
 WIFI : On/Off
 CELLULAIRE :3G/4G
 Gestion du profile utilisateur (Profil Management)
Profile
Connexion
Enregistrement
Profile voitures
 Aide(Help)
 Centre de Notifications (Notifications Center) :
Le Centre de notifications est parmi les services les plus importants de l’application, il
est conçu afin d’informer l’utilisateur de l’état de sa véhicule d’une part et de lui rappeler
des événements prévus d’autre part.
 Notifications sur les évènements utilisateur :
L’utilisateur gère des évènements concernant sa voiture et le système s’occupe de lui
notifier ses évènements.
 Notifications sur les évènements systèmes :
Ils ont pour rôle de rappeler l’utilisateur des événements prévus créés par le système à
partir de données récupères de véhicule.
 Historiques de diagnostic (Logs) :
 Logs :
Il est recommandé que l’utilisateur peut consulter l’historique de l’utilisation de
l’application autrement dit l’historique de l’interaction avec son véhicule c’est pourquoi ce
service luit offre une liste complète des traces d’utilisation des différents services et

22 | P a g e
principalement les traces des diagnostiques récentes avec leurs résultats ainsi que les erreurs
récemment signalées
 Statistiques   ce service va être ajouté dans la version prochaine  
Ce service sera développé afin de permettre à l’utilisateur de l’application d’être informer
sur les changements dans une période bien déterminée au niveau du :
 Vitesse
 Distances parcourus
 Consommation du Carburant
 Température …….
 Tableau de bord (Dashboard) :
Une API qui sert à afficher des données représentatives en temps réel, on parle donc de
la visualisation d’un tableau de bord quasi-identique à celui du véhicule : en fait il va contenir
les items suivants :
 Kilométrage : distance parcourue.
 Vitesse : vitesse du véhicule.
 Température : température du véhicule.
 RPM : nombre de tours du moteur par minute.
 Fuel Levels : niveau de carburant.
L’utilisateur va être capable de consulter ces termes séparément avec plus de détails, donc
une interface isolée pour chaque item sélectionné avec une ergonomie simple et plus riche.
 Estimation et Géolocalisation (Estimation & GPS) :
Ce service se base sur la connexion Internet et utilise les APIs Google (Google Maps et
Géolocalisation) afin de :
 Localiser la voiture.
 Estimer le plus court chemin à partir des données relatives à la position actuelle

23 | P a g e
du véhicule et la destination désirée.
 Estimer la distance parcourue possible avec la quantité du carburant disponible
dans le réservoir.
 Estimer le temps de fonctionnement normal de la voiture avant que l’une des
composants doit être changée ou réparée.
2. Besoins non fonctionnels
Ce sont des exigences qui ne concernent pas spécifiquement le comportement du système
mais plutôt elles identifient des contraintes internes et externes du système.
Dans notre application les principaux besoins non fonctionnels se résument dans les
points suivants :
 Sécurité d’accès aux données :
Notre application doit assurer le maximum de sécurité à travers l’identification de ses
utilisateurs ce qui nécessite la réalisation des opérations suivantes :
 Besoins d’établissement de la connexion WIFI/ USB avec l’elm 327 pour les
appareils IOS– niveaux d’accès « Create and Read »
 Besoins d’établissement de la connexion Bluetooth avec l’elm 327(pour les
appareils Android et Microsoft) – niveaux d’accès « Create and Read »
 Chiffrement md5 des mots de passes
 Connexion avec Serveur : Déconnexion après temps morts d’inactivité –
durées.
 Connexion avec Serveur : Besoins de mot de passe – longueur, caractères
spéciaux, expiration, politique de réutilisation
 Performance :
 Temps de réponse : le chargement de l’application, ouverture d’écrans et des
délais de rafraîchissement doivent être rapides le plus possible.
 En temps de traitement : la synchronisation des données entre serveur et
application va s’exécute ne arrière-plan avec un temps d’exécution réduit
dépendant du débit de connexion internet utilisée.

24 | P a g e
 L’interrogation de données : l’application doit assurer temps de chargement
initial et des chargements sur demande des données récupères de l’appareil
elm 327 via Bluetooth en courts délais.
 Capacité :
L’utilisateur ne doit pas être inquiet du volume des données stockées, il ne veut pas voir
des notifications de style « pas assez de mémoire » ce qui nous rend très prudent concernant
les deux termes suivants :
 Quel est le nombre et le volume de transactions que le système est capable de
traiter ?
On parle de la synchronisation des données, l’analyse et le traitement des données
interrogées, les commandes passées par Bluetooth, le flux des données entre interfaces.
 Combien de données le système doit-il être capable de stocker ?
 Intégrité :
L’application doit bien répondre à ce besoin à travers :
 La capture des erreurs d’entrée-sortie – comment traiter les échecs d’interface
électroniques, etc.
 Le traitement des mauvaises données – import de données, marquer-et-continuer
ou arrêt la politique d’importation, etc.
 Intégrité des données – intégrité référentielle dans tables de base de données et
interfaces
 Compatibilité :
Pour garantir que notre application couvre une partie importante du marché on va
répondre à ces questions :
 La compatibilité avec des applications partagées – À quels autres systèmes doit-
il parler ?
 La compatibilité sur des systèmes d’exploitation différents – sur lesquels doit-il
être capable de fonctionner ?
 La compatibilité sur des plateformes différentes : Sur quelles plateformes

25 | P a g e
matérielles doit-il marcher ?
 Ergonomie :
Car Self Care doit être facile à utiliser. En effet les interfaces utilisateurs doivent être
conviviales, simples, ergonomiques, adaptées à l’utilisateur et bien structurées du point de
vue contenu informationnel. Pour ce fait la future application va prendre en considération :
 Les standards d’ergonomie – la densité d’éléments sur les écrans, la
disposition, les couleurs, l’Interface Utilisateur.
 Internationalisation / besoins de localisation – langages, orthographe.
 Disponibilité :
Ce besoin est très important en fait il peut qualifier l’application entière. Les services
offerts par la solution finale doivent être toujours disponibles dans tous les conditions. Donc
si l’utilisateur cherche le service « X » l’application doit être prête à répondre à son besoin.
III. Diagramme de cas d’utilisation générale
Pour une vue générale sur les différents modules qui vont être traités dans notre
application. On a eu recours au digramme de cas d’utilisation général représenté dans la
figure suivante.
Figure 3:Diagramme de cas d'utilisation général
.Utilisateur
Gerer profile
gérer centre de noftifications
consulter tableau de bord
Lancer diagnostic
gérer estimation
gérer préérences

26 | P a g e
Conclusion
Durant ce deuxième chapitre, nous avons pu aller un peu au fond du système en
définissant ses besoins et ses acteurs qui nous ont guidés vers la modélisation du
diagramme de cas d’utilisation général autrement dit il est maintenant possible
d’entamer la conception.

27 | P a g e
Chapitre III

28 | P a g e
Introduction
La phase de conception est un processus créatif qui constitue l’étape la plus
importante dans le cycle de développement logiciel.
L’étude conceptuelle sert à définir le contour du système à modéliser, à capturer les
fonctionnalités principales du système afin d’assurer une meilleure compréhension et
aboutir à plusieurs solutions en vue de fournir une base à la planification de projet.
I. Raffinement de cas d’utilisation
Nous allons maintenant rependre les cas d’utilisations identifiés dans le diagramme de
cas d’utilisation général et les raffinés en s’appuyant encore une fois sur les diagrammes de
cas d’utilisation UML
1. Gérer Profile
Figure 4:Diagramme de cas d'utilisation « gérer profile »
<<include>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
utilisateur
gerer connexion
consulter profile
consulter profile utilisateur
consulter profile voiture
s'authentifier
s'inscrire

29 | P a g e
1.1S’authentifier
 Scénario du cas d’utilisation « s’authentifier »
Titre : S’authentifier
Acteur : Utilisateur
Résumé : C’est une tâche très importante pour la sécurité de l’application qui permet d’accéder à
certains privilèges.
Description du scénario principal
Pré condition : Utilisateur est inscrit.
Utilisateur pas encore authentifié
Action de
départ :
Redirection du panel Connexion à authentification.
Scénario
nominal
Utilisateur Système
1-L’utilisateur introduit son login et son
mot de passe
2-Opération de vérification des entrées
utilisateur par le système
3-Le serveur recherche dans la BD le profil
correspond aux données tapées
3-Le serveur attribue une session à l’utilisateur
lui permettant d’accéder aux fonctionnalités
désirées
Post-Condition : Utilisateur en connexion avec le système et possibilité d’accéder aux fonctionnalités qui lui
concernant.
Enchainements
alternatifs
E1 : champs vides
E2 : règles de saisie non respectées
E3 : Login ou mot de passe inexistant dans
la BD
E1 : Le système affiche un message mentionnant
la présence d’un (des) champ(s) vide(s).
E2 : le système affiche un message mentionnant
la règle non respectée
E3 : le système affiche un message « login ou
mot de passe incorrect »
Action finale : Redirection vers la page suivante
Tableau 1: Description du cas d'utilisation « s'authentifier »

30 | P a g e
 Diagramme de séquence « S’authentifier »
Figure 5:Diagramme de séquences « s'authentifier »
Description Textuelle :
L’interface d’authentification sécurise notre application. L’utilisateur tape son login
et son mot de passe qui seront chiffrés et envoyés au serveur. Ce dernier vérifie tout d’abord
si le login figure dans la BD si tout va bien il s’occupe de la vérification de mot de passe une
fois la vérification n’aboutit pas à une détection d’erreurs une session est attribut à
l’utilisateur et il sera dirigé vers la page d’accueil si non un message d’erreur va s’afficher
signalant l’échec de l’authentification.
diagramme de sequences s'authentifier
6:R=reponse
5:requete select
9:profilutilisateur affcihé
8:indique le succés de connexion
9:message d'echec de connexion affiché
8:indique l'echec de la connexion
7:traitement de R
4:passer demande de connexion
3:message d'erreur de saisie affcihé
2:controle de saisie
1:taper 'username' et 'password' et conencter
I_Connexion C__ Serveurutilisateur. User
Saisie Incorrecte
Saisie Corercte
alt
Authentification réussite
Authentification echouée
alt
6:R=reponse
5:requete select
9:profilutilisateur affcihé
8:indique le succés de connexion
9:message d'echec de connexion affiché
8:indique l'echec de la connexion
7:traitement de R
4:passer demande de connexion
3:message d'erreur de saisie affcihé
2:controle de saisie
1:taper 'username' et 'password' et conencter

31 | P a g e
1.2S’inscrire
 Scénario du cas d’utilisation « s’inscrire »
Titre : S’inscrire
Résumé : Interface permet l’ajout de nouveaux profils utilisateurs.
Pré condition : Utilisateur pas encore inscrit
Action de départ : Redirection du panel Connexion vers inscription.
Scénario nominal
1. L’utilisateur remplit le
formulaire et appuyer sur
« registre »
2.Opération de vérification des -entrées
utilisateur par le système
3.Le serveur ajoute dans la BD le profil
correspond aux données tapées
4.Le système redirige l’utilisateur vers
la page d’authentification.
Post-Condition : Utilisateur est inscrit.
Enchainements alternatifs Utilisateur Système
E1 : champs vides
E2 : règles de saisie non
respectées
E1 : Le système affiche un message
mentionnant la présence d’un (des)
champ(s) vide(s)
E2 : le système affiche un message
mentionnant la règle non respectée.
Action finale : Redirection vers la page suivante
Tableau 2:Description du cas d'utilisation « s'inscrire »

32 | P a g e
 Diagramme de séquence « S’inscrire »
Figure 6: Diagramme de séquences « s'inscrire »
L’interface d’inscription est très importante dans notre application. Elle sert à
ajouter des nouveaux profils utilisateurs qui assurent la sécurisation de l’application.
L’utilisateur entre ses coordonnées qui seront chiffrés et envoyés au serveur qui vérifie tout
d’abord si les données tapées respectent bien les règles de saisie ; si oui une requête de type
« insert » sera envoyée au serveur de données afin d’ajouter le profil utilisateur dans la BD.
Une fois l’utilisateur est bien ajouté il sera redirigé vers la page d’authentification. Sinon un
message d’erreur va s’afficher signalant l’échec de l’inscription.
Diagramme Sequence s'inscrire
7: triatement de r
6: r=réponse
5: requete select
1: remplir le formulaire et taper "register"
2: controle de saisie3: message d'erreur de saisie affcihé
4: passer demande d'inscription
8: indique l'echec de l'inscription
9: message d'echec d'inscription affiché
8: indique le succés d'inscription
9: redirection vers la page d'authentification
I_Inscription C_Serveurutilisateur user
Saisie Incorrecte
Saisie Corercte
alt
Inscription réussite
Inscription echouée
alt 7: triatement de r
6: r=réponse
5: requete select
1: remplir le formulaire et taper "register"
2: controle de saisie3: message d'erreur de saisie affcihé
4: passer demande d'inscription
8: indique l'echec de l'inscription
9: message d'echec d'inscription affiché
8: indique le succés d'inscription
9: redirection vers la page d'authentification

33 | P a g e
1.3Consulter profile utilisateur
 Scénario du cas d’utilisation « consulter profile utilisateur »
Titre : Consulter profil utilisateur
Résumé : Panel contient les coordonnées de l’utilisateur de l’application
Pré condition : Utilisateur est connecté
Profil pas encore affiché
Action de départ : Redirection du panel d’authentification vers profile utilisateur
Scénario nominal
1. L’utilisateur demande la
consultation de son profil
2. Opération de vérification de
connexion
3. Opération du chargement du profil
par le serveur
4. Le profile utilisateur est affiché.
Post-Condition : L’utilisateur consulte son profil.
E1 : pas de connexion avec le
serveur
E2 : utilisateur pas encore
connecté
signalant un problème de connexion
E2 : le système redirige l’utilisateur
vers le panel de connexion.
Action finale : Profil utilisateur consulté
Tableau 3:Description du cas d'utilisation « consulter profile utilisateur »

34 | P a g e
 Diagramme de séquence « consulter profile utilisateur »
Figure 7:Diagramme de séquences « consulter profile utilisateur »
L’utilisateur peut consulter son profil mais il doit tout d’abord être connecté sinon
il va être redirigé vers la page de connexion avant de pouvoir consulter son profil.
1.4Consulter profile voiture
diagramme de séquence consulter profil voiture
5: R=reponse
4: requete select
1: clique sur l'icone "user"
2: verification du connexion
3: rediriger vers la page de connexion
3: demande de chargement de profil
6: traitement du demande
7: chargement du profil
7: indique l'erreur lors du traitement
8: profil utilisateur affcihé
8: un message d'erreur affcihé
Utilisateur IHM_USER C_.Serveur User.
Utilisateur est connecté
Utilisateur est non connecté
alt
succes du chargemenet de profil
echec du chargement du profil
alt
5: R=reponse
4: requete select
1: clique sur l'icone "user"

35 | P a g e
 Scénario du cas d’utilisation « consulter profile voiture »
Titre : Consulter profil voiture
Résumé : Panel contient les coordonnées des voitures de l’utilisateur
Pré condition : Utilisateur est connecté
Profil pas encore affiché
Action de départ : Redirection du panel d’authentification vers profile voiture
Scénario nominal
1. L’utilisateur demande la
consultation de profil de ses
voitures
2. Opération de vérification de
connexion
3. Opération du chargement du profil
par le serveur
4. Le profile voiture est affiché.
Post-Condition : L’utilisateur consulte son profil de voitures.
E1 : pas de connexion avec le
serveur
E2 : utilisateur pas encore
connecté
signalant un problème de connexion
E2 : le système redirige l’utilisateur
vers le panel de connexion.
Action finale : Profile voitures consulté
Tableau 4:Description du cas d'utilisation « consulter profile voiture »

36 | P a g e
 Diagramme de séquence « consulter profile voiture »
Figure 8:Diagramme de séquences « consulter profile voiture »
L’utilisateur peut consulter la liste de voitures enregistrées mais il doit tout d’abord être
connecté sinon il va être redirigé vers la page de connexion avant de pouvoir consulter la
liste de ses voitures.
2. Diagnostic
diagramme de séquence consulter profil voiture
5: R=reponse
4: requete select
1: clique sur l'icone "car"
Utilisateur IHM_Voiture C_.Serveur Voiture
Utilisateur est connecté
Utilisateur est non connecté
alt
succes du chargemenet de profil
echec du chargement du profil
alt
5: R=reponse
4: requete select
1: clique sur l'icone "car"

37 | P a g e
2.1 Lancer diagnostic
Figure 9:Diagramme de cas d'utilisation « lancer diagnostic »
<<extends>>
<<extends>>
lancer diagnostic rapide
lancer diagnostic complet
lancer diagnostic
Utilisateur

38 | P a g e
 Scénario du cas d’utilisation « lancer diagnostic »
Titre : Lancer diagnostic
Acteur : Utilisateur, ELM 327
Résumé : La fonctionnalité principale de l’application informe l’utilisateur sur l’état
de sa voiture.
Pré condition : Diagnostic pas encore lancé
Action de départ : Choix de type de diagnostic après consultation du panel
Scénario nominal
1. L’utilisateur choisit le type
de diagnostic
2.L’utilisateur lance le
diagnostic
3. Le système interroge l’ELM
4. Le système récupère les données.
5. Le système analyse les données
6. Le résultat de diagnostic affiché
Post-Condition : L’utilisateur consulte le résultat de diagnostic.
E1 : pas de connexion avec
l’ELM 327
signalant un problème de connexion avec
le microcontrôleur et lui redirige vers la
page de préférences.
Action finale : Diagnostic consulté
Tableau 5:Description de cas d'utilisation « lancer diagnostic »

39 | P a g e
 Diagramme de séquence « lancer diagnostic »
Figure 10:Diagramme de séquences « lancer diagnostic »
Une fois le Bluetooth du smartphone est activé et bien connecté avec le
microcontrôleur ELM 327, l’utilisateur va attendre quelques instants, après le choix de type
de diagnostic * et le lancement, pour consulter l’état de son véhicule via le résultat de
diagnostic choisit.
Types de diagnostic :
diagramme de sequence lancer diagnostic
10: resultat du diagnostic affiché
9: chargemnt des données
8: analyse des données
7: transmission data
6: interrogation
5: succes de connexion ELM
4: scan for elm & pairing
3: tentative d'activation BT
2: activation du bluetooth
1: choisir type de diagnostic et taper "start"
Utilisateur. I_Diagnostic
C_Bluetooth elm 327
10: resultat du diagnostic affiché
9: chargemnt des données
8: analyse des données
7: transmission data
6: interrogation
5: succes de connexion ELM
4: scan for elm & pairing
3: tentative d'activation BT
2: activation du bluetooth
1: choisir type de diagnostic et taper "start"

40 | P a g e
Diagnostic complet : l’utilisateur veut consulter l’état de tous les composants électriques
et mécaniques de sa voiture. Donc l’ELM 327 va être interrogé sur tous les données quelle
peut retenir à-propos de véhicule.
Diagnostic rapide : c’est un diagnostic semi-automatique concernant les composants
nécessaires au fonctionnement de voiture (Moteur, Carburant, Batterie).
2.2 Consulter logs
Figure 11:Diagramme de cas d'utilisation « consulter logs «
 Scénario du cas d’utilisation « consulter logs »
Titre : Consulter logs
Résumé : Afin de contrôler le fonctionnement du voiture l’utilisateur consulte l’historique de
diagnostic.
Pré condition : Logs pas encore affiché
Action de départ : Accès au Logs à partir du panel d’accueil
Scénario nominal
1. L’utilisateur consulte la page du log.
3. La liste des logs peut être consulté
par utilisateur.
2. Le système s’occupe de charger les logs
Post-Condition : L’utilisateur consulte l’historique de diagnostic.
Action finale : Logs consultés
Tableau 6:Description du cas d'utilisation « consulter logs »
Utilisateur ,
consulter logs

41 | P a g e
 Diagramme de séquence « consulter logs »
Figure 12:Diagramme de séquences « consulter logs »
La consultation d’historique des pannes autrement dit les logs de diagnostic est une
tâche très importante et facile à utiliser qui offre à l’utilisateur la possibilité de se souvenir
de l’état de sa voiture avec un simple clic sur l’icône de logs dans l’interface de menu
principal
3. Estimation & localisation
Figure 13:Diagramme de cas d'utilisation « estimation et localisation »
diagramme de sequence consulter logs
logs affichés chargement des donnees
3:R= requete select
ordre de chargement du logs
1:consulter interface
Utilisateur.. I_Logs BD_SQLITEcontroler Logs
logs affichés chargement des donnees
3:R= requete select
ordre de chargement du logs
1:consulter interface
_utilisateur
estimer ressources et chemin

42 | P a g e
 Scénario du cas d’utilisation « estimation & localisation »
Titre : Estimer ressources & localisation
Résumé : Cette fonctionnalité est une option offre à l’utilisateur de choisir le bon chemin pour
son parcours et estimer les ressources nécessaires.
Pré condition : Estimation pas encore prête.
Action de départ : Accès au panel estimation à partir du page d’accueil
Scénario nominal
1. L’utilisateur tape sa destination.
3. L’utilisateur consulte le plus court
Chemin possible pour son parcours.
5. L’utilisateur prend sa décision à
travers le résultat d’estimation
2. Le plus court chemin entre couple (départ,
destination) est tracé sur la carte.
4.A la base des données de temps réels
récupères du panel tableau de bord, le
système estime les ressources nécessaires
pour le parcours.
Post-Condition : L’utilisateur consulte l’estimation.
Enchainements
alternatifs
E1 : pas de connexion internet E1 : Le système affiche un message
mentionnant un problème de connexion
internet.
Action finale : Estimation prête et utilisateur peut prendre sa décision.
Tableau 7:Description du cas d'utilisation « estimation et localisation »

43 | P a g e
 Diagramme de séquence « estimation & localisation »
Figure 14:Diagramme de séquences « estimation et localisation »
L’estimation est un service qui nécessite une connexion internet afin de déterminer
le plus court chemin entre le point du départ et le point du destination désirés à l’aide des
services Google Map et GPS .De ce fait dès que l’utilisateur choisit le couple de points
(source et destination )le service de géolocalisation lui trace la trajectoire du plus court
chemin possible ,et à cet instant le système prend la main afin d’estimer les ressources
nécessaires pour parcourir la trajectoire en se basant sur les données récupérées du tableau
de bord donc le système ,une fois le traitement des données est terminé , indique à
l’utilisateur la faisabilité de quantité de carburant dans le réservoir par rapport à la quantité
nécessaire ,ainsi que les pannes qui peuvent apparaissent si l’utilisateur prend son chemin
diagramme de séquence estimation des ressources
affichage de resultat
analyse des données
données instantannées des ressources
demande des données realtives aux ressourcesplus court chemin tracé sur map
tracer trajectoire
traitement de demande
Connexion
etablie
appel de service web
choisir depart et destination
page d'estimation affichée
rediriger vers page d'estimation
verification de connexion internet
cliquer sur l'icone "estimater"
Utilisateur... I_accueil Google APII_Estimation c_dashbord
affichage de resultat
analyse des données
données instantannées des ressources
demande des données realtives aux ressourcesplus court chemin tracé sur map
tracer trajectoire
traitement de demande
appel de service web
choisir depart et destination
page d'estimation affichée
rediriger vers page d'estimation
verification de connexion internet
cliquer sur l'icone "estimater"

44 | P a g e
avec l’état actuelle du voiture. En fait le système va afficher à l’utilisateur toute une synthèse
sert à lui aider à la prise de décision.
4. Gérer Centre de Notifications
Figure 15:Diagramme de cas d'utilisation « gérer centre de notifications »
4.1 Gérer évènements de l’utilisateur
Figure 16:Diagramme de cas d'utilisation « gérer évènements utilisateur »
gerer les evenements utilisateurs
gerer le centre de notifications
consulter evenements systemes.
L'Utilisateur
<<extend>>
<<extend>>
<<extend>>utilisateur .
gerer les évènements utilisateurs
ajouter evenement
modifier evenement
supprimer evenement

45 | P a g e
 Scénario du cas d’utilisation « gérer évènements utilisateur »
Titre : Gérer évènements utilisateurs
Résumé : Ce panel permet à l’utilisateur de se rappeler des évènements que les gère.
Précondition : Evènements pas encore gérés.
Action de
départ :
Accès au panel centre de notifications à partir du page d’accueil
Scénario
nominal
1. L’utilisateur choisit le type « user évents »
3. L’utilisateur peut consulter, ajouter,
modifier ou supprimer un évènement.
2. Le système affiche les évènements
utilisateurs.
4. Sauvegarde après changements
effectués par utilisateur.
Post-Condition : L’utilisateur gère ses évènements.
Action finale : Gestion des événements utilisateur effectuée
Tableau 8:Description du cas d'utilisation gérer « évènements de l'utilisateur »

46 | P a g e
 Diagramme de séquence « gérer évènements utilisateur »
Figure 17:Diagramme de séquences « gérer évènements de l'utilisateur »
La gestion de évènements d’utilisateur lui permet de se rappeler des évènements relatifs
à sa voiture, de créer, modifier ou supprimer des évènements en consultant le panel « user
évents » où le système charge les informations relatives aux évènements créés par
l’utilisateur et les affiches sur écran, dès le moment du chargement des évènements
l’utilisateur peut gérer les événements voulus.
4.2Consulter évènements du système
Figure 18:Diagramme de cas d'utilisation « consulter évènement système »
Diagramme de séquences gérer evenements utilisateur
5: gerer evenement precis
4: evenements affcihés
3: chargement des evenments
2: demande de chargement d'evenements
1: choisr "usre events"
Utilisateur , I_Evenement BD_SQLLITE
5: gerer evenement precis
1: choisr "usre events"
Utilisateur ,
consulter evenements systemes

47 | P a g e
 Scénario du cas d’utilisation « consulter évènements du système »
Titre : Consulter évènements systèmes
Résumé : Ce panel permet à l’utilisateur de se rappeler des évènements génères
automatiquement par le système.
Pré condition : Evènements pas encore consultés
Action de départ : Accès au panel centre de notifications à partir du page d’accueil
Scénario nominal
1. L’utilisateur choisit le type
« system évents »
3. L’utilisateur peut consulter,
les évènements.
2. Le système affiche les évènements.
Créés automatiquement.
Post-Condition : L’utilisateur consulte ses évènements systèmes.
Action finale : Consultation des événements systèmes effectuée
Tableau 9:Description du cas d’utilisation « consulter évènements système »

48 | P a g e
 Diagramme de séquence « consulter évènements du système »
Figure 19:Diagramme de séquences « consulter évènements system »
La consultation des évènements crée par le système est accessible via le panel
« system events » où le système charge les informations relatives aux évènements
auto-générés et les affiches sur écran, dès le moment du chargement des évènements
l’utilisateur peut consulter les événements voulus.
5. Gérer préférences
Diagramme de séquences "consulter evenements systemes"
5: consulter evenement precis
1: choisr "system events"
Utilisateur , I_Evenement BD_SQLLITE
5: consulter evenement precis
1: choisr "system events"

49 | P a g e
Figure 20:Diagramme de cas d'utilisation « gérer préférences »
 Scénario du cas d’utilisation « gérer préférences »
Titre : Consulter préférences
Résumé : Ce panel est destiné au paramétrage de l’application tel que paramétrage BT,
Unit System, Data Connection,
Pré condition : Préférences non gérées.
Action de départ : Accès au panel de préférences à partir du page d’accueil
Scénario nominal
1. L’utilisateur choisit la(les)
préférence(s) à gérer
3.L’utilisateur gère la préférence
choisit
2.Le système sauvegarde les
changements effectués
Post-Condition : L’utilisateur paramètre l’application.
Enchainements
alternatifs
Action finale : Préférences gérées
Tableau 10:Description du cas d'utilisation « gérer préférences »
<<extends>>
<<extends>>
<<extend>>
<<extend>>
gérer Bluetooth
gérer systeme d'unité
gérer préférences
Utilisateur.
gérer connxion de données
gestion de language

50 | P a g e
 Diagramme de séquence « gérer préférences »
Figure 21:Diagramme de séquences « gérer préférences »
La gestion de préférences permet à l’utilisateur de paramétrer l’application en fait
il peut modifier les données de synchronisation wifi ou cellulaire ainsi que le paramétrage
du Bluetooth. Éventuellement l’utilisateur peut changer la langue de l’application comme il
peut changer les paramètres de système d’unités (vitesse, kilométrage, carburant).
Afin de gérer l’une ou tous les préférences de l’application l’utilisateur consulte la panel
préférences de l’interface Settings, à cet instant les variables dans la cache se chargent pour
rend le changement des préférences possible par l’utilisateur ensuite s’il y’a des
changements effectués ils seront sauvegardés dans la cache.
6. Consulter Tableau de Bord
diagramme de séquences gérer préférences
4: suvegarde des changements
3: changer préférences
2: chargement des valeurs de préférences
1: consulter panel Preferences
Utilisateur; I_Préférences BD_cache
4: suvegarde des changements
3: changer préférences
2: chargement des valeurs de préférences
1: consulter panel Preferences

51 | P a g e
Figure 22:Diagramme de cas d'utilisation « consulter tableau de bord »
 Scénario du cas d’utilisation « consulter tableau de bord »
Titre : Consulter tableau de bord
Résumé : Ce panel est conçu pour l’affichage des données de temps réel telles que
Vitesse, RPM, température.
Pré condition : Tableau de bord non prêt
Action de départ : Accès au panel du tableau de bord à partir du page d’accueil
Scénario nominal
1.L’utilisateur accède au
panel du tableau du bord.
3.L’utilisateur consulte le
tableau du bord
2. Le système charge les données de
temps réel à partir des données reçus de
l’elm 327
Post-Condition : L’utilisateur consulte le tableau du bord.
Action finale : Tableau du bord consulté.
Tableau 11:Description du cas d'utilisation « consulter tableau du bord »
Utilisateur ,
consulter tableau de bord

52 | P a g e
 Diagramme de séquence « consulter tableau de bord »
Figure 23:Diagramme de séquences « consulter tableau du bord »
L’utilisateur peut consulter en temps réel la vitesse, le nombre de tours par minute de
moteur, la température de son véhicule toute en consultant le panel du tableau de bord où le
système s’occupe de charger les données en interrogeant l’ELM 327 en temps réel.
Diagramme de séquence consulter tableau de bord
6: Tableu de bord affcihé
5: chargement des données
4: transmission des données
3: inetrrogation de l'elm
2: ordre de chargement de données
1: acceder au panel
utilisateur . I_Tableau de bord ELM 327C_Bluetooth .
6: Tableu de bord affcihé
5: chargement des données
4: transmission des données
3: inetrrogation de l'elm
2: ordre de chargement de données
1: acceder au panel

53 | P a g e
II. Diagramme de classe
Figure 24:Diagramme de classe
Conclusion
Durant ce chapitre, nous sommes arrivés à faire une étude conceptuelle qui décrit le
système à développer, ce qui rend la phase de réalisation possible maintenant.
0..*
gerer evenements
0..1
1..1
gerer profile
1..1
1..*
gerer logs
1..1
1..*
gérer voiture
1..1
user
-
-
-
-
id_user
username
password
email
: int
: String
: String
: String
+
+
+
s'authentifier ()
s'inscrire ()
afficher_profil ()
: void
: void
: void
diags_logs
-
-
-
-
-
-
id_log
id_user
id_voiture
titre_log
conetnu_log
date_log
: int
: int
: int
: String
: String
: Date
+
+
lancer_log ()
consulter_logs ()
: void
: void
voiture
-
-
-
-
-
id_voiture
id_user
immatricule
date_circulation
date_ajout
: int
: int
: int
: Date
: Date
+
+
ajouter_voiture ()
profile_voiture ()
: void
: void
evenement
-
-
-
-
-
-
-
-
id_evenement
id_voiture
titre_evenement
description_evenement
type_evenement
date_creation
date_alerte
id_user
: int
: int
: String
: String
: String
: Date
: Date
: int
+
+
+
+
ajouter_evenement ()
afficher_evenement ()
modifier_evenement ()
supprimer_evenement ()
: void
: void
: void
: void

54 | P a g e
Chapitre IV :

55 | P a g e
Introduction
La conception de l’application est finalement réalisée ce qui nous offre la possibilité
d’entamer dans ce chapitre la partie réalisation et implémentation dans laquelle on s’assure
que le système est prêt pour être exploité par les utilisateurs finaux.
On va commencer par présentation de l’environnement matériel et logiciel utilisé pour
développer notre application. Puis on va introduire l’architecture adoptée. Enfin, on va
présenter le travail accompli tout au long de la période du stage.
I. Etude Technique
Tout au long de ce projet nous avons eu recours à divers environnements de travail
matériels et logiciels ainsi que des différentes technologies que nous facilitent les taches.
1. Environnement de travail matériel
 Lors du développement de l’application, nous avons utilisés :
 Un ordinateur portable « Acer travail Mate P 253 »
 Système d’exploitation : Windows 10 Edition Professionnel 64
bits.
 Microprocesseur : Intel Core i3 @ 1.70 GHz.
 Mémoire vive : 4 Go.
 Disque dur : 500 Go.
 Un ordinateur portable « Samsung np350 v8 »
 Système d’exploitation : Windows 10 Edition Professionnel 64
bits.
 Microprocesseur : Intel Core i7 @ 1.70 GHz.
 Mémoire vive : 8 Go.
 Disque dur : 1 To.
 Un smartphone « HTC one m7 »
 Ram : 2 Go DDR2
 Plateforme Android : Android
 Plateforme Android : Android™ Lolipop avec HTC Sense™

56 | P a g e
HTC BlinkFeed™

 Vitesse du processeur : Qualcomm® Snapdragon™ 600, quad-core, 1,7 GHz

 Microcontrôleur « ELM 327 »
 L’ELM327 est un microcontrôleur programmé produit par ELM
Electronique pour traduire le diagnostic embarqué (OBD) l'interface dans la
plupart des voitures modernes. Le protocole de commande ELM327 est l'une
des normes la plus populaire PC-to-OBD interface et est également mis en
œuvre par d'autres fournisseurs.

 L’ELM327 original est mis en œuvre sur le microcontrôleur PIC18F2480 de
Micro chip Technology.

 ELM327 est l'un d'une famille de traducteurs OBD d'ELM Electronics.
D'autres variantes de mettre en œuvre un sous-ensemble des protocoles
OBD.
2. Environnement de travail logiciel
2.1 Logiciels utilisés

57 | P a g e
 Microsoft Office Word 2016
Figure 25:Logo « Microsoft Word »
Microsoft Word est un logiciel de traitement de texte publié par Microsoft. La version la
plus récente est Word 2016.
Un logiciel de traitement de texte couvre deux notions, assez différentes en pratique : un
éditeur de textes interactif et un compilateur pour un langage de mise en forme de textes
(notions qui sont précisées dans Traitement de texte).
 Sybase PowerAMC (15.1)
Figure 26:Logo « PowerAMC »
PowerAMC est un logiciel de conception créée par la société SDP, qui permet de
modéliser les traitements informatiques et leurs bases de données associées.
Il a été créé par SDP sous le nom AMC*Designer, racheté par Power soft qui lui-même
a été racheté par Sybase en 1995. Depuis 2010 Sybase appartient à l'éditeur allemand SAP.

58 | P a g e
 Intel XDK
Figure 27:Logo « Intel XDK »
L'Intel® XDK fournit un environnement de développement multiplateforme complet
pour la création d'applications HTML5 hybrides pour les appareils téléphoniques et tablettes
mobiles. Applications HTML5 ne sont pas limitées à des pages Web intelligentes affichées
dans un navigateur, vous pouvez également emballer votre code HTML5 et déployer
directement sur un appareil mobile comme une application mobile hybride installée
localement. Cela permet d'utiliser les mêmes canaux de distribution et de monétisation que
pour les applications mobiles natives, en plus de la même expérience d'installation de
l'application et le lancement.
 Intel App Preview
Figure 28:Logo « Intel App Preview »
Intel App Preview permet aux concepteurs et développeurs web et applications hybrides qui
utilisent le processeur Intel XDK de pré visualiser leurs applications sur des appareils réels.

59 | P a g e
 LAMP :
Figure 29:Logo « LAMP »
Lamp est un acronyme désignant un ensemble de logiciel permettant de construire notre
serveur :
 Linux
Figure 30:Logo « Debian »
Debian 8 : est un système d’exploitation, assure l'attribution des ressources aux autres
composants
 Apache
Figure 31:Logo « Apache »
Apache est un serveur http.il répond directement aux requêtes de clients web
 MySQL
Figure 32:Logo « MySQL »

60 | P a g e
MySQL Server est un " système de gestion de base de données relationnelle "
 PHP 5
Figure 33:Logo PHP 5
C’est un langage de script orienté objet, exécuté coté serveur.il permet la génération des
pages web dynamiques et la communication avec le serveur MySQL.
2.2 Technologies utilisées
 Html 5
Figure 34:Logo « HTML 5 »
HTML5 (Hypertext Markup Language 5) est la dernière révision majeure de html .
Le langage courant, HTML5 désigne souvent un ensemble de technologies Web
(HTML5, CSS3 et JavaScript) permettant notamment le développement d'applications.
 CSS 3

61 | P a g e
Figure 35:Logo CSS 3
Les feuilles de style en cascade, généralement appelées CSS de l'anglais CascadingStyle
Sheets, forment un langage informatique qui décrit la présentation des documents
HTML et XML.
 Cordova
Figure 36:Logo « Cordova »
Apache Cordova est un Framework de développement mobile open-source. Il permet
d'exploiter les technologies Web courantes telles que HTML5, CSS3 et JavaScript pour
développer des applications multiplateformes, évitant ainsi l'utilisation des langages natifs
propres aux différentes plates-formes mobiles. Les applications s'exécutent dans des
wrappers ciblés pour chaque plate-forme,
 JavaScript
Figure 37:Logo « JavaScript »
JavaScript est un langage de programmation de scripts principalement employé dans
les pages web interactives mais aussi pour les serveurs2. C’est un langage orienté
objet à prototype, c’est-à-dire que les bases du langage et ses principales interfaces sont
fournies par des objets qui ne sont pas des instances de classes, mais qui sont chacun équipés
de constructeurs permettant de créer leurs propriétés, et notamment une propriété de

62 | P a g e
prototypage qui permet d’en créer des objets héritiers personnalisés. En outre,
les fonctions sont des objets de première classe.
 JQuery
Figure 38:Logo jQuery
jQuery est une bibliothèque JavaScript libre et multiplateforme créée pour faciliter
l'écriture de scripts côté client dans le code HTML .
La bibliothèque contient notamment les fonctionnalités suivantes :
 Parcours et modification du DOM Événements ;
 Effets visuels et animations ;
 Manipulations des feuilles de style en cascade (ajout/suppression des classes,
d'attributs…) ;
 Ajax ;
 Plugins ;
 JSON
Figure 39:Logo « JSON »
JSON (JavaScript Object Notation) est un format de données textuelles dérivé de la
notation des objets du langage JavaScript. Il permet de représenter de l’information
structurée comme le permet XML par exemple.

63 | P a g e
Un document JSON ne comprend que deux types d'éléments structurels :
 Des ensembles de paires nom / valeur ;
 Des listes ordonnées de valeurs.
Ces mêmes éléments représentent trois types de données :
 Des objets ;
 Des tableaux ;
 des valeurs génériques de type tableau, objet, booléen, nombre, chaîne ou null.
 Ajax
Figure 40:Logo Ajax
L'architecture informatique Ajax (acronyme d'Asynchrones JavaScript and XML).
Ajax combine JavaScript, les CSS, JSON, XML, le DOM et le XMLHttpRequest afin
d'améliorer maniabilité et confort d'utilisation des applications internet riches :
 DOM et JavaScript permettent de modifier l'information présentée dans le
navigateur en respectant sa structure ;
 L’objet XMLHttpRequest sert au dialogue asynchrone avec le serveur Web ;
 XML structure les informations transmises entre serveur Web et navigateur.
Outre le XML, les échanges de données entre client et serveur peuvent utiliser d'autres
formats, tels que JSON.
II. Architecture de l’application

64 | P a g e
Model-Vue-Contrôleur(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.
MVC regroupe :
 Model
C’est un modèle de données comme indique son nom il gère les données de l’application
en fait il récupère les informations brutes de la base de données et les organisent afin d’être
traitées par le contrôleur par la suite.
 View
Cette partie de l’architecture concernant les interfaces graphiques créés en HTML5, CSS3
qui s’affichent à l’utilisateur.
 Controller
Le contrôleur s’occupe de la logique de code, il présente un intermédiaire entre le modèle
et la vue.
Figure 41:Architecture de l'application

65 | P a g e
III. Interfaces & Maquettes de l’application
3. Interface « Home »
Figure 42:Interface « Menu principal »

66 | P a g e
C’est l’interface principale de l’application via laquelle l’utilisateur peut accéder aux
différentes fonctionnalités avec un simple clic sur l’icône de service désiré.
4. Interface « Diagnostic »
« Diagnostic » est le premier service désiré par
l’utilisateur, en fait cette interface offre à l’utilisateur la
possibilité de lancer un diagnostic afin de consulter l’état
de son véhicule d’une manière simple et efficace avec une
ergonomie qui s’adapte à la perspective de l’utilisateur.
Figure 43:Interface « Diagnostic »

67 | P a g e
5. Interface « Notifications Center »
Avec ses deux panels ‘Notifications center ‘ permet à
l’utilisateur de se rappeler des évènements liés à sa voiture
et même de gérer les évènements.
Figure 44:Interface » Notifications Center »
6. Interface « Logs »
7. Interface « Estimation & GPS »
L’interface d’estimation permet l’estimation de plus cours
chemin pour un parcours choisi par l’utilisateur ainsi que
les ressources nécessaires.
Figure 45:Interface « Estimation »
8. Interface « Settings & Preferences »

68 | P a g e
L’interface de Settings regroupe 4 panels :
 User
Espace utilisateur lui permet de gérer son profile.
Figure 46:Interface » User »
 Car
Ce panel est réservé gérer la liste les voitures de
l’utilisateur.

69 | P a g e
Figure 47:Interface « Car »
 Help
Afin d’assurer une meilleure utilisation de l’application, le
panel d’Aide va guider l’utilisateur.
Figure 48:Interface « Help »
 Preferences :
Le paramétrage de l’application passe par la gestion du
contenu de ce panel, on parle de paramétrage de BT,
connexion de données,
Figure 49:Interface « Preferences »
9. Interface « Dashboard »

70 | P a g e
Cette interface représente un tableau de bord qui parait
comme celui de la voiture, il sert à afficher la vitesse de la
voiture, le nombre de tour de moteur par minute, la
température.
Figure 50:Interface » Dashboard »
Conclusion
Dans ce chapitre, nous avons réussi à préciser l’environnement matériel ainsi que
l’environnement logiciel de l’application. Comme nous avons décrit l’architecture adoptée,
nous avons représenté l’application finale à travers quelques interfaces graphiques.

71 | P a g e
Conclusion générale
Ceux qui ont des voitures ont toujours besoin d’être informés sur leurs états afin
d’assurer le bon fonctionnement et la performance à chaque utilisation.
Dans ce contexte, ce projet de fin d’études s’est déroulé au sein de la société Canadian
Software Technology afin de mettre en place une solution de « diagnostic automobile ». Ce
projet se résume en conception et réalisation d’une application mobile multiplateforme pour
le diagnostic des voitures en s’adaptant aux attentes et besoins clientèles.
Ce projet était une bonne occasion pour vivre la première expérience dans la vie
professionnelle. Il nous a apporté de nouvelles connaissances qui nous ont permis
d’approfondir les compétences que nous avons acquises tout au long de notre cursus
universitaire.

72 | P a g e
Sur le plan personnel, ce projet nous a permis de sentir le gout de travail en groupe
ainsi que renforcer notre créativité et notre détermination.
Grâce à son caractère extensible et sa modularité, notre système peut être enrichi
considérablement par l’intégration d’autres moules selon les besoins clientèles tels qu’un
module de gestion de paiement ou un service d’historique.
Bibliographie
 « UML 2- de l’apprentissage à la pratique » par Laurent AUDILBERT
 « Getting Started with the Intel. XDK. » par Intel XDK
Néographie
 http://www.w3schools.com/
 https://software.intel.com/en-us/intel-xdk
 https://www.linode.com/docs/websites/lamp/lamp-on-debian-8-jessie
 https://fr.wikipedia.org/
 https://github.com/
 http://qnimate.com/
 http://stackoverflow.com/
 http://jquerymobile.com/
 https://cordova.apache.org/
Glossaire

73 | P a g e
 CST : Canadian Software Technology
 CSS : Cascading Style Sheets
 HTML : HyperText Markup Language
 LAMP : Linux Apache MySQL PHP
 UML : Unified Modeling Language
 SGBD : Système de Gestion de Bases de Données
 SQL : Structured Query Language
 JSON : JavaScript Object Notation
 Ajax : Asynchrones JavaScript and XML
 MVC : Model-View-Controller
 GPS : Global Positioning System
 PHP : HyperText Préprocesseur

Rapportpfe

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Rapportpfe

Similar a Rapportpfe (20)

Último

Último (10)

Rapportpfe