Vous êtes sur la page 1sur 52

École Supérieur Européenne de Management

ESEM

Rapport de Stage
Conception et Réalisation d’une Application pour le Suivi des
Opération de Contrôles des Appareils Disconnecteurs.

Organisme d’Accueil : DCFC Réalisé par : LAFDAL Rafiq


Année Université 2017/2018
REMERCIEMENT
Avant tout, je tiens à remercier le bon Dieu tout puissant qui m’a
accordé santé et courage pour réaliser ce travail.
Je remercie mon encadreur Monsieur JACQUES LEONI pour
son assistance, disponibilité, orientations et conseils.
Je tiens également à remercier l’ensemble des membres du jury
qui me font l’honneur de juger ce travail.
Je remercie tout particulièrement tous les enseignants qui ont
contribué à notre formation.
Enfin, je remercie aussi tous mes amis et collègues qui m’ont
soutenu et tous ceux qui ont contribué de près ou de loin à la
réalisation de ce travail.
DÉDICACE
Je dédie ce modeste travail à ma famille respective et
particulièrement à mes parents pour leurs soutiens qu’ils m’ont
accordés tout au long de notre chemin.
TABLE DES MATIÈRES

Table des Matières


Table des Matières____________________________________________________________i
Liste des Figures_____________________________________________________________iii
Liste des Tableaux___________________________________________________________iv
Liste des Abréviations_________________________________________________________v
Introduction Générale_________________________________________________________1
Chapitre I : Organisme d’Accueil et Capture des Besoins_____________________________3
I.1. Introduction__________________________________________________________________3
I.2. Présentation de l’Organisme d’Accueil_____________________________________________3
I.2.1. Informations Générales______________________________________________________________3
I.2.2. Les principaux acteurs______________________________________________________________3
I.2.3. Compétences et réactivités__________________________________________________________4
I.2.4. Les secteurs d’interventions_________________________________________________________4
a – Étude technique – Audit – Ingénierie__________________________________________________4
b – Protection des réseaux d’eau potable__________________________________________________4
c – Les panneaux solaires______________________________________________________________5
d – Production ECS____________________________________________________________________5
e – Reprise de réseau enterré___________________________________________________________5
f – Assemblage et réparation de chaudière________________________________________________6
g – Lutte légionellose__________________________________________________________________7
h – Isolation – Calorifuge_______________________________________________________________7
i – Centrale traitement air VMC__________________________________________________________8
j – Désembuage des réseaux____________________________________________________________8
k – Recherche de fuite et réparation______________________________________________________8
l – Autres tâches_____________________________________________________________________8

I.3. Stage___________________________________________________________________9
I.4. Problématique________________________________________________________________9
I.5. Proposition d’une solution______________________________________________________10
I.6. Recueil des besoins___________________________________________________________10
I.5.1. Besoins fonctionnels_______________________________________________________________10
I.5.2. Besoins non-fonctionnels (ou techniques)______________________________________________11

I.6. Langage et Processus de développement__________________________________________11


I.8. Conclusion___________________________________________________________________11

Chapitre II : Analyse des Besoins_______________________________________________12


II.1. Introduction_________________________________________________________________12
II.2. Identification des acteurs______________________________________________________12

i
II.3. Diagramme de Contexte_______________________________________________________13
II.4. Cas d’utilisation______________________________________________________________15
II.4.1. Identification des cas d’utilisation____________________________________________________15
II.4.2. Description des cas d’utilisation______________________________________________________16
II.4.3. Diagramme des cas d’utilisation_____________________________________________________17
II.5. Diagramme de Séquence Système_____________________________________________________19

II.6. Conclusion__________________________________________________________________19

Chapitre III : Conception et Elaboration du Schéma Relationnel______________________20


III.1. Introduction________________________________________________________________20
III.2. Diagramme de séquence d’interaction___________________________________________20
III.2.1. Diagramme d’interaction pour le cas d’utilisation « S’authentifier »_________________________21

III.3. Diagramme de Classes du Domaines_____________________________________________22


III.3.1. Diagramme de classe______________________________________________________________22
III.3.2. Classes, attributs et responsabilités__________________________________________________23

III.4. Schéma relationnel___________________________________________________________26


III.5. Conclusion_________________________________________________________________27

Chapitre IV : Réalisation et Tests_______________________________________________28


IV.1. Introduction________________________________________________________________28
IV.2. Environnement de Programmation et Bibliothèques_______________________________28
IV.2.1. Sublime Text____________________________________________________________________28
IV.2.2. XAMPP_________________________________________________________________________28
IV.2.3. JavaScript_______________________________________________________________________28
IV.2.4. JQuery_________________________________________________________________________29
IV.2.4. AJAX___________________________________________________________________________29
IV.2.8. JQuery Mobile___________________________________________________________________29
IV.2.8. NodeJS_________________________________________________________________________29
IV.2.9. CORDOVA______________________________________________________________________29

IV.3. Schéma Physique de la Base de donnée__________________________________________29


IV.4. Architecture de l’Application___________________________________________________29
IV.4.1. Diagramme de Déploiement________________________________________________________31
IV.4.2. Structuration du Code Source_______________________________________________________31

IV.5. Captures d’écran____________________________________________________________33


IV.6. Conclusion_________________________________________________________________35

Conclusion Générale_________________________________________________________36
Bibliographie_______________________________________________________________37

ii
LISTE DES FIGURES

Liste des Figures


Figure I. 1 : Étude technique, audit et ingénierie........................................................................4
Figure I. 2 : Appareil de protection des réseaux d’eau potable..................................................4
Figure I. 3 : Les panneaux solaires.............................................................................................5
Figure I. 4....................................................................................................................................6
Figure I. 5....................................................................................................................................6
Figure I. 6 : Chaufferie................................................................................................................6
Figure I. 7....................................................................................................................................7
Figure I. 8 : Protection de tuyauterie..........................................................................................7
Figure I. 9 : Protection des tuyaux..............................................................................................7
Figure I. 10 : Cheminé................................................................................................................8
Figure I. 11..................................................................................................................................8
Figure I. 12 : Recherche de fuite.................................................................................................8

Figure II. 1 – Relation en les acteurs du système.....................................................................13


Figure II. 2 – Diagramme de Contexte.....................................................................................13
Figure II. 3 – Diagramme des cas d’utilisation.........................................................................18
Figure II. 4 – Diagramme de Séquence Système « S’authentifier ».........................................19

Figure III. 1 – Diagramme de séquence d’interaction « S’authentifier ».................................21


Figure III. 2 – Diagramme de classe du domaine de notre Application...................................24

Figure IV. 1 – Schéma physique de la base de données...........................................................30


Figure IV. 2 – Diagramme de Déploiement..............................................................................31
Figure IV. 3 – Structure de code source...................................................................................32
Figure IV. 4 – Formulaire d’Authentification...........................................................................33
Figure IV. 5 – La page d’accueil de l’administrateur...............................................................33
Figure IV. 6 – Le menu de l’administrateur.............................................................................34
Figure IV. 7 – Le formulaire de chantier / opérations de contrôle...........................................34

iii
LISTE DES TABLEAUX

Liste des Tableaux


Tableau II. 1 – Acteurs du Système..........................................................................................12
Tableau II. 2 – Messages entre acteurs et système...................................................................14
Tableau II. 3 – Les cas d’utilisation du système.......................................................................16
Tableau II. 4 – Description du cas « S’authentifier »...............................................................17

Tableau III. 1 – Les stéréotypes du Diagramme d’interaction « S’authentifier ».....................22


Tableau III. 2 – Description des classes et leurs attributs.........................................................26

iv
LISTE DES ABRÉVIATIONS

Liste des Abréviations


AJAX Asynchronous JavaScript And XML
CSS Cascade Style Sheet
DCFC Distribution – Chaud – Froid – Calorifuge
DOM Document Object Model
HTML HyperText Markup Language
JQ JQuery
JQM JQuery Mobile
JS JavaScript
JSON JavaScript Object Notation
SD Sequence Diagram
SGBD Système de Gestion de Base de Données
TIC Technologies de l’Information et de Communication
UML Unified Modeling Language
XAMPP X (Cross – multiplatform) Apache MariaDB PHP Perl

v
Introduction
Générale
Introduction Générale

INTRODUCTION
GÉNÉRALE
Introduction Générale
Les nouvelles technologies d’information et de télécommunication (TIC) ont
grandement contribué aux progrès dans différents domaines. Dans ce contexte, nous
présenterons dans ce mémoire notre proposition pour informatiser la tâche de vérification de
différents chantiers au sein de l’organisme DCFC (Distribution – Chaud – Froid –
Calorifuge) dans le quelle nous avons effectué un stage afin de comprendre la problématique
de gestion des chantiers et les opérations de vérifications des d’appareils dits
« Disconnecteur » dans ces chantiers.

Pour mieux éclaircir et présenter notre travail, nous avons organisé notre mémoire en
quatre chapitres :

Le premier chapitre traite de la présentation de l’organisme d’accueil, dans lequel nous


présenterons l’historique, son domaine d’activité et la gestion des chantiers et des opérations
de contrôle et de vérification des installations d’appareil « Disconnecteur ». Par la suite, nous
avons proposé notre solution qui consiste en la conception et développement d’une
application hybride (mobile et desktop) pour la gestion des chantiers. Cette application doit
répondre à un certain nombre de besoins énumérés dans le recueil des besoins.

Par la suite, l’analyse des besoins fera l’objet de deuxième chapitre, dans lequel nous
présenterons les différents acteurs du système, leurs différents cas d’utilisation et les
diagrammes de séquence système.

En ce qui concerne le troisième chapitre, la conception du système sera détaillée et


élaborée en utilisant les diagrammes d’interaction ainsi que le diagramme de classe. Ce
dernier est converti au schéma relationnel en appliquant les règles de passage du diagramme
de classe vers le schéma logique de données.

En dernier lieu, le quatrième chapitre est consacré à la réalisation de l’application, en


présentant les différents outils techniques et les langages de programmation utilisés, le
diagramme de déploiement ainsi que quelques captures d’écran des interfaces de notre
application.

1
Introduction Générale

2
CHAPITRE I
ORGANISME D’ACCUEIL ET
CAPTURE DES BESOINS
Chapitre I Organisme d’Accueil et Capture des Besoins

CHAPITRE I
ORGANISME D’ACCUEIL ET CAPTURE DES BESOINS

Chapitre I : Organisme d’Accueil et Capture des Besoins


I.1. Introduction
Dans ce premier chapitre nous allons présenter l’organisme d’accueil, à savoir : DCFC,
son historique et son domaine d’activité. L’accent sera mis, par la suite, sur le de gestion des
différents contrôles effectué sur les chantiers. A base de ça, nous proposons une solution
informatique qui répond à un certain nombre de besoins fonctionnels et non-fonctionnels.

I.2. Présentation de l’Organisme d’Accueil


I.2.1. Informations Générales
La DCFC est créé en avril 2016 par Monsieur JACQUES LEONI – ingénieur des
mines, c’est une société par action simplifiée à associé unique qui s’exerce sur les secteurs
d’activités du commerce interentreprises de fournitures et équipements industriels divers.

La devise de cette société est de donner les meilleurs services sur l’utilisation
intelligente de l’énergie. La production de chauffage et d’eau chaude dans les immeubles n’a
cessé de prospérer, des évolutions faites au coup par coup afin de pouvoir optimiser les
investissements techniques. Et aussi d’adapter des solutions et astuces pour de réel retour sur
investissement qui doivent se traduire par des économies d'énergie, par l'impact écologique et
par la durabilité des moyens technique misent en œuvre.

I.2.2. Les principaux acteurs


Faire le tour des avantages et des inconvénients de l'immobilier concerné ou de
l'industrie en question afin de pouvoir adapter des fournitures idéales. Le génie climatique est
une matière longue à comprendre avec des approches à fortiori déroutantes mais misent
ensemble de manière judicieuse peuvent changer tout le modèle.

I.2.3. Compétences et réactivités


La DCFC totalisent un nombre très important d’intervention diverse dans le domaine
du génie climatique tel que l'étude, la conception, la mise en œuvre, l'exploitation et la
maintenance des systèmes permettant le contrôle des ambiances ou d’améliorer les conditions
d'une ambiance agréable pour les êtres vivants, dans des espaces clos constituant les lieux de
vie (bâtiments, habitations………)

3
Chapitre I Organisme d’Accueil et Capture des Besoins

I.2.4. Les secteurs d’interventions

a – Étude technique – Audit – Ingénierie


Élaborer les moyens humains, matériels et techniques.

Figure I. 1 : Étude technique, audit et ingénierie

b – Protection des réseaux d’eau potable

Figure I. 2 : Appareil de protection des réseaux d’eau potable

Vérifiez le bon fonctionnement des dispositifs de protection ainsi que l'installation en


général. Donner également nos avis techniques pour l’amélioration de vos installations.

c – Les panneaux solaires


Plusieurs solutions techniques existent sur le marché, chaque système apporte son lot
d'avantage et d’inconvénient en termes de coût, de performance et de retour sur
investissement. Guider chaque client vers le meilleur choix technique, le plus adapté à la
situation.

4
Chapitre I Organisme d’Accueil et Capture des Besoins

Figure I. 3 : Les panneaux solaires.

d – Production ECS
Les meilleurs types de productions ECS pour un coût énergétique faible. Et surtout
mettre fin aux problèmes de légionnelle et de biofilm par des apports techniques et de
contrôles.

e – Reprise de réseau enterré


Assurer une prestation complète pour la réparation des réseaux enterrés.
Cette prestation comprend le terrassement l'ouverture fermeture, la tuyauterie et le
calorifugeage.

Figure I. 4.

f – Assemblage et réparation de chaudière


Remplacer les éléments de chaudière fonte ou reprendre les soudures sur les chaudières
acier.

5
Chapitre I Organisme d’Accueil et Capture des Besoins

Figure I. 5 

Figure I. 6 : Chaufferie
g – Lutte légionellose

Réadaptation les installations d'Eau Chaude


Sanitaire pour supprimer toute poche résiduelle de
légionnelle et de biofilm.
Nous mettons en place les moyens humains et
techniques pour résoudre de manière définitive les

légionnelles.

Figure I. 7.

6
Chapitre I Organisme d’Accueil et Capture des Besoins

h – Isolation – Calorifuge
Nous réalisons tout type d'isolation thermique avec finition à la demande du client.

Figure I. 8 : Protection des tuyaux. Figure I. 9 : Protection de tuyauterie.

i – Centrale traitement air VMC


Dimensionnement et mise en place de centrale de
traitement.

Figure I. 10 : Cheminé.

j – Désembuage des réseaux


Pour améliorer le bon fonctionnement des installations, l’entreprise propose le
désembuage et de l'équilibrage des réseaux.

7
Chapitre I Organisme d’Accueil et Capture des Besoins

Figure I. 11.

k – Recherche de fuite et réparation


La recherche de fuite par les techniques
électro-acoustique avec suivant les cas
l'injection d'H2 et d'un détecteur H2. La
technique par fumigène sous pression. Le
traçage des réseaux, identifier, repérer, le
modéliser afin de réaliser des prestations
curatives et préventives.

l – Autres tâches
Figure I. 12 : Recherche de fuite.
 Contrôle de Disconnecteurs
 Remplacement des Radiateurs
 Rénovation de chaufferie
 Manutention et levage
 Maçonnerie locaux techniques
 Nettoyage des VMC et CTA
 Serrurerie pour locaux techniques
 Désamiantage
 Carrelage – peinture
 Flocage coupe-feux
 Récupération NRJ sur eau usée
 Peinture des sols et murs

I.3. Stage
Durant notre stage au niveau de l’entreprise DCFC, nous nous sommes focalisés sur  la
vérification et l’installation des disconnecteurs. Un disconnecteur est un élément de protection
pour lutter contre les possibles retours d'eau dans une maison au niveau de la tuyauterie
(d'arrosage, du circuit de chauffage, etc.).

Cette tâche de vérification et de réparation ou de remplacement des disconnecteurs


s’effectue sur des chantiers localisés par des adresses. Un chantier appartient à un propriétaire
et géré par un client de l’entreprise DCFC. Le vérificateur doit faire un diagnostique de
l’installation et remplis une fiche de contrôle. Cette fiche est un fichier PDF contenant des
formulaires. Une fois terminé, le vérificateur envoi ce PDF vers le gérant de l’entreprise pour
une dernière vérification, et l’envoi à son tours au client pour établir un devis de service.

8
Chapitre I Organisme d’Accueil et Capture des Besoins

I.4. Problématique
Lors du stage ci-dessus présenté, nous avons constaté que la gestion des opérations de
vérification et de réparation des disconnecteur était manuelle. Le gérant de l’entreprise crée,
sur une carte Google-Map, les différents chantiers sous forme de marqueurs, en important des
adresses à partir d’un fichier Excel, et pour gérer l’affectation des chantiers aux différents
clients, il doit créer plusieurs cartes, une carte par client. Par conséquent, cette façon de gérer
crée les problèmes suivant :

 Gestion de plusieurs cartes pour les chantiers d’un client.


 Recréer les cartes pour la prochaine année et récupération manuelle d’historique
de contrôles effectués pour un client.
 Le vérificateur n’accède pas aux données de la carte.

I.5. Proposition d’une solution


Pour remédier aux problèmes ci-dessus cités, nous avons proposé une solution qui
consiste à un système constitué des parties suivante :

 Serveur de Données qui contiendra une base de données contenant toutes les
informations nécessaires pour la gestion des vérifications des disconnecteurs.
 Serveur Web qui permet d’accéder à la base de données et d’implémenter les
traitements distants.
 Une application mobile qui répond aux besoins du client en termes de
fonctionnalités, d’ergonomie, de rapidité de traitement, etc.

I.6. Recueil des besoins


Dans cette section, nous présenterons les différents besoins que l’application doit
répondre. Nous avons deux types de besoins, besoins fonctionnels et besoins non-fonctionnels
(besoins techniques).

I.5.1. Besoins fonctionnels


En ce qui concerne les fonctionnalités du futur système, nous pouvons mettre l’accent
sur les points suivants :

 L’authentification : accès sécurisé par un identifiant et un mot de passe.


 La gestion des mallettes (ensemble d’outils utilisés pour l’opération de
vérification).
 La gestion des techniciens (utilisateurs de l’application) : pouvoir ajouter,
supprimer, modifier et consulter les utilisateurs.
 La gestion des propriétaires : pouvoir ajouter, supprimer, modifier et consulter
les propriétaires des chantiers.
 La gestion des clients : pouvoir ajouter, supprimer, modifier et consulter les
clients.

9
Chapitre I Organisme d’Accueil et Capture des Besoins

 La gestion des chantiers / contrôles : pouvoir ajouter, supprimer, modifier et


consulter les chantiers. Ajouter, modifier et supprimer une opération de contrôle
pour un chantier.
 Remplir le formulaire de contrôle et génération du fichier PDF.

I.5.2. Besoins non-fonctionnels (ou techniques)


L’application doit répondre aux besoins techniques suivants :

 Sécurité : Protéger l’accès à l’application par un identifiant et un mot de passe.


 L’interface de l’application doit être conviviale et facile à utiliser.
 Le temps de réponse de l’application doit être acceptable.

I.6. Langage et Processus de développement


En ce qui concerne le formalisme et l’enchaînement des étapes d‘analyse et de
conception que nous avons adopté, nous nous sommes basé sur le langage de modélisation
UML et une démarche décrite dans [01].

I.8. Conclusion
Dans ce premier chapitre nous avons présenté l’organisme d’accueil ainsi que le besoin
du client pour réaliser une application afin de gérer les différents chantiers de contrôle et de
vérification. Nous avons conclu ce chapitre par un recueil de besoins fonctionnels et non-
fonctionnels.

10
CHAPITRE II
ANALYSE DES BESOINS
Chapitre II Analyse des Besoins

CHAPITRE II
ANALYSE DES BESOINS

Chapitre II : Analyse des Besoins


II.1. Introduction
Dans la phase d’analyse des besoins, nous décrirons les interactions des différents
acteurs avec le système afin de réaliser les fonctionnalités attendues qui sont modélisé sous
forme de cas d’utilisation. Pour mener à bien cette phase, nous commençons par la
présentation des acteurs, la communication entre les acteurs et l’application, les cas
d’utilisation pour chaque acteur, la description des cas d’utilisation en utilisant les
diagrammes de séquences système.

II.2. Identification des acteurs


Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement avec le système étudié. Un acteur peut
consulter et /ou modifier directement l'état du système, en émettant et /ou en recevant des
messages susceptibles d’être porteur de données. En ce qui concerne notre système, nous
avons pu identifier les acteurs suivants :

Acteur Rôle
Permet de gérer les chantiers, les techniciens, et configurer les
Administrateur
paramètres du système.
Vérificateur des installations, il rempli le rapport de
Technicien
vérification
Tableau II. 1 – Acteurs du Système.
En plus de ces deux acteurs, nous ajouter l’acteur générique « Utilisateur » [02] qui
représente toute entité non encore identifié par le système. Ainsi pour cet acteur, la seule
fonctionnalité accessible est l’authentification. Le diagramme suivant illustre la relation entre
les trois acteurs :

12
Chapitre II Analyse des Besoins

Figure II. 1 – Relation en les acteurs du système.

II.3. Diagramme de Contexte


Dans ce qui suit, nous allons représenter l’interaction du futur système avec son
environnement extérieur. Plus précisément, cette interaction s’effectuera entre le système, qui
est considéré comme une boite noir, et les différents acteurs identifiés précédemment, en
identifiant les différents messages échangés entre chaque acteur et le système.

Figure II. 2 – Diagramme de Contexte.

Les différents messages sont explicités dans le tableau suivant :

13
Chapitre II Analyse des Besoins

Acteur Message Acteur -> Système Message Système -> Acteur


Utilisateur m1 L’authentification (identifiant et mot m2 Réponse du système (soit erreur soit
de passe) l’affichage de l’interface (carte Google-
Map avec les marqueurs des chantiers))

m3 Accès à la gestion des techniciens m4 Affichage de la liste des techniciens,


(Vérificateur). avec possibilité d’ajout, de suppression
et de modification.
m5 Accès à la gestion des propriétaires. m6 Affichage de la liste des propriétaires,
avec possibilité d’ajout, de suppression
et de modification.
m7 Accès à la gestion des clients. m8 La liste des clients avec possibilité
Administrateur

d’ajout, de suppression et de
modification.
m9 Sélection d’un chantier sur la carte m10 Affichage de formulaire pour édition du
Google-Map chantier et un deuxième formulaire pour
la création d’opération de contrôle.
m11 Accès à l‘importation des chantiers m12 Affichage d’une interface pour la
sur fichiers EXCEL sélection d’un fichier EXCEL (avec un
format bien défini.
m13 Accès à la situation global des m14 Affichage d’une grilles sur contenant
opérations de contrôles. les opérations de contrôles, avec
possibilité de modification.
m15 Sélection d’un chantier. m16 Affichage d’un menu contextuel associé
au chantier.

m17 Itinéraire vers le chantier par rapport m18 Dessiner l’itinéraire pour atteindre le
à la position actuelle. chantier.
Technicien

m19 Renseignement du Rapport de m20 Affichage de formulaire du rapport de


vérification de chantier et génération vérification de disconnecteur.
du document PDF.
m21 Appeler le représentant du client (le m22 Le système effectue l’appel
Technicien du Client). téléphonique pour le N° configuré pour
le client.

Tableau II. 2 – Messages entre acteurs et système.

II.4. Cas d’utilisation


D’après [02] (p. 62), pour un acteur particulier du système, un cas d’utilisation
représente une séquence d’actions qui seront réalisées par le système afin de répondre à un
besoin métier et produire un résultat observable et intéressant. Il permet de décrire ce que le
futur système doit faire, sans spécifier comment il le fera.

14
Chapitre II Analyse des Besoins

Une autre définition tirée de [01] (voir Chap.2, pt. 2.2.2 et § 1), Un cas d’utilisation est
une unité cohérente représentant une fonctionnalité visible de l’extérieur. Il réalise un service
de bout en bout, avec un déclanchement, un déroulement et une fin, pour l’acteur qui l’initie.
Un cas d’utilisation modélise un service rendu par le système, sans imposer le mode de
réalisation de ce service [01].

II.4.1. Identification des cas d’utilisation


Dans ce qui suit, nous allons énumérer les différents cas d’utilisation pour chaque acteur
du système. Pour mieux présenter ces cas d’utilisation, nous avons opté pour une structure
tabulaire (voir [02] page 65). Le tableau suivant présente les différents cas d’utilisation
identifié pour notre système :

Acteur Principal / Messages Emis / Reçus par les


Cas d’utilisation
Acteurs Secondaires acteurs
Emet : Information d’identification
et le mot de passe.
S’authentifier Utilisateur Reçoit : L’interface adéquate à
l’utilisateur.

Consulter Emet : Ajout, Modification,


Suppression et consultation des
Afficher la liste des Ajouter
Administrateur mallettes.
mallettes Modifier Reçoit : Confirmation d’ajout, de
Supprimer modification et de suppression.
Consulter Emet : Ajout, Modification,
Consulter la liste des Suppression et consultation des
Ajouter
Techniciens Administrateur Techniciens (Vérificateurs).
(Vérificateurs) Modifier Reçoit : Confirmation d’ajout, de
Supprimer modification et de suppression.

Consulter Emet : Ajout, Modification,


Suppression et consultation des
Consulter la liste des Ajouter propriétaires.
Administrateur
Propriétaires Modifier Reçoit : Confirmation d’ajout, de
modification et de suppression.
Supprimer
Consulter Emet : Ajout, Modification,
Suppression et consultation des
Consulter la liste des Ajouter
Administrateur clients.
Clients Modifier Reçoit : Confirmation d’ajout, de
Supprimer modification et de suppression.
Emet : Importation d’adresses
Importer
(ajout en vrac), Modification,
Gérer les Suppression et consultation des
Modifier Administrateur
Chantiers/Contrôles chantiers / contrôles.
Supprimer

15
Chapitre II Analyse des Besoins

Reçoit : Confirmation
Consulter d’importation, de modification et
de suppression.
Emet : Sélectionner le chantier sur
la carte.
Afficher l’itinéraire Technicien Reçoit : Affichage de l’itinéraire
sur la carte.

Emet : Sélection du chantier.


Choix de l’action : « Sur place ».
Elaborer le Rapport de contrôle Technicien
Reçoit : Affichage du formulaire
de Rapport de contrôle.
Tableau II. 3 – Les cas d’utilisation du système.

II.4.2. Description des cas d’utilisation


Chaque cas d’utilisation énuméré dans le tableau II.2 sera décrit, textuellement, en
suivant un formalisme présenté dans [02]. (p. 71). Dans ce rapport, nous allons faire
uniquement la description du cas « S’authentifier ».

Sommaire d’Identification
Titre S’authentifier
But Permet d’identifier l’utilisateur et de savoir son rôle dans l’application
(privilèges accordés à cet utilisateur).
Résumé L’utilisateur doit fournir un identifiant et un mot de passe puis valide le
formulaire d’authentification. Le système utilise l’identifiant et le mot de
passe pour vérifier si ces informations sont correctes. Dans le cas d’erreur,
le système affiche un message d’erreur et invite l’utilisateur et refaire
l’authentification, sinon (dans le cas de succès), le système affiche
l’interface adéquate pour l’utilisateur.
Acteurs Utilisateur
Date de Création 01/02/2018 Date de Mise à Jour 05/03/2018
Version 1.0.0 Responsable LAFDAL Rafiq
Description des enchaînements
Pré-conditions /
Scénario nominal Ce cas d’utilisation est déclenché lorsqu’un utilisateur veut accéder au
système.
Enchainement (a) – S’identifier par login et mot de passe
L’utilisateur fournit un identifiant (login) et un mot de passe secret, et
envoie les informations au système afin d’accéder à son espace de travail.
Le système effectue des vérifications.
- Si l’utilisateur a omis l’identification ou mot de passe alors il faut
exécuter [Exception 01 : champsVides].
- Si l’identifiant et/ou mot de passe ne sont pas correcte alors il faut
exécuter [Exception 02 : champsIncorrect].
Enchaînements /
Alternatifs
Exceptions
[Exception 01 : champsVides] :

16
Chapitre II Analyse des Besoins

Le système notifie une erreur à l’utilisateur lui indiquant qu’il a oublié un ou plusieurs champs à
saisir (identifiant ou mot de passe), et l’invite à compléter les champs manquants.
[Exception 02 : champsIncorrect] :
Le système indique à l’utilisateur qu’une erreur est détectée liée à son identifiant et/ou à son mot de
passe, il l’invite à re-saisir son identifiant et/ou son mot de passe.
Tableau II. 4 – Description du cas « S’authentifier ».

II.4.3. Diagramme des cas d’utilisation


Dans ce qui suit, et après avoir énuméré les différents cas d’utilisation ainsi que leur
description textuelle, nous schématisons tous les cas d’utilisation dans un seul diagramme,
connu sous le nom de Diagramme des cas d’utilisation, illustré dans la figure II.3.

17
Chapitre II Analyse des Besoins

S’authentifier

Utilisateur
<< include >> Ajouter << include >>
<< include >> Ajouter
<< extend >>
<< extend >>
Modifier
Consulter Liste Mallettes << extend >> Modifier
<< extend >> Consulter Liste Techniciens
<< extend >> Supprimer << extend >>
Supprimer
<< extend >>
Consulter << extend >>
Consulter

<< extend >> Ajouter

Consulter Liste Propriétaire << extend >> Modifier


Administrateur

<< extend >> Ajouter << extend >> Supprimer


<< extend >>
Modifier Consulter
Consulter Liste Client << extend >>

<< extend >> Supprimer


Gérer les chantiers/contrôles

<< extend >> Consulter

<< include >>


Afficher l’itinéraire
Elaborer le rapport de contrôle << include >>
Technicien

Figure II. 3 – Diagramme des cas d’utilisation.

18
Chapitre II Analyse des Besoins

II.5. Diagramme de Séquence Système

Un autre diagramme important dans la phase d’analyse des besoins et qui permet
d’ajouter des informations supplémentaires sur le cas d’utilisation en décrivant les interactions
entre acteur(s) et système, est le diagramme de séquence système. Pour chaque cas
d’utilisation, nous établirons un diagramme de séquence système dans lequel, l’acteur ou les
acteurs ainsi que le système sont représentés par une ligne de vie, et l’échange de messages
entre acteur(s) et système est représenté par des flèches de communication,

Dans la figure suivante, nous illustrons le digramme de séquence du cas d’utilisation


« S’authentifier » :

Figure II. 4 – Diagramme de Séquence Système « S’authentifier ».

II.6. Conclusion
Après la phase d’analyse des besoins, qui nous a permet de déterminer ce que le
système doit faire, nous allons entamer dans le chapitre suivant la phase de conception objet,
dans laquelle nous mettrons l’accent sur le diagramme de classe du domaine (objets métiers
qui représente les concepts du domaine et leurs relations structurelles) et le passage au modèle
relationnelle.

19
CHAPITRE III
CONCEPTION ET ELABORATION
DU SCHÉMA RELATIONNEL
Chapitre III Conception et Elaboration du Schéma Relationnel

CHAPITRE III
CONCEPTION ET ELABORATION DU SCHÉMA
RELATIONNEL

Chapitre III : Conception et Elaboration du Schéma Relationnel


III.1. Introduction
Dans ce chapitre, nous allons réaliser la conception objet de notre système pour
déterminer les objets métiers qui réalisent les différents cas d’utilisation décrit dans la chapitre
II. Ceci sera réalisé en utilisant les diagrammes de séquence d’interaction entre acteur(s) et
objets du système. Par la suite, nous élaborons le diagramme de classes de domaine et le
passage vers le modèle relationnel.

III.2. Diagramme de séquence d’interaction


Pour chaque diagramme de séquence système, nous établirons le diagramme de
séquence d’interaction, dans lequel le système est remplacé par les objets qui interviennent
pour réaliser le cas d’utilisation concerné. Pour ce type de diagramme, nous avons trois types
de classes (voir [02] page 171) :

 Classes d’interface (boundary) : des classes qui permettent l’interaction entre


l’application et ses utilisateurs. Pour chaque cas d’utilisation, il y a au moins une
classe d’interface. Ce type de classe est schématisé comme suit :

 Classes de Contrôle (Control) : Ce sont des classes qui contiennent les


traitements et la cinématique de l’application. Elles font la transition entre les
classes d’interface et les classes entité. Elles sont schématisées comme suit :

 Classes entité (entity) : Elles représentent les objets métiers, et ce sont très
souvent des entités persistantes, c'est-à-dire qui vont garder leurs informations
(données) après l’exécution d’un cas d’utilisation particulier. En général, elles

20
Chapitre III Conception et Elaboration du Schéma Relationnel

sont enregistrées dans une base de données. Leur schématisation se fait grâce à
ce stéréotype :

III.2.1. Diagramme d’interaction pour le cas d’utilisation « S’authentifier »


Le diagramme d’interaction du cas d’utilisation « S’authentifier » est élaboré comme
suit :

Figure III. 1 – Diagramme de séquence d’interaction « S’authentifier ».


Le tableau suivant résume les stéréotypes utilisés pour représenter les objets qui
interviennent pour réaliser le cas d’utilisation « S’authentifier » :

Stéréotype Signification
Objet interface pour le formulaire d’authentification. Ce dernier contient
deux champs de saisie, à savoir, l’identifiant (login) et le mot de passe,
qui permettent à l’utilisateur de renseigner son identifiant et son mot de
passe. En plus, il contient un bouton pour envoyer ces informations.
Objet contrôle qui permet de vérifier s’il y a un ou plusieurs champs
vides. Nous pouvons aussi vérifier dans ce contrôleur la forme des
champs, par exemple, le mot de passe doit avoir au moins 7 caractères
avec au moins deux caractères numériques, et l’identifiant doit avoir au
mois 5 caractères.

21
Chapitre III Conception et Elaboration du Schéma Relationnel

Deuxième objet contrôle qui permet de vérifier si les champs renseignés


par l’utilisateur sont correctes. Cette vérification s’effectue en utilisant
l’objet entité de la classe « Compte » (objet persistant qui enregistre les
comptes des utilisateurs du système).
Objet entité (objet métier) qui contient tous les comptes des utilisateurs
du système.
Objet interface qui représente la vue principale de l’utilisateur connecté.
Nous pouvons la considérer comme l’espace de travail de l’utilisateur.
Tous les autres cas d’utilisation seront accessibles à partir de cette
interface.
Tableau III. 1 – Les stéréotypes du Diagramme d’interaction « S’authentifier ».
Remarques

 Les diagrammes de séquence d’interaction nous guident dans la phase de codage


de l’application, et ceci à travers la séparation entre les parties du code
responsable des l’interface, des contrôles, des entités ainsi que l’accès au
données.
 Les différentes classes entités utilisées dans les diagrammes de séquences
d’interaction permettent d’établir le diagramme de classe du domaine (classes
des objets métiers).

III.3. Diagramme de Classes du Domaines


III.3.1. Diagramme de classe
Le diagramme de classe est généralement considéré comme le plus important dans un
développement orienté objet. Il représente l’architecture conceptuelle du système : il décrit les
classes que le système utilise, ainsi que leurs liens (héritage, agrégation, composition, …etc.)

La figure III.2. illustre le diagramme de classe de notre application. Nous nous


focalisons sur les classes entité (classes du domaine) qui représente les données de
l’application.

III.3.2. Classes, attributs et responsabilités


Dans ce qui suit, nous allons décrire les différentes classes schématisées dans la figure
III.2. Cette description sera présentée sous forme d’un tableau, comme suit :

Attributs
Classe Responsabilité
Designation Définition Type
Administrateur Classe qui enregistre id Identifiant Numérique
les informations de
l’administrateur.
Technicien Enregistre les id Identifiant Numérique
informations sur le numAttestationLicence N° Alphanumériqu
vérificateur. d’attestation e
Utilisateur Pour stocker les id Identifiant Numérique
données des nom Nom de Alphabétique

22
Chapitre III Conception et Elaboration du Schéma Relationnel

utilisateurs, l’utilisateur
spécialement login et le prénom Prénom de Alphabétique
mot de passe. l’utilisateur
login L’identifiant Alphanumériqu
d’accès e
motDePasse Mot de passe Chaine de
Caractères
icon Icon qui Binaire
représente
l’image de
l’utilisateur.
Mallette Les mallettes utilisées id Identifiant Numérique
lors des opérations de numMallette N° de la Alphanumériqu
vérification des mallette e
chantiers.
(La suite à la page 25)

23
Chapitre III Conception et Elaboration du Schéma Relationnel

Figure III. 2 – Diagramme de classe du domaine de notre Application.

24
Chapitre III Conception et Elaboration du Schéma Relationnel

Attributs
Classe Responsabilité
Designation Définition Type
Client Représente les clients id Identifiant Numérique
qui soumirent des designation Désignation Alphanumérique
chantiers à l’entreprise du client
pour être contrôlés. numTel N° du Alphanumérique
Téléphone
Propriétaire Les différents id Identifiant
propriétaires des nom Nom du Alphabétique
chantiers. propriétaire
adresse Adresse du Alphanumérique
propriétaire
type Type du Enuméré
propriétaire :
Particulier ou
Entreprise
Chantier Les chantiers à id Identifiant Numérique.
contrôler . numSite Numéro du Alphanumérique
site. .
adresse Adresse du Alphanumérique
chantier. .
latLng Latitude et Chaine de
longitude sur caractères
la carte.
type Type du Enuméré.
chantier :
Appartement,
Villa, Sous-
sol ou autre
autreType Si type est Chaine de
autre, il faut Caractère.
préciser le
type dans
cette attribut.
nbreDisco Nombre de Numérique.
disconnecteur
dans ce
chantier.
Contrôle Les opérations de id Identifiant. Numérique.
contrôle à réaliser sur nomTechClient Nom du Alphabétique.
les chantiers. technicien du
client.
numTelTechClient N° du Alphanumérique
Téléphone du .
technicien du
client.
endroitCle Description Chaine de
de l’endroit caractère.
de la clé du

25
Chapitre III Conception et Elaboration du Schéma Relationnel

chantier.
dateDebut Date de début Date
de l’opération
du contrôle.
dateFin Date de la fin Date
de l’opération
de contrôle.
fini Est-ce que le Booléen.
contrôle est
fini ou non ?
resultat Résultat de Chaine de
l’opération de caractère.
contrôle.
conditionAccès Conditions Chaine de
d’accès au caractères.
chantier.
prisePhoto Est-ce qu’il y Booléen.
eu des prises
de photos.
PDF Rapport de vérification id Identifiant. Numérique.
associé à une opération nomFichier Nom du Chaine de
de contrôle fichier. caractère.
Tableau III. 2 – Description des classes et leurs attributs.

III.4. Schéma relationnel


A partir d’un diagramme de classe, nous obtiendrons le schéma relationnel (modèle
logique de données), et ceci en appliquant les règles de passage suivantes :

Règle 01 : Chaque classe du diagramme de classe devient une relation.

Règle 02 : Association Unique-Multiple (1/0..1 - *), dans ce cas, nous ajouter une clé
étrangère dans la relation issue de la classe qui participe une seul fois dans l’association.

Règle 03 : Association Multiple-Multiple (* - *), l’association sera transformée à une


relation, dont la clé primaire est la concaténation des clés primaires des associations issues des
classes qui participent dans cette association.

Règle 04 : Héritage, ici, nous avons trois méthodes pour transformer l’héritage :

 la méthode ascendante : Supprimer les relations issues des sous-classes et faire


migrer tous les attributs dans la relation issue de la classe mère et ajouter un
nouveau attribut qui détermine le type d’une instance de cette relation ;
 la méthode descendante : Supprimer la relation issue de la superclasse et faire
migrer ses attributs vers les relations issues des sous-classes ;
 la méthode distincte : ne pas supprimer aucune relation, ni celle issue de la
superclasse, ni celles issues des sous-classes, et ajouter une clé étrangère dans

26
Chapitre III Conception et Elaboration du Schéma Relationnel

les relations issues des sous classes vers la clé primaire de la relation issue de la
superclasse.
Après l’application des règles ci-dessus citées, nous obtiendrons le schéma relationnel
suivant :

Utilisateur (id, nom, prenom, login, motDePasse, role, actif, icon)


Administrateur(id, #idUtilisateur)
Technicien (id, numAttestionLicence, adresse, #idUtilisateur)
Mallette (id, numMallette)
Proprietaire (id, nom, adresse, type, #idClient)
Client (id, designation, numTel)
PDF (id, nomFichier)
Chantier (id, numSite, adresse, latLng, type, autreType, nbreDisco, #idProprietaire,
#idClient)
Controle (id, nomTechClient, endroitCle, dateDebut, dateFin, fini, resultat,
observationVisuelle, observationTechnique, conditionAcces,
localisationLocal, prisePhoto, #idChantier, #idTechnicien,
#idMallette, #idPDF)

III.5. Conclusion
Ce chapitre nous a permet de répondre à la question suivante : comment le système
réalisera les différents cas d’utilisation ? à travers les différentes classes (interfaces, contrôle
et enttité), le diagramme de classe du domaine et le schéma relationnel.

27
CHAPITRE IV
RÉALISATION ET TESTS
Chapitre IV Réalisation et Tests

CHAPITRE IV
RÉALISATION ET TESTS

Chapitre IV : Réalisation et Tests


IV.1. Introduction
Ce présent chapitre sera dédié à la partie de réalisation notre application et la mise en
œuvre de l’ensemble des techniques pour atteindre cette objectif. Par la suite, nous allons
montrer quelques captures d’écran de notre application.

IV.2. Environnement de Programmation et Bibliothèques


Dans cette section, nous allons énumérer les différentes technologies qui sont utilisées
pour développer notre système.

IV.2.1. Sublime Text


Est un éditeur de texte multi-langage qui reconnait la coloration syntaxique des la
plupart des langages de programmation. Pour notre cas, nous l’avons utilisé pour coder en
HTML, CSS, JavaScript [04].

IV.2.2. XAMPP
XAMP est une plateforme pour le développement Web qui fonctionne sous Windows,
Linux et MacOs. Cette plateforme est utilisée pour créer des applications Web avec PHP et
gérer les bases de données avec le SGBD MariaDB. Cette dernière tache se fait en utilisant
l’application PHPMyAdmin [05].

IV.2.3. JavaScript
JavaScript est un langage de script incorporé dans les documents HTML et exécuté par
le navigateur (Google chrome, Firefox, …) [06].

IV.2.4. JQuery
JQuery est un framework Javascript libre qui simplifie la manipulation des objets DOM
d’une base Web et d’interagir avec le serveur en utilisant AJAX [07].

IV.2.4. AJAX
AJAX (Asynchronous Javascript And XML) est une technique qui permet de réaliser
des requêtes au serveur Web pour obtenir des données ou effectuer des opérations à distance,
et sous actualiser une partie de la page [08].

28
Chapitre IV Réalisation et Tests

IV.2.8. JQuery Mobile


Une plateforme qui se base sur le framework JQuery et fournie un ensemble de
composants graphique pour les plateformes mobiles [09].

IV.2.8. NodeJS
Node.js® est un environnement d’exécution JavaScript construit sur le moteur
JavaScript V8 de Chrome [10].

IV.2.9. CORDOVA
CORDOVA est un framework à base de NodeJS qui permet de construire des
applications mobiles multiplateforme à base des technologie Web (HTML, CSS et JavaScript
[11].

IV.3. Schéma Physique de la Base de donnée


La base de données a été implantée en utilisant l’application Web PhpMyAdmin (outil
intégré dans XAMP), ce dernier nous permet de schématiser les tables et leurs relations (clé
étrangère) comme indiqué à la figure IV.1.

Dans le schéma physique, nous indiquons les types des attributs de chaque table, les
clés primaires, les clés étrangères ainsi que les champs références

IV.4. Architecture de l’Application


Après avoir présenté la partie de données de notre application, nous allons expliquer
l’architecture de l’Application en termes de déploiement des modules qui la constituent sur les
différentes machines (Serveur, Ordinateur de travail et les téléphones intelligents
(Smartphones)). En plus de ça, nous présentons la structuration de notre code source (Partie
client et serveur).

29
Chapitre IV Réalisation et Tests

Figure IV. 1 – Schéma physique de la base de données.

30
Chapitre IV Réalisation et Tests

IV.4.1. Diagramme de Déploiement


La figure suivante illustre les composants de notre application leur exécution par les
différentes machines :

Application réalisée en utilisant langage PHP accessible à

Serveur MariaDB Machine Serveur

Base de données Serveur


Contrôle DISCO Contrôle DISCO (Application Web)

TCP Application réalisée en HTML, CSS e

Application réalisée en HTML, CSS et JavaScript.


HTTP/HTTPS HTTP/HTTPS

Téléphone (Smartphone) Ordinateur Personnel

Application Mobile Application Bureau

Figure IV. 2 – Diagramme de Déploiement.


Pour les deux applications (Bureau et mobile), elles sont implémentées en utilisant le
même code (avec de légères modifications et elles sont générées en utilisant CORDOVA.

IV.4.2. Structuration du Code Source


Dans cette partie, nous allons discuter de l’architecture de notre application en termes de
structure de code source. Ceci permet d’ajouter un éclaircissement sur le diagramme de
déploiement ci-dessus présenté.

Notre application est basée sur l’architecture Client/Serveur à trois niveaux. C’est
niveaux sont comme suit :

Niveau 1 – Serveur base de donnée, pour notre cas, nous avons utilisé MariaDB [12].

Niveau 2 – Serveur Web Apache version 2.4.

Niveau 3 – Téléphone intelligent (Smartphone) ou un Ordinateur portable.

31
Chapitre IV Réalisation et Tests

La figure suivante, présente sommairement la structuration de notre code source :

Machine Serveur
Serveur Web Apache
Serveur de donnée
MariaDB Objets Métiers Contrôleurs

Requêtes Résultats
DAO
Index.php

HTTP/HTTPS

Requêtes HTTP (GET / POST) traités par le contrôleur principal.


Les réponses sont en format JSON

Index.html

Fragments HTML CSS


JQM

JS
JQ /JQM

Application Client

Figure IV. 3 – Structure de code source.

IV.5. Captures d’écran


Dans cette section, quelques vues de l’interface Homme-Machine de notre application
seront illustrées et expliquées.

32
Chapitre IV Réalisation et Tests

Figure IV. 4 – Formulaire d’Authentification.


La figure ci-dessus montre la première interface qui sera affichée pour l’utilisation. Une
fois ce dernier s’authentifie, il sera redirigé vers une nouvelle interface :

Le bouton Le bouton
pour se pour afficher
déconnecte le menu.

Les chantiers

Le bouton pour
center la carte
sur les chantiers.

Figure IV. 5 – La page d’accueil de l’administrateur.

Le clic sur le bouton du Menu affichera ceci :

33
Chapitre IV Réalisation et Tests

Figure IV. 6 – Le menu de l’administrateur.


Le click sur un chantier permet d’afficher l’interface suivante :

Figure IV. 7 – Le formulaire de chantier / opérations de contrôle.

IV.6. Conclusion
Dans ce dernier chapitre, qui représente la phase final du processus de développement
logiciel, nous avons présenté les différents outils et langages informatiques utilisés pour

34
Chapitre IV Réalisation et Tests

développer notre application. Par la suite, nous avons montré la structure physique de notre
base de données, en montrant les tables et leurs interrelations. Par la suite, le diagramme de
déploiement a été présenté pour bien illustrer les différentes parties de notre application et
leur affectation à différentes machines (Serveur, ordinateur personnel et téléphone intelligent).

Nous avons clôturé ce chapitre par la présentation de quelques interfaces des


utilisateurs. En ce qui concerne la phase des tests, le travail est toujours en cours de
développements et attente d’une validation de la part de l’organisme d’accueil.

35
CONCLUSION
GÉNÉRALE
Chapitre IV Conclusion Générale

CONCLUSION
GÉNÉRALE
Conclusion Générale
Dans le monde des entreprises, le temps est un paramètre très fondamental, et utiliser
des technologies et des méthodes pour gagner du temps, et par conséquent gagner de l’argent,
est très important. Ceci nous a motivé à proposer une application hybride (mobile / bureau)
afin de permettre de gérer les opérations de contrôle des appareils, dites disconnecteurs, et
avoir des rapports de contrôle à temps réel.

Pour atteindre cet objectif, la première étape consiste à comprendre ce processus de


contrôle des ces appareils, pour cela, nous avons effectué un stage au sein de l’organisme
DCFC, qui s’est achevé par l’élaboration d’un recueil de besoins (cahier des charges).

Par la suite, nous avons entamé la phase d’analyse des besoins en élaborant les
différents diagrammes dédiés à ça : diagramme des cas d’utilisation et diagramme de
séquence système, et ceci dans l’objectif de bien spécifier ce que le système doit faire. Cette
étape est suivie par la conception Orienté objet du système qui abouti à un diagramme de
classes et le schéma logique des données.

Finalement, notre travail s’est concrétisé dans la phase de réalisation et validation par
des tests effectués dans l’organisme d’accueil.

36
BIBLIOGRAPHIE
Bibliographie

BIBLIOGRAPHIE
Bibliographie
[01] Laurant AUDIBERT. ‘UML 2 - De l'apprentissage à la pratique’. Site web. URL :
https://laurent-audibert.developpez.com/Cours-UML/?page=mise-en-oeuvre-uml.
Publié le 31 octobre 2006 - Mis à jour le 12 janvier 2009. Date de consultation :
05/04/2018.

[02] Roy GILLES. ‘UML2 en action, de l'analyse des besoins en action’. Presses de
l'Université de Québec, 2009, première édition.

[03] Scott W. Ambler. ‘The Elements of UML 2.0 Style’. Première publication en format
imprimable en 2005. ISBN-13 978-0-521-61678-2 et ISBN-10 0-521-61678-6

[04] Sublime HQ Pty Ltd, ‘Sublime Text - A sophisticated text editor for code, markup and
prose’. Site web. URL : https://www.sublimetext.com. Date de consultation :
20/04/2018.

[05] Kai 'Oswald' Seidler, Kay Vogelgesang, …, ‘XAMPP Apache + MariaDB + PHP +
Perl’. Page web. URL : https://www.apachefriends.org/index.html. Date de
consultation : Mai 2018.

[06] Pluralsight team, ‘JS JavaScript.com. Ready to try JavaScript ?’. Page Web. URL :
https://www.javascript.com. Date de consultation : Avril 2018.

[07] JS Foundation, ‘JQuery, write less do more’. Page Web. URL : https://jquery.com.
Date de consultation : Avril 2018.

[08] Mohamed CHINY ‘AJAX (Asynchronous Javascript And XML’. Page Web. URL :
http://www.chiny.me/ajax-c-est-quoi-10-1.php. Date de consultation : Avril 2018.

[09] JS Foundation, ‘JQuery Mobile. A Touch-Optimized Web Framework’. Page Web.


URL : https://jquerymobile.com. Date de consultation : Avril 2018.

[10] Node.js Foundation, ‘Node JS. A JavaScript runtime built on Chrome’s V8 Javascript
engine’. Page Web. URL : https://nodejs.org. Date de consultation : Avril 2018.

[11] The Apache Software Foundation, ‘Apache CORDOVATM, Mobile apps with HTML,
CSS & JS’. Page Web. URL : https://cordova.apache.org. Date de consultation : Avril
2018.

[12] MariaDB Foundation, ‘The MariaDB Foundation – Supporting continuity and open
collaboration in the MariaDB ecosystem’. Page Web. URL : https://mariadb.org. Date
de consultation : Avril 2018.

37
Bibliographie

38

Vous aimerez peut-être aussi