Le document est une dédicace et un remerciement qui souligne l'importance de la famille, des enseignants et des mentors dans la réalisation d'un projet académique lié à l'informatique. Il aborde le développement d'un framework pour Kinect v2 dans le cadre d'un projet de fin d'études, intégrant des éléments de conception, de planification et de méthodologie agile. Le document est structuré en plusieurs chapitres, détaillant les différentes phases de réalisation et d'évaluation du projet.

1. Dédicaces
Parce qu’elle était mon école, mon enseignante, ma conseillère,
mon soutien continuel …
Je dédie ce travail à ma plus chère du monde, à la femme dont je
suis fier d’être son fils
A ma mère Madame Krichen Fatma
Qu’elle trouve dans cette œuvre le fruit de ses sacrifices et le
témoignage de mon grand amour et de ma gratitude la plus sincère.
A toute ma famille qui n’a jamais cessé de m’encourager et de
procurer l’aide nécessaire pour réaliser ce projet.
Amine Magdich

2. Remerciement
D’abord, nous devons grâce à Dieu qui nous a comblées de
ses bienfaits et nous a données la force pour accomplir ce
travail.
J’adresse l’expression de ma très grande reconnaissance à
mon professeur encadrant
Monsieur Ahmed Kharrat
Pour la confiance qu’il m’a investie en acceptant
d’encadrer mes travaux, pour ses conseils judicieux et
pour l’attention qu’il a apporté à ma mémoire à divers
stades de son élaboration.
J’aurais également le plaisir de présenter mes chaleureux
remerciements au membre du jury ;
Monsieur Lotfi Chaari
Monsieur Tarek Zlitni
D’avoir bien voulu assister à la soutenance de mémoire et
d’accepter de juger mon travail. En outre, je remercie
Monsieur Amine Mzid
Directeur technique de la société « SiFast »
De m’avoir accepté en tant que stagiaire au sein de son
entreprise avec toute générosité. Mes sincères
remerciements s’adressent à mon encadreur,
Monsieur Khaled Masmoudi
Chef de projet Symphony.
Je leur exprime toute ma gratitude pour leurs entières
collaborations, leur disponibilité et leurs aides vitales
à ce projet. Je voudrais également remercier tous les
autres employés de « SiFast » pour la bonne humeur
générale qui régnait au sein de l’entreprise.
Par la même occasion, j’adresse mes remerciements à tous
mes enseignants pour leurs efforts qui ont guidé mes pas
et enrichi mes travaux tout au long de mes études
universitaires.
Enfin, mes remerciements vont à ma famille et à mes amis.

3. Avant-Propos
L’automatisation des systèmes d’information demeure au centre de l’activité
informatique. Soumises à des contraintes d’un marché de plus en plus ouvert et de
concurrence nationale et internationale rude, les entreprises des différents secteurs d’activité
industrielle et commerciale ont tendance à réviser les solutions informatiques qui facilitent
leurs systèmes pour plus d’efficacité et donner à chacun de ses clients l’impression d’unicité.
Cette étude entre dans le cadre de la préparation d’un projet de fin d’études pour l’obtention
du diplôme national d’ingénieur en Informatique: TECH. WEB & MULTIMEDIA au sein de
l’institut supérieur d’informatique et du multimédia de Sfax « ISIMS ».
Ce projet a un apport considérable à notre formation. Il nous a fourni l’occasion pour mettre
en œuvre nos connaissances dans le domaine de l’informatique et d’établir des contacts
avec le monde professionnel.
Ce sujet se rapporte à la conception et au développement d’un Framework pour Kinect v2
pour la société SiFast.
Amin

5. SOMMAIRE
Introduction générale .......................................................................................................................................1
Chapitre 1: ETUDE PREALABLE..............................................................................................................4
I. RECUEIL...................................................................................................................................................5
I.1. Présentation de l’organisation.....................................................................................................5
I.2. Mission ..............................................................................................................................................5
I.3. Organisation.....................................................................................................................................6
I.4. Vision.................................................................................................................................................7
II. Présentation de l’application.................................................................................................................7
II.1. CONCEPTS DE BASE ................................................................................................................8
II.2. Objectifs à atteindre.................................................................................................................... 10
II.3. Analyse de l’existant .................................................................................................................. 12
II.3.1. Etude de l’existant ............................................................................................................. 12
II.3.2. Critiques de l’existant....................................................................................................... 14
II.3.3. Appréciation ........................................................................................................................ 15
II.3.3.1. Champs de l’étude......................................................................................................... 15
III. Langage et méthodologie de conception ................................................................................... 19
III.1. Pourquoi Scrum............................................................................................................................ 20
IV. Conclusion.......................................................................................................................................... 22
Chapitre 2: Planification et architecture .................................................................................................. 23
I. Capture des besoins.............................................................................................................................. 24
I.1. Identification des acteurs........................................................................................................... 24
I.2. Les besoins fonctionnels............................................................................................................ 25
I.3. Les besoins non fonctionnels ................................................................................................... 26
II. Planning du traitement des cas d’utilisation.................................................................................. 27
II.1. Priorités........................................................................................................................................... 27
II.2. Risques............................................................................................................................................ 27
III. Pilotage du projet avec Scrum...................................................................................................... 28
III.1. Les outils Scrum .......................................................................................................................... 28
III.2. Équipe et rôles.............................................................................................................................. 28

6. III.3. Le backlog du produit ................................................................................................................ 29
III.4. Diagramme des cas d’utilisation global................................................................................ 33
III.5. Architecture................................................................................................................................... 34
III.6. Planification des sprints............................................................................................................. 36
V. Conclusion .............................................................................................................................................. 37
Chapitre 3: Release 1 : La réalisation d’une application de simulation ......................................... 38
I. Le premier sprint................................................................................................................................... 39
I.1. Spécification fonctionnelle ....................................................................................................... 40
I.1.1 Description du champ de l’étude ............................................................................................ 40
a) Description textuelle du cas d’utilisation « Uploader une image »............................... 41
b) Description textuelle du cas d’utilisation « Prendre une image » ................................. 42
c) Description textuelle du cas d’utilisation « Définir la vue »........................................... 43
d) Description textuelle du cas d’utilisation « Choisir les accessoires ».......................... 43
e) Description textuelle du cas d’utilisation « Ajuster la taille »........................................ 44
f) Description textuelle du cas d’utilisation « Changer Type de cadre »......................... 45
g) Description textuelle du cas d’utilisation « Personnaliser les éléments «Couleurs »
45
h) Description textuelle du cas d’utilisation « Choisir la forme »...................................... 45
i) Description textuelle du cas d’utilisation « Valider Commande »................................ 46
I.2. Diagrammes de séquences........................................................................................................ 47
I.3. Diagramme de classe.................................................................................................................. 56
I.3.1. Représentation des associations..................................................................................... 61
I.3.2. Représentation des classes............................................................................................... 63
I.3.3. Représentation des méthodes.......................................................................................... 67
I.3.4. Présentation du diagramme de classe........................................................................... 68
I.4. Transformation en modèle relationnel................................................................................... 70
I.5. Test .................................................................................................................................................. 78
I.5.1. Les tests unitaires............................................................................................................... 78
Chapitre 4: Release 2 : Réalisation d’un Framework Kinect ............................................................ 80
I. Le premier sprint................................................................................................................................... 81
I.1. Spécifications fonctionnelles.................................................................................................... 81
I.1.1. Diagramme des cas d’utilisation.................................................................................... 81
I.1.2. Description textuelle des cas d’utilisation .................................................................. 83

7. a) Description textuelle du cas d’utilisation « Déplacer le curseur» ............................83
b) Description textuelle du cas d’utilisation « engager» ..............................................83
I.2. Conception ...............................................................................................................84
I.2.1. Diagramme de séquence système ..................................................................... 84
I.2.2. Diagramme de séquence système ..................................................................... 85
1.2.3. Diagramme de classe ........................................................................................ 88
I.2.3.1. Représentation des méthodes ..........................................................................90
I.3. Test ........................................................................................................................... 95
I.3.1. Test unitaire ...................................................................................................... 95
II. Le deuxième sprint ...........................................................................................................95
II.1. Spécifications fonctionnelles ....................................................................................96
II.1.1. Diagramme des cas d’utilisation ......................................................................96
II.1.2. Description textuelle des cas d’utilisation ........................................................ 98
a) Description textuelle du cas d’utilisation « Redimensionner la porte» ...................98
b) Description textuelle du cas d’utilisation « Sélectionner et cliquer sur les éléments
interactifs» .............................................................................................................................................. 98
c) Description textuelle du cas d’utilisation « Tourner les objets».................................... 99
II.1.3. Diagramme de séquence détaillé.................................................................................100
III. Conclusion........................................................................................................................................104
Chapitre 5: La phase closure.....................................................................................................................105
I. Environnement de développement.................................................................................................106
I.1. Environnement matériel...........................................................................................................106
I.2. Environnement de test..............................................................................................................108
I.3. Environnement de production................................................................................................109
I.4. Environnement logiciel............................................................................................................110
I.5. Outils de développement de l’application..........................................................................113
I.6. Outils de conception .................................................................................................................117
I.7. Outils de traitement et de présentation................................................................................117
II. Mesure d’optimisation de niveau technique................................................................................118
III. Documentation................................................................................................................................125
IV. Les interfaces de l’application....................................................................................................125
V. Apports et Evaluation ........................................................................................................................136
V.1. Apports au niveau des connaissances technique :............................................................136

8. V.2. Apports au niveau de la conception et du développement :..........................................137
V.3. Apports au niveau social :.......................................................................................................137
V.4. Bilan quantitatif :.......................................................................................................................137
V.6. Evaluation....................................................................................................................................138
VI. Bilan quantitatif..........................................................................................................................138
VII. Conclusion........................................................................................................................................139
Conclusion et perspectives ........................................................................................................................140
Annexe A........................................................................................................................................................141
I. Présentation...........................................................................................................................................141
II. Les 4 valeurs du Manifeste Agile...................................................................................................142
III. Les 12 principes du Manifeste Agile........................................................................................142
Annexe B........................................................................................................................................................143
I. Dictionnaire apuré des données..................................................................................................143
Annexe C........................................................................................................................................................152
I. Règle 1 : transformation des entités/classes................................................................................152
II. Règle 2 : transformation des associations :..................................................................................152
II.1. Association un à plusieurs :....................................................................................................152
II.2. Les associations plusieurs à plusieurs :...............................................................................153
II.3. Association un à un : ................................................................................................................153
II.4. Transformation de l’héritage : ...............................................................................................154
II.5. Transformation de la composition : .....................................................................................154
Bibliographie.................................................................................................................................................155

9. Table des figures
Figure 1: Mode d’emploi du Kinect ...................................................................................... 2
Figure 2: Logo de SIFAST .................................................................................................... 5
Figure 3: Les secteurs d'activité du SiFast ............................................................................. 6
Figure 4: Organigramme de la société SiFast ........................................................................ 7
Figure 5: Schéma démonstratif des différents éléments d'une porte .................................... 9
Figure 6: Schéma général de nombre d’internautes dans le monde..................................... 13
Figure 7: Schéma simplifié de la méthode d’interaction actuel ........................................... 15
Figure 8: Schéma de la solution choisi ................................................................................ 18
Figure 9: Le processus Scrum .............................................................................................. 21
Figure 10: Diagramme de contexte statique ...................................................................... 25
Figure 11: Équipe Scrum ................................................................................................... 29
Figure 12: Diagramme des cas d’utilisation global ........................................................... 33
Figure 13: architecture Client/serveur ............................................................................... 34
Figure 14: Représentation de l’architecture 1 tiers ............................................................ 35
Figure 15: Représentation de l’architecture N tiers ........................................................... 36
Figure 16: Plan du release .................................................................................................. 37
Figure 17: Diagramme de cas d’utilisation Front Office ................................................... 40
Figure 18: Diagramme de séquence détaillé du cas d’utilisation « création de la
simulation » 48
Figure 19: Diagramme de séquence détaillé du cas d’utilisation « modification des
matériaux » 49
Figure 20: Diagramme de séquence détaillé du cas d’utilisation « modification des
formes » 50
Figure 21: Diagramme de séquence détaillé du cas d’utilisation « modification des
panneaux » 51
Figure 22: Diagramme de séquence détaillé du cas d’utilisation « modification des
couleurs » 52
Figure 23: Diagramme de séquence détaillé du cas d’utilisation « modification des
vitrages » 53
Figure 24: Diagramme de séquence détaillé du cas d’utilisation « changement d’image »
54
Figure 25: Diagramme de séquence détaillé du cas d’utilisation « changement des
accessoires » 55
Figure 26: Représentation des classes ............................................................................... 69

10. Figure 27: Représentation du Modelé relationnel .............................................................. 77
Figure 28: Exemple de capture d’écran de l’outil de test « Jenkins » ............................... 79
Figure 29: Diagramme des cas d'utilisation du premier sprint (release 2) ......................... 82
Figure 30: Diagramme de séquence système du cas d'utilisation "engager un utilisateur "
85
Figure 31: Diagramme de séquence détaillé du cas d'utilisation "engager avec l’utilisateur
" 86
Figure 32: Diagramme de séquence détaillé du cas d'utilisation "Déplacer le Curseur" ... 87
Figure 33: Diagramme de classe du premier sprint (release 2) ......................................... 94
Figure 34: Diagramme des cas d'utilisation du second sprint (release 2) .......................... 97
Figure 35: Diagramme de séquence détaillé du cas d'utilisation "Tourner les objets" .... 101
Figure 36: Diagramme de séquence détaillé du cas d'utilisation " Redimensionner la
porte" 102
Figure 37: Diagramme de séquence détaillé du cas d'utilisation " Sélectionner et cliquer
sur les éléments interactifs" .................................................................................................... 103
Figure 38: La composition du Kinect V2 ........................................................................ 107
Figure 39: Fonctionnement de Git ................................................................................... 110
Figure 40: Kinect v2 Configuration Verifier ................................................................... 111
Figure 41: Kinect Studio .................................................................................................. 111
Figure 42: Visual Gesture Builder ................................................................................... 112
Figure 43: Représentation du modèle MVC et les relations entre les trois parties ......... 118
Figure 44: Architecture Client/Serveur REST ................................................................. 121
Figure 45: Architecture Client/Serveur WebSocket ........................................................ 121
Figure 46: Architecture Client/Serveur Web Socket ....................................................... 123
Figure 47: Page d’accueil du notre site de simulation .................................................... 126
Figure 48: Message qui improuve l’état du Kinect ......................................................... 126
Figure 49: Le menu de simulation ................................................................................... 126
Figure 50: Les fonctionnalités de la maison .................................................................... 127
Figure 51: Les fonctionnalités de la catégorie« Forme » ................................................. 127
Figure 52: Les fonctionnalités de la catégorie « Matériaux » .......................................... 128
Figure 53: Les fonctionnalités de la catégorie « Panneaux »........................................... 129
Figure 54: Les fonctionnalités de la catégorie « Couleurs » ........................................ 129
Figure 55: Les fonctionnalités de la catégorie « Vitrages »............................................. 130
Figure 56: Les fonctionnalités de la catégorie « Accessoires » ....................................... 130

11. Figure 57: Les fonctionnalités de la catégorie « Inclinaisons » ...................................... 131
Figure 58: Vue d’intérieur ............................................................................................... 131
Figure 59: Conseil client en ligne .................................................................................... 132
Figure 60: Enregistrement de la simulation ..................................................................... 132
Figure 61: utilisateur est non engagé « Capture IR) ....................................................... 133
Figure 62: Engagement de l’utilisateur ........................................................................... 134
Figure 63: Redimensionnement perspective de l’utilisateur ............................................ 134
Figure 64: La sélection d’un objet ................................................................................... 135
Figure 65: Avancer la main pour cliquer ....................................................................... 135
Figure 66: Redimensionnement verticale ........................................................................ 135
Figure 67: Redimensionnement horizentale .................................................................... 136
Figure 68: Redimensionnement responsive ..................................................................... 136
Figure 69: Redimensionnement verticale ........................................................................ 136
Figure 70: Processus actuel de développement ............................................................... 141
Figure 71: Processus Agile .............................................................................................. 141
Figure 72: Règle 1 du passage du modèle conceptuel vers le modèle logique ................ 152
Figure 73: Règle 2 du passage du modèle conceptuel vers le modèle logique ................ 153
Figure 74: Règle 3 du passage du modèle conceptuel vers le modèle logique (premier cas)
153
Figure 75: Règle 3 du passage du modèle conceptuel vers le modèle logique (deuxième
cas) 154
Figure 76: Règle 3 du passage du modèle conceptuel vers le modèle logique (troisième
cas) 154
Figure 77: Règle 3 du passage du modèle conceptuel vers le modèle logique (quatrième
cas) 154

12. Liste des tableaux
Tableau 1: Schéma démonstratif des différents éléments d'une porte ...................................... 9
Tableau 2: Tableau comparative entre les deux modes d’utilisations NUI et GUI .................. 11
Tableau 3: Table de critère entre les deux premières solutions ............................................... 17
Tableau 4: Table de critère entre les cinq solutions ................................................................. 17
Tableau 5: Tableau comparatif entre les différents Framework disponible ............................. 18
Tableau 6: Backlog produit ...................................................................................................... 31
Tableau 7: Backlog du premier sprint (release 1) .................................................................... 39
Tableau 8: Description textuelle du cas d'utilisation « Uploader une image » ........................ 41
Tableau 9: Description textuelle du cas d'utilisation « Prendre une image » ........................... 42
Tableau 10: Description textuelle du cas d'utilisation « définir la vue » ................................. 43
Tableau 11: Description textuelle du cas d'utilisation « Choisir les accessoires » .................. 43
Tableau 12: Description textuelle du cas d'utilisation « ajuster la taille » ............................... 44
Tableau 13: Description textuelle du cas d'utilisation « Changer Type de cadre » ................. 45
Tableau 14: Description textuelle du cas d'utilisation « Personnaliser les éléments «Couleurs
» ................................................................................................................................................ 45
Tableau 15: Description textuelle du cas d'utilisation « Choisir la forme » ............................ 46
Tableau 16: Description textuelle du cas d'utilisation « Valider Commande » ....................... 46
Tableau 17: Table liste des objets naturels ............................................................................... 56
Tableau 18: Table multiplicité des associations ....................................................................... 61
Tableau 19: Table de la représentation des associations .......................................................... 61
Tableau 22: Liste des tables du modèle relationnel ................................................................. 70
Tableau 23: Backlog du premier sprint (release 2) .................................................................. 81
Tableau 24: Description textuelle du cas d'utilisation « Déplacer le curseur » ........................ 83
Tableau 25: Description textuelle du cas d'utilisation « engager » .......................................... 83
Tableau 26: Table liste des objets naturels ............................................................................... 88
Tableau 27: Table de la représentation des associations .......................................................... 90
Tableau 30: Backlog du second sprint (release 2) .................................................................... 95
Tableau 31: Description textuelle du cas d'utilisation « Redimensionner la porte» ............... 98
Tableau 32: Description textuelle du cas d'utilisation « Sélectionner et cliquer sur les éléments
interactifs» ................................................................................................................................ 99
Tableau 33: Description textuelle du cas d'utilisation « Tourner les objets » ......................... 99
Tableau 36: Table de comparaison entre le Web Socket et le REST [13] ............................. 122

13. Tableau 37: Table de la représentation du bilan quantitatif.............................................................138
Tableau 38: Table dictionnaire apuré des données pour le Release 1 Sprint 1..........................143
Tableau 39: Table dictionnaire apuré des données pour le Release 2 Sprint 1..........................148

14. Introduction générale
Introduction générale
Depuis quelques années, les consoles de jeux vidéo sortent des chambres des
adolescents pour venir s’installer dans les laboratoires de recherche, les centres
commerciaux ….
Dans le cadre de projet de fin d’étude à l’institut Supérieur d’Informatique et de
Multimédia de Sfax, nous allons effectuer un projet portant sur la conception de nouvelles
techniques d’interaction avec les mondes 3D (dispositifs de réalité virtuelle) en plus ce projet
vise à concevoir et à tester de nouvelles techniques d’interaction 3D avec les mondes virtuels
« hybrides1
» au sein d’une société de service comme SiFast2
.
Ces nouveaux outils qui permettent de jouer « sans fil » offrent aux joueurs une grande
liberté de mouvement. La dernière en date, la Kinect3
, commence à apparaître entre les murs
des maisons. C’est la première caméra en trois dimensions destinée au grand public. Grâce à
ses caméras couleur et infra-rouge, elle permet de restituer une image en trois dimensions du
corps humain, en l’intégrant dans un environnement virtuel. Le joueur commande la console
uniquement avec son propre corps. L’utilisation de cette « console sans manette » est tout
naturellement en train de dépasser le cercle des joueurs pour faire progressivement son entrée
dans d’autres domaines. Elle présente l’avantage, par rapport aux autres consoles, avec ses
caméras offrant une vision en profondeur et la reconnaissance du squelette par modélisation,
d’analyser le mouvement : angles, espace utilisé, vitesse de mouvement, vitesse angulaire.
Alors qu’à l’heure actuelle, les systèmes d’analyse du mouvement sont réservés aux
1
Composite
2
Une Entreprise de Services du Numérique
3 Il s’agit d’une caméra utilisant des techniques d’interaction développées par la société PrieSense, longtemps nommée par le nom de code
du projet, « Project Natal »
1

15. Introduction générale
laboratoires ou aux centres de rééducation, la Kinect pourrait permettre l’analyse de
mouvement à coût réduit.
Figure 1: Mode d’emploi du Kinect
D’une manière générale, les jeux vidéo ont aujourd’hui largement dépassé le simple
divertissement pour devenir un réel outil de développement et d’apprentissage. Les jeux sérieux
(« serious games »), ont commencé à se développer il y a une dizaine d’années, puisque se tenait
en 2004 le premier Sommet des jeux sérieux aux Etats-Unis auquel s’est succédé, en 2007, le
deuxième Sommet à Lyon. Nous les trouvons désormais des applications dans de nombreux
champs : défense, marketing, économie, gestion, éducation (jeux-géographiques),
humanitaire (Food Force, Darfurisdying)...
ce phénomène est intitulé la gamification (ou ludification) c’est le transfert des mécanismes
du jeu dans d’autres domaines, en particulier des sites web, des situations d'apprentissage, des
situations de travail ou des réseaux sociaux.
Dans ce contexte nous tenterons de créer une application Kinect qui permet la simulation des
objets virtuelle dans le monde réelle à travers des nouvelles techniques d’interaction IHM
4
(reconnaissance vocale, par geste …) cette application aura comme objectif d’offrir à ses
utilisateurs l’expérience de manipuler naturellement notre site web.
Nous aborderons donc dans notre mémoire les chapitres suivants :
4
Interaction Homme Machine
2

16. Introduction générale
Le premier chapitre sera consacré à l’étude préalable en évoquant le contexte de
l’application, l’analyse des besoins, le planning prévisionnel et en définissant les objectifs à
atteindre ainsi que les orientations en définissant le cycle de vie de notre projet qui est «
SCRUM ».
Le deuxième chapitre « planning et architecture » qui consiste en la première
phase dans le cycle Scrum. Dans ce chapitre nous dévoilons les principales exigences de
notre application et nous le clôturons par un planning de travail.
Le troisième chapitre « La réalisation d’une application de simulation » et le quatrième
chapitre «Réalisation d’un Framework Kinect» constituent le corps de notre rapport. Ces
deux chapitres seront consacrés pour le développement des deux releases de notre système en
respectant les principes fondamentaux de Scrum.
Le dernier chapitre « la phase de closure » détaille tous les outils utilisés pour la
conception et le développement de notre application ainsi que quelques captures écran de
la version finale de notre système.
Nous finirons par une conclusion générale qui récapitule tout le travail réalisé et
ouvre les perspectives futures de notre système.
3

17. CHAPITRE I : ETUDE PREALABLE
Chapitre 1:
ETUDE PREALABLE
Dans ce chapitre, nous nous intéressons à
définir le contexte de l’étude afin de
déterminer les besoins fonctionnels. Après
avoir analysé notre application de simulation,
nous avons pu déterminer les différentes
solutions proposées des services offerts par
cette application et étudier l’existant qui
regroupe les fonctionnalités de base que doit
offrir ce système.
Ainsi, dans le cadre de ce travail, nous
sommes chargés de réaliser une application de
simulation par un dispositif Kinect en
conservant les méthodologies traditionnelles
qui nous permet d’augmenter le nombre
d’internautes et offrir plusieurs types
d’interactivité à nos clients.
4

18. CHAPITRE I : ETUDE PREALABLE
I. RECUEIL
L’étape d’analyse de l’existant et la spécification des besoins est indispensable dans la
création d’une application informatique. Nous sommes censés d’étudier les travaux existants
et montrer leurs défaillances. Ensuite, nous fixons les objectifs à atteindre dans notre
application.
I.1. Présentation de l’organisation
: est une entreprise de services Numérique (ESN) créée en 2010 [1] par des
professionnels du service et de l’informatique, c’est un des leaders du nearshore Francophone,
délivre des services IT qui permettent à ses clients d’améliorer leur efficacité et leur
rentabilité. Grace à sa maîtrise des nouvelles technologies, son expérience de l’externalisation
et son approche collaborative, SiFast aide ses clients à développer des solutions innovantes
pour répondre à leurs enjeux axée sur les développements informatiques et l’infogérance
fondée sur les principes de la compétence, le respect et l’innovation focalisée sur la
satisfaction de nos clients.
Inspirés des différents standards du marché comme CMMi 5
et ISO 9001 6
et de
l’expérience du nearshore, SiFast définit son système qualité tout en conservant sa souplesse
et son agilité.
Figure 2: Logo de SIFAST
I.2. Mission
SiFast offre à ses clients, en véritable partenaire, un service de qualité et des solutions
innovantes, tout en respectant leurs contraintes et leurs spécificités. Elle leur permet
5
Livre CMMI par l'exemple écrit par François Dufay sorti en 2010
6
Livre Dix clés pour réussir sa certification ISO 9001 écrit par Claude Pinet sorti en 2009
5

19. CHAPITRE I : ETUDE PREALABLE
d’optimiser leur sourcing en leur garantissant un rapport qualité / prix très compétitif et
une flexibilité maximale.
I.3. Organisation
Afin de réaliser sa mission parfaitement, SiFast a bâti sa politique de ressources
humaines autour de l'excellence, convaincue que la force de la société réside dans la qualité
et l’expertise des collaborateurs. Elle est ouverte, à l’écoute de ses salariés, soucieuse de leur
bien-être. Les membres de SiFast partagent leurs connaissances, leurs compétences et leurs
expériences.
Les équipes de SiFast sont organisées par technologie (LAMP7
/PHP8
/CMS9
, Mobile10
,
.NET11
, Java EE12
, BI13
) comme c’est présenté dans la figure 3. Les responsables d’équipes
ont acquis la maîtrise de la gestion de projets nearshores complexes et peuvent se prévaloir
d’une réelle expertise dans les modèles de delivery Front/Back leur permettant d’être forte
de proposition.
Figure 3: Les secteurs d'activité du SiFast
7 L’acronyme « LAMP » fait référence aux quatre composantes d'un tel serveur Web
8 Utilisé pour produire des pages Web dynamiques via un serveur HTTP
9 Une famille de logiciels destinés à la conception et à la mise à jour dynamique de sites Web
10 Développement des applications pour des terminaux mobile
11 Un ensemble de produits et de technologies informatiques de l'entreprise Microsoft
12 Une spécification pour la technique Java d'Oracle
13 L’informatique décisionnelleest l'informatique à l'usage des décideurs et des dirigeants d'entreprises
6

20. CHAPITRE I : ETUDE PREALABLE
I.4. Vision
SiFast, en tant que spécialiste reconnu des solutions innovantes, met au service de
ses clients ses expertises très pointues pour que leurs sites et leurs applications soient
uniques, captivants et différenciant.
Cette entreprise a tendance à améliorer encore ses solutions tout en adoptant des
nouvelles stratégies d’assurance qualité (QA) pour assurer la satisfaction totale de ses clients.
Figure 4: Organigramme de la société SiFast
II. Présentation de l’application
L'objectif principal de notre travail est de concevoir et de développer une boutique en
ligne pour présenter, simuler, commercialiser et livrer nos produits à nos clients, que nous
estimons devenir de plus en plus nombreux grâce à cette application de simulation.
L’application, que nous allons proposer et développer dans le cadre de notre projet de
fin d’études, permet d’offrir des nouvelles techniques d’interaction avec les mondes 3D par la
7

21. CHAPITRE I : ETUDE PREALABLE
superposition d'un modèle virtuel à la perception que nous avons naturellement de la réalité
et ceci en temps réel. Nous proposons d'analyser, de concevoir et d'implémenter une
application Kinect pour un ensemble de magasins.
II.1. CONCEPTS DE BASE
Composition de la porte :
Une porte d’entrée, c’est une des premières choses que l’on perçoit de l’habitat,
elle reflète l’ambiance, la personnalité de votre foyer.
Vue de l’intérieur, la porte est un véritable meuble de l’entrée, partie intégrante de
son esthétisme, de sa décoration.
Mais la question qui se pose :
Comment sera votre maison ou votre appartement avec
une nouvelle porte?
Une porte est une menuiserie constituée de deux cadres en profilés aluminium, PVC,
Bois, Acier…
Un cadre dormant fixé au mur et un cadre ouvrant et son vitrage s'articule autour
de celui-ci comme l’indique la figure ci-dessous (Figure 5).
8

22. CHAPITRE I : ETUDE PREALABLE
Figure 5: Schéma démonstratif des différents éléments d'une porte
Le premier tableau nous présente un schéma démonstratif des différents éléments d'une
telle porte tel que le châssis, le panneau, le vitrage, le ferrage, les paumelles et le seuil.
Tableau 1: Schéma démonstratif des différents éléments d'une porte
Composé d'un dormant et d'un ouvrant, il est l'armature de la porte.
Le châssis
Il supporte les autres éléments le composant : panneau, vitrage, ferrage
(quincaillerie), joints et seuil.
Il habille la porte et apporte une touche esthétique à celle-ci en fonction
Le
des moulures et des ®nitions choisies.
panneau
Il a également un rôle important dans la résistance à l'effraction et
l'isolation.
9

23. CHAPITRE I : ETUDE PREALABLE
Source de lumière, il offre de multiples possibilités esthétiques. Il joue
Le vitrage
un rôle non négligeable en matière d'isolation et de résistance à
l'effraction.
Il comporte tous les éléments qui assurent les mouvements de l'ouvrant
Le ferrage
et le verrouillage/déverrouillage de la porte. Il a une très forte incidence
sur la résistance à l'effraction.
Support de l'ouvrant, elles sont des pièces importantes. Chez Monsieur
Les
Store, nous avons fait le choix de paumelles lourdes qui assurent une
paumelles
sécurité optimale. Elles empêchent tout débondage et évitent tout
affaissement de la porte dans le temps et à l'usage. Elles permettent un
réglage en hauteur, largeur et profondeur, assurant ainsi une pose
parfaite de l'ouvrant.
de conception basique, en métal, il est souvent le point faible des portes
Le seuil
d'entrée d'ancienne génération. Monsieur Store vous préconise ceux
fabriqués dans un matériau isolant ou en aluminium (à rupture de pont
thermique) qui garantissent une excellente isolation. Il existe des seuils
à battement, ou ultraplats, facilitant l'accès des personnes à mobilité
réduite.
II.2. Objectifs à atteindre
Notre application a pour mission de concevoir et visualiser les portes de notre future
habitation par la projection de ces éléments sur la façade d'une maison et de faciliter la
manipulation des applications de simulation et utiliser des nouvelles techniques d’interaction
NUI14
.
Les objectifs à atteindre sont :
✓ Aider la clientèle à choisir leur propre porte.

✓ Aider les menuisiers vendeurs de présenter leurs gammes des produits.
14 Natural user interface
10

24. CHAPITRE I : ETUDE PREALABLE
✓ Aider les fabricants d’exposer leurs vastes produits.

✓ Capitaliser un savoir-faire dans les outils de simulation de portes.

✓ La simulation des objets virtuels dans le monde réelle.

✓ Permettre à l'utilisateur d'interagir directement c'est-à-dire sans outil
intermédiaire, avec la machine.

✓ Le corps humain devient le seul et unique "contrôleur15
".

✓ Transformer des objets de notre environnement en outil pour interagir avec
la machine.
✓ Les utilisateurs apprirent des mouvements et des actions qui leur permirent de
mieux et plus simplement explorer les possibilités d'interaction avec la machine.
✓ Une application simple à utiliser que l'on n'a même plus besoin de maîtriser.

✓ Répondre à toutes les exigences des usagers d'une manière optimale grâce à
ses fonctionnalités.
✓ Prévoir une application assez dynamique et simple pour assurer la cohérence du
processus de maintenance.
Le tableau ci-dessous (Tableau N°2) illustre une étude comparative entre les
deux modes d’utilisations NUI et GUI.
Tableau 2: Tableau comparative entre les deux modes d’utilisations NUI et GUI
Critères NUI GUI
facilite l'utilisateur peut connaitre les
fonctions facilement à travers les
mouvements naturels
les nouveaux utilisateurs peuvent avoir
un moment difficile d'apprendre
à utiliser la souris et toutes les
fonctions de l'interface graphique.
vitesse dépend de l'utilisateur l'utilisateur doit fonctionner en
utilisant la souris et le clavier
15 Un contrôleur est une entité qui a pour but de contrôler (dans le sens de surveiller ou de diriger/manipuler)
11

25. CHAPITRE I : ETUDE PREALABLE
souche aucune souche les touches de raccourci sont utilises
exemple tactile immersive 3d gnome Shell
II.3. Analyse de l’existant
Cette étude se base essentiellement sur des recherches et les études lors de notre
stage chez SiFast.
Dans un marché concurrentiel où les médias sociaux ont donné au client un rôle de
premier ordre, il est plus important que jamais de savoir ce que les clients pensent de services
offerts par une entreprise. Faire participer les clients de l’intérieur et s’assurer que tout le
monde partage la même vision, sont des composantes vitales à la survie et à la réussite de ses
activités.
La satisfaction de la clientèle est aujourd’hui monnaie courante pour la quasi-totalité
des entreprises et ce indépendamment de leur taille. Elle améliore la flexibilité, la
productivité et stimule la croissance du chiffre d’affaires.
A partir de ces exigences, la société SiFast a décidé d’offrir à sa clientèle (les
menuisiers, les distributeurs, les Clients …), une solution de la simulation en ligne, qui
leur permet de créer et de simuler à tout moment les besoins de leurs clients. Cette solution
qui représente une interface de représentation de notre future porte en temps réel.
Notre solution sera conçue pour être simple d’utilisation dans un souci d’efficacité
et de gain de temps, tout en apportant des données précises.
II.3.1. Etude de l’existant
L’étude de l’existant constitue une étape fondamentale dans notre projet. Elle consiste,
d’abord, à collecter toutes les informations nécessaires à la compréhension et à la
12

26. CHAPITRE I : ETUDE PREALABLE
caractérisation du système du logiciel informatique. Elle peut mener à une
observation critique sur ces informations afin de dégager les défaillances éventuelles.
L'impatience des internautes est légendaire. Plus une page prend de temps à charger,
plus l'internaute est tenté d'aller voir ailleurs, et parfois, ne plus revenir. D'après une étude
d’Akamai [2], 57 % des internautes abandonnent une page qui prend plus de 3 secondes à
charger, la première cause de lenteur d'un site web est liée au volume de données chargées.
Dans ce registre, le poste le plus gourmand concerne, sans aucun doute possible, les images.
Ce qui reflète le problème majeur dans les applications de simulation qui utilisent les
images matricielles au sein du site et engendrera en plus la perte de la qualité en fonction de
redimensionnement.
Malgré le nombre important des internautes dans le monde qui va atteindra 3,07
milliards en 2015, en hausse de +6,2% vs 2014. Cela représentera 42,4% de la population.
Pour les 3 années suivantes, les taux de croissance sont estimés à plus de 5%, et la
pénétration d'Internet devrait atteindre 48,2% en 2018 selon les dernières prévisions
d'eMarketer [3] et dispose la répartition géographique suivante illustrée dans la figure 6.
Figure 6: Schéma général de nombre d’internautes dans le monde
Légende :
13

27. CHAPITRE I : ETUDE PREALABLE
Or il n y avait que ces nouvelles applications NUI qui s’adressent principalement pour
créer des applications natives soit des applications Mobile ou bureautique sans prendre en
valeur les utilisateurs de l’internet et conserver les types d’interaction traditionelles en
utilisant les consoles classiques(clavier, souris …).
II.3.2. Critiques de l’existant
Nous avons pu diagnostiquer les systèmes existant des applications de simulation et
dégager les anomalies du système actuel tout en se rapportant à notre application comme c’est
indiqué dans la figure 7.
Parmi ces anomalies nous citons :
▪ Difficulté de mémorisation : quand un utilisateur revient sur l'interface après
une période d'inutilisation il est censé de retenir les emplacements des boutons
et les divers fonctionnalités.

▪ Problème de fiabilité : l'interface est conçue pour que l'utilisateur commette le
moins d'erreur possible mais cette interface se diffère d’un internaute à un autre.

▪ Perte de qualité : la qualité des applications de simulation diminue en fonction
de la résolution spatiale de chaque terminal.
▪ La perte du temps : l’internaute passe plusieurs minutes pour la
compréhension de notre système et l’exploitation par la suite.
▪ Manque de convivialité : chaque internaute possède son point de vue par
rapport l’application fourni mais nous sommes toujours obligé d’améliorer
l’interaction homme-machine pour que l'interface devient peu à peu agréable
pour l'utilisateur.
14

28. CHAPITRE I : ETUDE PREALABLE
▪ Application complexe : nécessite une bonne maitrise de la langue et quelque
notion informatique.
Figure 7: Schéma simplifié de la méthode d’interaction actuel
II.3.3. Appréciation
II.3.3.1. Champs de l’étude
Pour atteindre les objectifs fixés à l’avance nous proposons les solutions suivantes :
a) Problématique 1 :
Solution1 : Application Web SVG16
Le développement d’une application Web à base de SVG, Ce principe rend les
images SVG étirables sans perte de qualité.
Solution2 : Application Flash
Le développement d’une application Flash, nous permet de dynamiser la simulation
grâce au lecteur flash Player dans les navigateurs
b) Problématique 2 :
Solution1 : Application Kinect
16 (Scalable Vector Graphics) est un format de dessin vectoriel, élaboré à partir de 1998 par un groupe de travail comprenant entre autre
IBM, Apple, Microsoft, Xerox.
15

29. CHAPITRE I : ETUDE PREALABLE
Le développement d’une application Kinect, ce système nous permet de commander
l’application par la voix les gestes.
Solution2 : Application compatible sur AIRxTouch [4].
Le développement d’une application compatible sur AIRxTouch, grâce à une
Caméra Webcam et une Caméra Infrarouge, ce système permet d’interagir avec ses
utilisateurs sans contact.
Solution3 : Application pour des écrans tangibles17
Le développement d’une application sur des écrans tangibles : cette solution consiste à
développer une application sur des dispositifs tactiles (l’exemple des Smartphone, tablette…).
Solution4 : Application Leap Motion 18
Le développement d’une application compatible avec Leap Motion : cette
proposition vise d’interroger notre système avec les mouvements des mains et des 10 doigts.
Solution5 : Application WISEE [5]
Le développement d’une application à base de WISEE : cette solution a pour
objectif d’interagir en se basant sur les transmissions sans fil.
Solution choisie :
Nous avons défini un ensemble de critères d’évaluation afin de comparer les
propositions cité précédemment et d’en choisir une pour le développement comme
l’illustre les tableaux 3et 4.
17
Tactile
18
Capable de suivre les mains et les doigts ou les outils similaires de l’utilisateur
16

30. CHAPITRE I : ETUDE PREALABLE
a) Problématique 1 :
Tableau 3: Table de critère entre les deux premières solutions
Solution 1 Solution 2
Temps de réponses + _
Résolution des + -
images
Compatibilité + -
Référencement + -
Sécurité - +
Dans notre cas, nous avons choisi de développer une application Web à base de SVG
b) Problématique 2 :
Tableau 4: Table de critère entre les cinq solutions
Solution 1 Solution 2 Solution 3 Solution 4 Solution 5
Détection + _ _ _ _
squelettes
Détection + + _ + _
Main
Détection + _ + _ _
faciale
Détection + _ _ _ +
gestuelle
Compatibilité + _ _ _ _
Voix + + + + _
Fiabilité + _ _ _ _
Les limites d’une version desktop et les apports des applications web ont poussé la société
SiFast à nous proposer de développer un Framework pour Kinect V2 pour le web grâce à
17

31. CHAPITRE I : ETUDE PREALABLE
ses avantages par rapport aux autres solutions proposées illustré par un schéma explicatif
dans la figure 8.
Figure 8: Schéma de la solution choisi
Une analyse des solutions existantes montre que la plupart de ces applications
offrent des fonctionnalités de base pour l’utilisation du Kinect v1 dans les navigateurs.
Les applications développées sont censées pour les autres consoles et ne sont pas
implémenté à cet instant pour la deuxième génération du Kinect comme il est noté dans le
tableau 5.
Tableau 5: Tableau comparatif entre les différents Framework disponible
Framework Description et Compatibilité
Zigfu [6]
Permet l’interactivité avec MICROSOFT KINECT V1, ASUSXTION, et
ANY OPENNI SENSOR.
Compatibilité : Windows et Mac OS grâce à son Serveur
KinectJS
Permet l’interactivité avec MICROSOFT KINECT V1 seulement.
18

32. CHAPITRE I : ETUDE PREALABLE
L’existence de plusieurs exemples similaires à nos besoins.
Compatibilité : seulement Windows à travers son Serveur Web
Kinesis
Permet l’interactivité avec MICROSOFT KINECT XBOX seulement.
L’existence de plusieurs exemples similaires à nos besoins.
Compatibilité : seulement Windows à travers son Serveur Web
III. Langage et méthodologie de conception
La méthodologie est une démarche organisée rationnellement pour aboutir à un
résultat. Parmi les différentes méthodologies existantes, nous pouvons citer le modèle en
cascade utilisée souvent dans les simples projets dont les besoins sont clairs et bien définis dès
le début, le modèle en Y utiliser pour le développement des applications mobiles, ainsi que le
processus unifié et les méthodologies agiles (Scrum & extrême programming) caractérisées
par leurs souplesses et utilisées dans des grands projets.
Pour bien conduire notre projet et nous assurer du bon déroulement des différentes phases,
nous avons opté Scrum comme une méthodologie de conception et de développement.
Après le choix de la méthodologie, nous avons besoins d’un langage de modélisation
unifiée pour la modélisation de notre projet. Pour concevoir notre système, nous avons
choisi UML19
comme un langage de modélisation.
Notre choix s'est basé sur les points forts de ce langage notamment sa standardisation et
les divers diagrammes qu’il propose. Aussi UML présente le meilleur outil pour
19
Unified Modeling Language
19

33. CHAPITRE I : ETUDE PREALABLE
schématiser des systèmes complexes sous un format graphique et textuel simplifié et
normalisé.
En effet UML n'est ni un processus ni une démarche, d'où il fallait choisir une
méthodologie de conception et de développement que nous devons l'adopter
III.1. Pourquoi Scrum
« Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l’esprit du rugby et les adapte aux
projets de développement. Comme le pack lors d’un ballon porté au rugby, l’équipe chargée du
développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de
mêlée, le Scrum Master aiguillonne les membres de l’équipe, les repositionne dans la bonne
direction et donne le tempo pour assurer la réussite du projet. » [7]
Scrum est issu des travaux de deux des signataires du Manifeste Agile20
, Ken
Schwaber et Jeff Sutherland, au début des années 1990.Il appartient à la famille des
méthodologies itératives et incrémentales et repose sur les principes et les valeurs agiles21
.Le
plus souvent, les experts de Scrum, même ses fondateurs, le décrivent comme un cadre ou un
patron de processus orienté gestion de projet et qui peut incorporer différentes méthodes ou
pratiques d’ingénierie. S’il est difficile de définir la nature de Scrum, sa mise en place est
beaucoup plus simple et peut être résumée par la figure N°9.
Le principe de base de Scrum est le suivant :
➢ Dégager dans un premier lieu le maximum des fonctionnalités à réaliser pour former
le backlog du produit,
➢ En second lieu définir les priorités des fonctionnalités et choisir lesquelles
seront réalisé dans chaque itération,

➢ Par la suite focaliser l'équipe de façon itérative sur l’ensemble de fonctionnalités à
réaliser, dans des itérations appelées Sprints,
20
Le manifeste agile est un texte rédigé et signé en 2001 par 17 experts dans le domaine de
développement d’applications informatique.
21
Voir annexe A
20

34. CHAPITRE I : ETUDE PREALABLE
➢ Un Sprint aboutit toujours sur la livraison d’un produit partiel fonctionnel
appelé incrément.
Figure 9: Le processus Scrum
Le choix de Scrum comme une méthodologie de pilotage pour notre projet s’est
basé sur les atouts de ce dernier. Il se résumé comme suit:
➢ Plus de souplesse et de réactivité,

➢ La grande capacité d’adaptation au changement grâce à des itérations courtes,

➢ Et la chose plus importante, c’est que Scrum rassemble les deux cotés théorique et
pratique et se rapproche beaucoup de la réalité.
Vu que Scrum ne couvrant que les aspects de gestion de projet, et pour compléter le
vide laissé en matière de pratiques de développement, nous avons pris la décision de
coupler Scrum avec une autre méthodologie agile qui est l’extrême programming et qui
couvre les bonnes pratiques d’ingénierie logicielle notamment le développement dirigé par
le test, qui sera détaillé dans les chapitres qui suivent, et la programmation en binôme, etc.
21

35. CHAPITRE I : ETUDE PREALABLE
IV. Conclusion
Dans ce chapitre, nous avons défini, dans une première partie, le champ de l’étude
ainsi que les objectifs à atteindre. Dans une deuxième partie, nous avons étudié l’état actuel
de la société SiFast et enfin, nous avons proposé une solution pour la simulation des objets.
22

36. Chapitre II : Planification et architecture
Chapitre 2:
Planification et architecture
Dans le chapitre précédent, nous avons choisi
d'adopter la méthodologie Scrum pour la
conception de notre futur système. En fait,
Scrum est organisé suivant trois phases dont
la première est la phase de planification et
architecture (appelé aussi sprint 0 dans
quelques ouvrages).Cette phase est la plus
importante dans le cycle de développement
Scrum puisqu'elle qui influence directement
la réussite des sprints et en particulier le
premier.
23

37. Chapitre II : Planification et architecture
Introduction
Les travaux réalisés dans cette période de temps conduit à construire une bonne vision
du produit, identifier les rôles des utilisateurs et dégager les fonctionnalités principales afin de
produire le backlog initial ainsi qu'une première planification des sprints.
Cette phase fera donc l’objet de ce chapitre où nous commençons par la capture des
différents besoins, identifier les rôles des utilisateurs et préparer notre plan de release.
I. Capture des besoins
I.1. Identification des acteurs
a. Les acteurs
« Un acteur représente l’abstraction d’un rôle joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié. » [8]
Tous simplement un acteur est une entité physique (personne) ou abstraite (logiciel)
capable d’utilisée le système afin de répondre à un besoin bien définit. Les acteurs de notre
application sont :
✓ Le fournisseur : C’est lui, une personne ou une entreprise qui peut fabriquer les
portes et exercer des activités de vente de ces produits en gros.
✓ Le distributeur : C’est un gestionnaire de commerce de détail, avec des statuts
particulier. Il est chargé de présenter les portes et les services des fournisseurs dans le
but de les vendre aux clients actuels ou potentiels et d’installer les portes chez les
clients.
✓ L’internaute ou le client : Il désigne la personne ou l'entité qui prend la décision
d'acheter des portes chez un distributeur.
✓ L’administrateur: C’est lui, qui supervise l’enchainement du travail au sein de
notre application.
24

38. Chapitre II : Planification et architecture
b. Diagramme de contexte statique
Ce diagramme d’UML permet simplement de montrer la relation des différents acteurs
avec le système. Il spécifie le nombre d’instances de chaque acteur relié au système à un
moment donné comme il est indiqué dans la figure N°10.
Figure 10: Diagramme de contexte statique
Pour expliquer le diagramme ci-dessus, nous pouvons dire qu’à un instant t nous pouvons
avoir 0 ou plusieurs administrateurs qui manipulent l’application, et 0 ou plusieurs distributeurs
qui consultent la liste des leads ainsi 0 ou plusieurs clients qui sont en train d’utiliser
l’application.
I.2. Les besoins fonctionnels
Les besoins fonctionnels ou les cas d’utilisations en terme d’UML peuvent être définis comme
suit : « Un cas d’utilisation (use case) représente un ensemble de séquences d’actions réalisées
par le système et produisant un résultat observable intéressant pour un acteur particulier. » [8]
Un cas d’utilisation est une suite d’actions effectuées par le système afin de répondre à
une demande d’un utilisateur (acteur). Dans ce qui suit, nous décrivons les différents besoins
fonctionnels de notre système :
➢ Modifier l’image de la maison : Consiste à modifier l’image de notre simulation
à travers plusieurs méthodes (uploader une image, prendre une image, choisir une
image depuis la liste de maisons témoins),
25

39. Chapitre II : Planification et architecture
➢ Personnaliser la porte: Consiste à redimensionner et personnaliser notre porte
selon leur besoin esthétique (couleur, vitrage, accessoires, taille, angle …),
➢ Contacter le fournisseur : Permet à l’utilisateur de demander des conseils ou des
informations à propos les produits fournis,
➢ Valider une commande : Permet de l’utilisateur de passer son commande par le
remplissage d’un formulaire,
➢ Kinnifier la simulation : Consiste à offrir des nouveaux types d’interaction (par
geste, mouvement, émotions …),
➢ Mise à jour des fournisseurs : consiste d’offrir les fonctionnalités d’ajout,
modification et suppression des fournisseurs,

➢ Mise à jour des distributeurs : consiste d’offrir les fonctionnalités d’ajout,
modification et suppression des distributeurs,
➢ Consulter les détails des utilisateurs : Permet de consulter les détails des
utilisateurs, leurs commandes …,
➢ Consulter la liste des clients: Permet aux distributeurs de consulter les simulations
des leads et les contacter par la suite.
I.3. Les besoins non fonctionnels
Les besoins non fonctionnels sont des besoins qui ont un aspect visible pour l’utilisateur,
mais qui ne sont pas reliés directement au comportement du système. Les besoins non
fonctionnels de notre système se décrivent comme suit :
Besoins de disponibilité : notre application constitue de créer des simulations en ligne, il faut
que cette dernière soit disponible à tout moment.
Besoins de sécurité : vu que cette application contient des données confidentielles, tous les
accès aux différents espaces (administrateur, distributeur, etc.) doivent être protégés par un
mot de passe et un privilège d’accès. Ainsi, il faut s’assurer des cryptages des données au
niveau de la base.
26

40. Chapitre II : Planification et architecture
Besoins de performance : il s’agit d’optimiser le temps de chargements des pages par
l’utilisation des bonnes pratiques du développement. [9]
Besoins de portabilité et de compatibilité : notre application doit être portable sur tous les
environnements logiciels (Windows, Mac OS, Linux).
Besoins de documentation : lors de la livraison de l’application, nous devons fournir la
documentation nécessaire pour les utilisateurs finaux (administrateur, fournisseur, client etc.)
ainsi que les futurs développeurs.
Besoins d’utilisation : Tous les standards d’ergonomies doivent être présents : interface
utilisateur bien claire et simple dans l’utilisation.
II. Planning du traitement des cas d’utilisation
Après tout le travail d’identification des cas d’utilisation, nous devons maintenant les
classifier. La classification des cas d’utilisation doit tenir compte de deux facteurs principaux
qui sont la priorité et les risques. Cette technique est utilisée généralement lors de la
conception des applications se basant sur le processus unifié, mais elle reste valable et
intéressante pour notre cas.
II.1. Priorités
Généralement, on dit qu’un cas d’utilisation A est plus prioritaire que B, si sa
réalisation accélère la stabilisation du système. Le choix des priorités dans cette section s’est
basé sur la dépendance entre les fonctionnalités de l’application. Par exemple, nous ne
pouvons pas affecter les dus personnalisation des portes tant que nous n’avons pas encore
terminé la récupération des données. Par conséquent, nous pouvons dégager trois niveaux de
priorité qui sont : priorité haute, moyenne et faible.
II.2. Risques
Lors du pilotage d’un projet, l’identification des risques critiques présente une étape
indispensable pour la réussite de ce dernier. Pour notre cas, le seul risque qui peut nous
ralentir est lié la complexité de l’application et aux différentes contraintes à respecter.
27

41. Chapitre II : Planification et architecture
III. Pilotage du projet avec Scrum
Le cadre Scrum est constitué de trois éléments qui sont l'équipe avec des rôles bien
définis, les blocs de temps22
et les artefacts.
III.1. Les outils Scrum
Pour le pilotage de leurs projets Scrum, les membres de l'équipe font recours à plusieurs
techniques. Une de ces techniques, qui est la plus répondue, consiste à créer des fiches (post It)
et de les coller sur un mur ou sur un tableau visible pour tous les membres de l'équipe. Une
autre technique consiste à utiliser un fichier Excel contenant toutes les informations nécessaires
pour les sprints, les user story leurs estimations, etc. Ce fichier devra être partagé en lecture et
en écriture (pour que tous les membres de l'équipe puissent le modifier à tout moment).
Par conséquent, plusieurs outils sont apparus en offrant la possibilité de suivre la priorité,
la traçabilité et la gestion de tout le travail associé. Parmi les outils existants, nous avons choisi
d’utiliser Serena Scrum [10].
III.2. Équipe et rôles
« L’équipe a un rôle capital dans Scrum : elle est constituée avec le but d’optimiser la
flexibilité et la productivité; pour cela, elle s’organise elle-même et doit avoir toutes les
compétences nécessaires au développement du produit. Elle est investie avec le pouvoir et
l’autorité pour faire ce qu’elle a à faire ». [7]
Bref, Scrum définit trois rôles qui sont :
Le Product Owner (le propriétaire du produit) : c’est une personne qui porte la vision du
produit à réaliser, généralement c’est un expert dans le domaine.
Le Scrum Master (le directeur de produit) : c'est la personne qui doit assurer le bon
déroulement des différents sprints du release, et qui doit impérativement maitriser Scrum.
Le Scrum Team (l’équipe de Scrum) : constitué des personnes qui seront chargées
d’implémenter les différents besoins du client. Bien évidemment, cette équipe sera constituée
des développeurs, des testeurs comme il est illustré dans figure N°11.
22
Blocs de temps souvent appelé timeboxes
28

42. Chapitre II : Planification et architecture
Dans le contexte de notre projet, M Fadhel ABID sera le propriétaire de produit, M.
Khaled MASMOUDI sera le directeur de produit ainsi l’équipe Scrum est composé par 5
développeur sont: M Tarak KHLIF, M Amin MAGDICH, Mlle Fatma BOUCHAKOI, Mlle
Molka DEJMAL, Mlle Khouloud Ismail.
Figure 11: Équipe Scrum
III.3. Le backlog du produit
Le backlog du produit est l’artefact le plus important de Scrum, c’est l’ensemble des
caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité. Les
caractéristiques fonctionnelles sont appelées des histoires utilisateur (user story) et les
caractéristiques techniques sont appelées des histoires techniques (technical story).
Le tableau 6 résume le backlog produit de notre application. Il est à noter que nous
n’avons pas cité les histoires techniques comme la préparation de la maquette graphique, les
travaux de conception et les jeux de tests, etc. Dans ce tableau chaque histoire utilisateur est
caractérisée par un rang déduit à partir de ses risques et sa priorité expliqués dans la section II
de ce même chapitre. Pour le traitement de nos histoires utilisateur nous choisissons de
commencer avec les cas d’utilisation les plus prioritaires et ayant le risque le moins élevé.
En plus du rang, chaque histoire utilisateur possède un effort (vélocité) qui est
l’estimation initiale sur la quantité de travail nécessaire pour implémenter cette exigence. Cet
29

43. Chapitre II : Planification et architecture
effort est calculé en point d’histoire qui correspond aux jours hommes idéaux. Généralement,
un point d’histoire vaut un jour/homme.
30

44. Chapitre II : Planification et architecture
Tableau 6: Backlog produit
Nom Effort Rang Description Thème
23
Risque Priorité
La récupération des 1 1 La récupération des Réalisation d’une Faible Élevé
données. informations sous format application de
JSON en utilisant les Web simulation
Services REST.
La manipulation de SVG 2 2 Consiste de reconstruire une Réalisation d’une Faible Élevé
image SVG avec des formules application de
mathématiques simulation
L’utilisation des plugins 1 3 Permet la reconstruction et la Réalisation d’une Moyen Élevé
Raphael.JS et Fabric.JS manipulation de la plateforme application de
et SnapSVG.JS de simulation d’une manière simulation
dynamique.
Nom Effort Rang Description Thème Risque Priorité
La récupération des 2 4 Permet de parcourir la liste des Réalisation d’un Moyen Élevé
informations depuis un personnes et de sélectionner Framework Kinect
dispositif Kinect l’un des utilisateurs engagés
puis la récupération de toute
information relative à ce
23
Thème : c’est la traduction du mot « features » selon Claude Aubry
31

45. Chapitre II : Planification et architecture
dernier en utilisant la
plateforme .Net.
La transmission des 2 5 Consiste de stocker les Réalisation d’un Moyen Élevé
données à travers la informations d’utilisateur Framework Kinect
technologie du Web engagé dans un vecteur ensuite
Socket les transformer sous format
JSON et enfin les envoyer au
niveau du Web Socket
La récupération des 1 6 Permet de récupérer les Réalisation d’un Moyen Élevé
données au niveau des informations transmis au Framework Kinect
Navigateurs niveau du Web Socket.
La définitions des 1 7 L’implémentation d’un Script Réalisation d’un Moyen Élevé
interactions au niveau du qui nous permet le Click, le Framework Kinect
JavaScript déplacement du curseur.
La définition des gestes 1 8 Permet la reconnaissance d’un Réalisation d’un Moyen Élevé
certain type de geste au niveau Framework Kinect
de l’application.
32

46. Chapitre II : Planification et architecture
III.4. Diagramme des cas d’utilisation global
Dans cette section nous présentons les besoins de notre système de manière formelle.
C'est-à-dire en utilisant le diagramme des cas d’utilisation du langage de modélisation UML
comme il est illustré dans la figure N°12.
Figure 12: Diagramme des cas d’utilisation global
33

47. Chapitre II : Planification et architecture
III.5. Architecture
Avant de se lancer dans la conception et le développement de tout système informatisé,
il est important de préparer l’architecture de ce dernier. Le terme architecture est vaste
puisqu’il y peut désigner l’architecture logique, l’architecture physique, architecture
logicielle, etc. Dans ce paragraphe nous nous intéressons à l’architecture « modèle
client/serveur » comme il est illustré dans la figure 13, c’est un mode de communication à
travers un réseau entre plusieurs programmes ou logiciels : l'un, qualifié de client, envoie des
requêtes ; l'autre ou les autres, qualifiés de serveurs, attendent les requêtes des clients et y
répondent. Dans notre cas, le client désigne également une console Kinect sur lequel il peut
interagir avec notre site, et le serveur, l'ordinateur sur lequel est exécuté le logiciel serveur.
Figure 13: architecture Client/serveur
34

48. Chapitre II : Planification et architecture
Cette application contient deux modes d’utilisation chaque mode à sa propre
architecture:
Mode hors ligne :
Architecture 1-Tier notre Framework peut être implémenté en Mode hors ligne.
Notre ordinateur sur laquelle nous avons installé notre Kinect va récupérer les
informations à travers un Framework développé en C# et les transmis au niveau des navigateurs à
l’aide d’un web socket sur l’adresse locale « LOCALHOST » et le port « 2012 »
Figure 14: Représentation de l’architecture 1 tiers
Mode en ligne :
L’architecture 3-Tier divise chaque application en trois couches logiques séparées
comme il est illustré dans la figure 15:
La couche présentation contient l'interface utilisateur. La couche métier effectue le
contrôle de processus métier, où la logique et les règles fonctionnelles sont exécutées. La
couche donnée se charge du stockage de données et y contrôle les données. Le composant de
gestion des données s'assure que les données sont conformes dans tout l'environnement
distribué. Employer des données fermant à clef et évitant la réplique des données peut assurer
leur uniformité.
35

49. Chapitre II : Planification et architecture
Figure 15: Représentation de l’architecture N tiers
III.6. Planification des sprints
La réunion de planification des sprints est l’événement le plus important dans Scrum.
Le but de cette réunion est de préparer le planning de travail et d’identifier le backlog des
sprints24
. L’un des produits de cette réunion est le choix de la durée des sprints et qui diffère
selon la complexité du projet et la taille de l’équipe. Pour notre projet nous avons choisi de
développer deux releases. Le premier sera nommé gestion des ressources (ressources
matérielles et humaines de l’école) et le second sera pour la gestion de l’enseignement. Pour
notre cas la durée de 21 jours pour un sprint semble adéquate.
La figure N°16 résume notre planning de travail.
24
Backlog du sprint : c’est l’ensemble des user story inclus dans le sprint
36

50. Chapitre II : Planification et architecture
Figure 16: Plan du release
V. Conclusion
Dans ce chapitre nous avons préparé notre plan de travail. Nous avons capturé les
besoins fonctionnels de notre application, les rôles des utilisateurs, par la suite nous avons
préparé l’architecture client/serveur ainsi que le plan de release de notre projet.
37

51. Chapitre III : La réalisation d’une application de simulation
Chapitre 3:
Release 1 : La réalisation
d’une application de
simulation
Le terme release peut être défini comme une
version distribuée d'une application [15] ou une
période de temps qui permet de la produire.
Peu importe quelle définition nous utilisons,
une release est constituée d'une suite
d'itérations (sprint) qui se terminent quand les
incréments de ces derniers construisent un
produit présentant suffisamment de valeur aux
utilisateurs finaux.
La durée des releases est définie par le
Product Owner en collaboration avec son
équipe Scrum. Notre premier release sera
composé de deux sprints, chacune ayant une
vélocité de 30 jours. Tous au long de ce
chapitre, nous allons traiter les histoires
utilisateurs de nos sprints pour produire un
incrément potentiellement livrable.

52. 38

53. Chapitre III : La réalisation d’une application de simulation
I. Le premier sprint
Le sprint est le cœur de Scrum. Il s’agit d’un bloc de temps durant lequel un incrément
du produit sera réalisé. Tous les sprints d’une release ont une durée constante et ne se
chevauchent jamais, c'est-à-dire qu’un sprint ne peut pas démarrer tant que le précédent n’est
pas encore terminé.
Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir le but de
ce dernier. Ce but doit être défini en terme métier et non pas en terme technique pour qu’il
soit compréhensible par les membres en dehors de l’équipe. Il s’agit de répondre à une
question fondamentale « pourquoi faisons-nous ce sprint ? ». Suite à une conversation entre le
Product Owner et l’équipe Scrum, nous avons décidé le but suivant : «l’implémentation du
SVG au niveau de la simulation ».
Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires
inclure dans ce dernier. Plus précisément, quelles histoires de notre backlog du produit seront
incluses dans le backlog du sprint. Le tableau 7résume donc le backlog de notre premier sprint :
Tableau 7: Backlog du premier sprint (release 1)
Histoire utilisateur Estimation
La reconstruction des images SVG. 7
L’utilisation des plugins Raphael.JS 10
L’utilisation des plugins Fabric.JS 10
Passons maintenant au vif de notre sujet : les activités et le cycle de développement.
Dans un sprint nous pouvons dégager quatre activités principales qui sont la spécification
39

54. Chapitre III : La réalisation d’une application de simulation
fonctionnelle, la conception, le codage et le test. Tout au long de ce sprint, nous respectons ces
activités pour construire le plan de notre travail.
I.1. Spécification fonctionnelle
La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas
d’utilisation d’UML et la description textuelle de ces derniers.
I.1.1 Description du champ de l’étude
Dans cette sous-section, nous présentons le diagramme de cas d’utilisation illustrant les
interactions entre les acteurs et notre application comme il l’indique le schéma suivant (figure
17).
❖ Description graphique des cas d’utilisation :
Figure 17: Diagramme de cas d’utilisation Front Office
40

55. Chapitre III : La réalisation d’une application de simulation
❖ Description textuelle des cas d’utilisation:
Pour rendre notre diagramme des cas d’utilisation plus lisible et afin de décrire le
comportement d’un système, les concepteurs d’UML proposent l’utilisation d’une technique
nommée la description textuelle des cas d’utilisation. En outre, la description textuelle n’est
pas normalisée dans UML. Nous proposons donc d’utiliser le plan adapté par Pascal Roques
dans [11].
a) Description textuelle du cas d’utilisation « Uploader une image »
Tableau 8: Description textuelle du cas d'utilisation « Uploader une image »
Description
Titre Uploader une image
But Permet à l’utilisateur d’intégrer l’image de son habitation au
niveau de notre application dans l’objectif de simuler les
portes disponibles.
Pré-condition L’application est lancée, une connexion internet est requise.
Scénario nominal L’application demande à l’utilisateur de choisir une image à
travers sa localisation dans son propre machine « Path ».
L’utilisateur choisit une image et appuie sur le bouton
Valider.
L’application vérifie l’extension du notre image et demande
à l’utilisateur de choisir les points de contrôles.
L’utilisateur modifie la position et la taille de l’image selon
la résolution spatiale de son écran et appuie sur le bouton
Continuer.
L’application adapte sa nouvelle image et l’affiche sur la
zone de simulation.
Enchaînements alternatifs
- A1 : image non valide L’enchainement A1 démarre au point 3 du scénario nominal.
41

56. Chapitre III : La réalisation d’une application de simulation
L’application indique à l’utilisateur que l’extension de son
image n’est pas valide.
Le scénario nominal reprend au point 1.
Enchaînements d’erreur Néant.
Post-conditions L’image de notre utilisateur a été adaptée au niveau de la
simulation.
b) Description textuelle du cas d’utilisation « Prendre une image »
Tableau 9: Description textuelle du cas d'utilisation « Prendre une image »
Description
Titre Prendre une image
But Permet à l’utilisateur de prendre des photos en temps réel.
Pré-condition L’utilisateur choisit le menu « Maison » et appuie sur le
bouton « Prendre Photo».
Scénario nominal L’application vérifie si une Cam est installée correctement
sur son propre dispositif.
L’application affiche une interface de capture qui nous
permet de prendre des images.
L’utilisateur appuie sur le bouton « Capturer »pour prendre
une image.
L’application demande à l’utilisateur de choisir les points de
contrôles.
L’utilisateur modifie la position et la taille de l’image selon
la résolution spatiale de son écran et appuie sur le bouton
Continuer.
L’application adapte sa nouvelle image et l’affiche sur la
zone de simulation.
Enchaînements alternatifs Néant.
42

57. Chapitre III : La réalisation d’une application de simulation
Enchaînements d’erreur
- E1 : annuler le traitement L’enchaînement E1 démarre au point 1 du scénario nominal
L’application ne détecte pas une caméra installée.
Le cas d’utilisation se termine en échec.
Post-conditions L’image de notre utilisateur a été adaptée au niveau de la
simulation.
c) Description textuelle du cas d’utilisation « Définir la vue »
Tableau 10: Description textuelle du cas d'utilisation « définir la vue »
Description
Titre Définir la vue
But Permet de définir la vue de notre simulation (intérieur,
extérieur).
Pré-condition Une connexion est requise.
Scénario nominal L’utilisateur appuie sur le bouton « Changer vue ».
L’application affiche l’image par défaut de la vue
sélectionnée.
Enchaînements alternatifs Néant
Enchaînements d’erreur Néant.
Post-conditions l’image de notre simulation est changée.
d) Description textuelle du cas d’utilisation « Choisir les accessoires »
Tableau 11: Description textuelle du cas d'utilisation « Choisir les accessoires »
Description
Titre Choisir les accessoires
But Permet à l’utilisateur d’ajouter une valeur esthétique au
niveau de son porte souhaité.
43

58. Chapitre III : La réalisation d’une application de simulation
Pré-condition l’utilisateur appuie sur la rubrique « Accessoires » et choisit
l’accessoire souhaité.
Scénario nominal L’application affiche tous les accessoires disponibles sur la
gamme courante.
L’utilisateur appuie sur l’accessoire souhaité.
L’application récupère l’accessoire et l’injecte au niveau de
la simulation.
Enchaînements alternatifs Néant
Post-conditions La zone de la simulation est modifiée par les nouveaux
accessoires.
e) Description textuelle du cas d’utilisation « Ajuster la taille »
Tableau 12: Description textuelle du cas d'utilisation « ajuster la taille »
Description
Titre Ajuster la taille.
But Permet le redimensionnement du notre porte.
Pré-condition l’utilisateur appuie sur la porte.
Scénario nominal L’application affiche les points de contrôle relatif de notre
porte.
L’utilisateur appuie sur une des points de contrôle et le
déplace au niveau de la zone de simulation en utilisant la
technologie de Drug and Drop.
L’application nous permet d’afficher la porte avec les
nouvelles modifications.
Enchaînements alternatifs Néant.
Post-conditions Néant.
44

59. Chapitre III : La réalisation d’une application de simulation
f) Description textuelle du cas d’utilisation « Changer Type de cadre »
Tableau 13: Description textuelle du cas d'utilisation « Changer Type de cadre »
Description
Titre Changer type de cadre
But Permet de changer le type du cadre au niveau de la
simulation.
Pré-condition l’utilisateur appuie sur la rubrique« Formes» et choisit type
du cadre « Standard, Mono Bloc ».
Scénario nominal L’application affiche la simulation avec le nouveau type de
cadre.
Enchaînements alternatifs Néant.
Post-conditions Néant.
g) Description textuelle du cas d’utilisation « Personnaliser les éléments «Couleurs »
Tableau 14: Description textuelle du cas d'utilisation « Personnaliser les éléments «Couleurs »
Description
Titre Personnaliser les éléments « Couleurs »
But Permet à l’utilisateur de changer le couleur des éléments de
son porte.
Pré-condition l’utilisateur appuie sur la rubrique « Couleurs».
Scénario nominal L’application affiche la liste des couleurs disponible.
L’internaute appuie sur leur couleur souhaité.
L’application affiche la nouvelle simulation dont le couleur
modifié.
Enchaînements alternatifs Néant.
Post-conditions Néant.
h) Description textuelle du cas d’utilisation « Choisir la forme »
45

60. Chapitre III : La réalisation d’une application de simulation
Tableau 15: Description textuelle du cas d'utilisation « Choisir la forme »
Description
Titre Choisir la forme
But Permet la modification de la forme.
Pré-condition l’utilisateur appuie sur la rubrique « Formes».
Scénario nominal L’application affiche toutes les formes disponibles.
L’application demande à l’utilisateur s’il désire de changer
la forme.
L’utilisateur appuie sur la forme désiré.
L’application affiche à l’utilisateur les nouvelles
modifications.
Enchaînements alternatifs Néant.
Post-conditions Néant.
i) Description textuelle du cas d’utilisation « Valider Commande »
Tableau 16: Description textuelle du cas d'utilisation « Valider Commande »
Description
Titre Valider Commande
But Permet de passer son commande à un fournisseur dans le
but d’obtenir un devis.
Pré-condition l’utilisateur appuie sur le bouton « J’enregistre ma
simulation»
Scénario nominal L’application affiche un formulaire a rempli.
Le mainteneur rempli le formulaire.
L’application vérifie les champs et enregistre les
informations ainsi la simulation au niveau de la base de
données.
L’application affiche un message de confirmation.
46

61. Chapitre III : La réalisation d’une application de simulation
Enchaînements alternatifs Néant.
Post-conditions L’application envoie un mail de validation pour le client et
un autre pour le fournisseur.
I.2. Diagrammes de séquences
Le diagramme de séquences permet de cacher les interactions d'objets dans le cadre
d'un scénario d'un diagramme de cas d'utilisation. Dans un souci de simplification, nous
représentons l'acteur principal à gauche du diagramme, et les acteurs secondaires éventuels à
droite du système. Le but étant de décrire comment se déroulent les actions entre les acteurs
ou objets. La dimension verticale du diagramme représente le temps, permettant de visualiser
l'enchainement des actions dans le temps, et de spécifier la naissance et la mort d'objets. Les
périodes d'activité des objets sont symbolisées par des rectangles, et ces objets dialoguent par
le biais de messages.
47

62. Chapitre III : La réalisation d’une application de simulation
a) Diagramme de séquence détaillé du cas d’utilisation « création d’une simulation »
Figure 18: Diagramme de séquence détaillé du cas d’utilisation « création de la simulation »
La figure n°18 illustre les tâches de la création d’une simulation. Dans ce diagramme, l’utilisateur charge notre application pour entrer à sa
session. Après le chargement, l’utilisateur accède à son espace ainsi qu’aux différentes fonctions.
48

63. Chapitre III : La réalisation d’une application de simulation
b) Diagramme de séquence détaillé du cas d’utilisation « modification des matériaux »
Figure 19: Diagramme de séquence détaillé du cas d’utilisation « modification des matériaux »
La figure n°19 illustre les tâches de la modification des matériaux. Dans ce diagramme, l’utilisateur peut consulter la liste des matériaux.
Ainsi, il peut changer le matériau actuel selon un critère choisi.
49

64. Chapitre III : La réalisation d’une application de simulation
c) Diagramme de séquence détaillé du cas d’utilisation « modification des formes »
Figure 20: Diagramme de séquence détaillé du cas d’utilisation « modification des formes »
La figure n°20 illustre les tâches consultation et modification des formes. Dans ce diagramme, l’utilisateur peut consulter tous les formes
puis il peut choisir une forme de la liste.
50

65. Chapitre III : La réalisation d’une application de simulation
d) Diagramme de séquence détaillé du cas d’utilisation « modification des panneaux »
Figure 21: Diagramme de séquence détaillé du cas d’utilisation « modification des panneaux »
La figure n°21 illustre les tâches de la modification des panneaux. Dans ce diagramme, l’utilisateur peut afficher les panneaux disponibles
ainsi, il peut choisir le panneau désiré.
51

66. Chapitre III : La réalisation d’une application de simulation
e) Diagramme de séquence détaillé du cas d’utilisation « modification des couleurs »
Figure 22: Diagramme de séquence détaillé du cas d’utilisation « modification des couleurs »
La figure n°22 illustre les tâches de la modification des couleurs. Dans ce diagramme, l’utilisateur peut consulter les couleurs disponibles.
Ainsi, il peut modifier le couleur de notre porte souhaité.
52

67. Chapitre III : La réalisation d’une application de simulation
f) Diagramme de séquence détaillé du cas d’utilisation « modification des vitrages »
Figure 23: Diagramme de séquence détaillé du cas d’utilisation « modification des vitrages »
La figure n°23 illustre les tâches de la modification des couleurs. Dans ce diagramme, l’utilisateur peut consulter la liste des vitrages
disponibles ainsi, il peut choisir l’un de ses vitrages.
g) Diagramme de séquence détaillé du cas d’utilisation « changement d’image »
53

68. Chapitre III : La réalisation d’une application de simulation
Figure 24: Diagramme de séquence détaillé du cas d’utilisation « changement d’image »
La figure n°24 illustre les tâches du changement d’image. Dans ce diagramme, l’utilisateur peut consulter la liste des maisons témoins,
choisir l’une de ses images pour personnaliser son simulation.
h) Diagramme de séquence détaillé du cas d’utilisation « changement des accessoires »
54

69. Chapitre III : La réalisation d’une application de simulation
Figure 25: Diagramme de séquence détaillé du cas d’utilisation « changement des accessoires »
La figure n°25 illustre les tâches du changement des accessoires. Dans ce diagramme, l’utilisateur peut consulter la listes des accessoires
pour la gamme choisi ainsi il peut choisir l’une des accessoires de la liste.
55

70. Chapitre III : La réalisation d’une application de simulation
I.3. Diagramme de classe
Le diagramme de classe est l’un des diagrammes statiques d'UML. Il permet de décrire
la structure d'un système informatique tout en montrant les différentes classes, leurs attributs,
leurs méthodes ainsi que les relations entre eux. Tout au long de nos sprints, nous essayerons
de construire ce diagramme au fur et mesure en ajoutant les différentes classes déduites.
L’étape typiquement orientée objet de l’analyse est la décomposition d’un domaine
d’intérêt en classes conceptuelles représentant les entités significatives de ce domaine. Il
s’agit simplement de créer une représentation visuelle des objets du monde réel dans un
domaine donné comme l’illustre le tableau N°17.
Tableau 17: Table liste des objets naturels
Numéro Classe Entités Propriétés
01 Vue_Maison id_vue Public
type_vue Private
02 Type_Accesoire id_Type_Accessoire Public
Libellé_Type_Accessoire Private
03 Sérigraphie id_Sèrigraphie Public
Libellé_Sèrigraphie Private
UrlImage_Sèrigraphie Private
PrixSupp_Sèrigraphie Private
04 Vitrage id_vitrage Public
56

71. Chapitre III : La réalisation d’une application de simulation
libelle_vitrage Private
05 Materiau id_Materieau Public
libelle_Materieau Private
06 Gamme id_Gamme Public
libéllé_Gamme Private
description_Gamme Private
07 Forme id_Forme Public
Libellé_Forme Private
08 Contart id_Contart Public
Civilité_Contart Private
Attribute Private
09 Distributeur id_Distributeur Public
RaisonSociale_Distributeur Private
CodeSiret_Distributeur Private
Email_Distributeur Private
10 Imposte id_Imposte Public
HauteurMax_Imposte Private
HauteurMin_Imposte Private
57

72. Chapitre III : La réalisation d’une application de simulation
11 Chasis id_Chasis Public
12 Cadre id_Cadre Public
HauteurMin_Cadre Private
HauteurMax Private
13 Vantail id_Vantail Public
HauteurMax_Vantail Private
HauteurMin_Vantail Private
Sens_Ouverture_Vantail Private
14 Element id_Element Public
Libéle_Element Private
Largeur_Element Private
attribute_min_Element Private
Largeur_Choisi_Element Private
Prix_Element Private
15 Couleur Id_Couleur Public
Libellè_Couleur Private
IntansitéR_Couleur Private
IntensitéV_Couleur Private
58

73. Chapitre III : La réalisation d’une application de simulation
IntensitéB_Couleur Private
Prix_Supp_Couleur Private
16 Accessoire id_Accessoire Public
Libellè_Accessoire Private
Url_Image_Accessoire Private
PositionX_Accessoire Private
PositionY_Accessoire Private
Prix_Supp_Accessoire Private
17 Picture_Maison id_picture Public
Description_Picture Private
Luminosité_Picture Private
Brillance_Picture Private
Largeur_Picture Private
Longeur_Picture Private
18 Simulation id_Simulation Public
Libellé_Simulation Private
19 Adresse id_Adresse Public
Adresse_Rue Private
59

74. Chapitre III : La réalisation d’une application de simulation
Adresse_Nro Private
Adresse_Ville Private
Adresse_code_postal Private
Adresse_Pays Private
Latitude Private
Longitude Private
20 Navigateur Id_Navigateur Public
Type_Navigateur Private
Version_Navigateur Private
21 Client Id_Client Public
Adresse_IP_Client Private
Pays_Client Private
Nom_Client Private
Contact_Client Private
Email_Client Private
Password_Client Private
Géolocalisation_Client Private
TelFixe_Client Private
60

75. Chapitre III : La réalisation d’une application de simulation
TelMob_Client Public
I.3.1. Représentation des associations
Les associations représentent des relations structurelles entre les classes d’objets.
Une association :
Exprime une connexion sémantique bidirectionnelle entre n classes (n>=1),
Représente une relation conceptuelle durable entre n classes (n>=1).
Les cardinalités d’une association :
Une cardinalités, dans une association, exprime le nombre de participations possibles
d’une occurrence de chaque entité à l’association comme il est indiqué dans le tableau 18.
Tableau 18: Table multiplicité des associations
1 Un et un seul
0..1 Zéro ou un
M..N De M à N (entiers)
0..* De 0 à plusieurs
1..* De 1 à plusieurs
N N (entier naturel)
Les associations qui figureront dans notre diagramme sont les suivantes comme
l’illustre le tableau N°19:
Tableau 19: Table de la représentation des associations
Numéro Association Classe Cardinalité
01 Possédé Gamme 1.*
61

76. Chapitre III : La réalisation d’une application de simulation
Accessoire 1.*
02 est achevé Simulation 1.1
Vue_Maison 1.1
03 est installé Adresse 1.*
Client 1.1
04 se connecte Client 1.*
Navigateur 1.1
05 Réalise Client 1.1
Simulation 1.*
06 Présente Forme 1.1
Simulation 1.*
07 est composé Forme 1.*
Element 1.*
08 Fabriqué Materiau 1.1
Gamme 1.*
09 Possède Gamme 1.*
Accessoire 1.*
10 Dispose Vitrage 0.1
Chassis 0.1
11 Caractérisé Vitrage 0.*
Sérigraphie 0.*
12 Peinturer Couleur 0.*
Vantail 2.*
13 est achevé Accessoire 1.*
Type_accessoire 1.1
14 Soussigne Distributeur 1.*
62

77. Chapitre III : La réalisation d’une application de simulation
Contrat 1.1
15 Se localise Distributeur 1.1
Adresse 1.1
I.3.2. Représentation des classes
Une classe n’est pas une fonction mais une description abstraite d’un ensemble d’objets du
domaine de l’application ; elle définit leur structure, leur comportement et leur relation.
Tableau 20: Table de la représentation des classes
Numéro Classe Attributs
01 Vue_Maison id_vue
type_vue
02 Type_Accesoire id_Type_Accessoire
Libellé_Type_Accessoire
03 Sérigraphie id_Sèrigraphie
Libellé_Sèrigraphie
UrlImage_Sèrigraphie
PrixSupp_Sèrigraphie
04 Vitrage id_vitrage
libelle_vitrage
05 Materiau id_Materieau
libelle_Materieau
63

78. Chapitre III : La réalisation d’une application de simulation
06 Gamme id_Gamme
libéllé_Gamme
description_Gamme
07 Forme id_Forme
Libellé_Forme
08 Contart id_Contart
Civilité_Contart
Attribute
09 Distributeur id_Distributeur
RaisonSociale_Distributeur
CodeSiret_Distributeur
Email_Distributeur
10 Imposte id_Imposte
HauteurMax_Imposte
HauteurMin_Imposte
11 Chasis id_Chasis
12 Cadre id_Cadre
HauteurMin_Cadre
64

79. Chapitre III : La réalisation d’une application de simulation
HauteurMax
13 Vantail id_Vantail
HauteurMax_Vantail
HauteurMin_Vantail
Sens_Ouverture_Vantail
14 Element id_Element
Libéle_Element
Largeur_Element
attribute_min_Element
Largeur_Choisi_Element
Prix_Element
15 Couleur Id_Couleur
Libellè_Couleur
IntansitéR_Couleur
IntensitéV_Couleur
IntensitéB_Couleur
Prix_Supp_Couleur
16 Accessoire id_Accessoire
65

80. Chapitre III : La réalisation d’une application de simulation
Libellè_Accessoire
Url_Image_Accessoire
PositionX_Accessoire
PositionY_Accessoire
Prix_Supp_Accessoire
17 Picture_Maison id_picture
Description_Picture
Luminosité_Picture
Brillance_Picture
Largeur_Picture
Longeur_Picture
18 Simulation id_Simulation
Libellé_Simulation
19 Adresse id_Adresse
Adresse_Rue
Adresse_Nro
Adresse_Ville
Adresse_code_postal
66

81. Chapitre III : La réalisation d’une application de simulation
Adresse_Pays
Latitude
Longitude
20 Navigateur Id_Navigateur
Type_Navigateur
Version_Navigateur
21 Client Id_Client
Adresse_IP_Client
Pays_Client
Nom_Client
Contact_Client
Email_Client
Password_Client
Géolocalisation_Client
TelFixe_Client
TelMob_Client
I.3.3. Représentation des méthodes
67

82. Chapitre III : La réalisation d’une application de simulation
Tableau 21: représentation des méthodes/classes
Nom de la Classe Numéro Méthodes
Forme
01 Forme ()
02 Récupérer Elements ()
03 Récupérer Matériau ()
04 Récupérer Gamme ()
05 Simulation ()
Simulation
06 Récupérer Forme ()
07 Récupérer Vue_Maison ()
I.3.4. Présentation du diagramme de classe
Les diagrammes de classes expriment la structure statique du système, en termes de classes et
de relations entre ces classes.
Un diagramme de classes n’exprime rien de particulier sur les liens d’un objet donné, mais
décrit de manière abstraite les liens potentiels d’un objet vers d’autres objets.
68

83. Chapitre III : La réalisation d’une application de simulation
Figure 26: Représentation des classes
69

84. Chapitre III : La réalisation d’une application de simulation
I.4. Transformation en modèle relationnel
Les travaux menés dans cette activité se résument tout simplement dans l’implémentation
et la réalisation des histoires utilisateurs analysés lors des étapes précédentes. Pour notre cas, nous
nous intéresserons seulement au schéma de la base de données.
Pour construire le schéma de base de données de notre application, nous devons
appliquer certaines règles pour passer d’un schéma entité association (diagramme de classe)
vers un schéma relationnel. Ces règles sont bien définies dans l’annexe B.
Dans ce qui suit, nous présentons les tables de notre base de données, tout en tenant
compte du type et des contraintes de leurs champs.
Tableau 22: Liste des tables du modèle relationnel
Numéro Nom de la Table Attributs TYPE Contraintes
01 Distributeur id_Distributeur integer PRIMARY KEY
RaisonSociale_Distributeur char UNIQUE
CodeSiret_Distributeur char UNIQUE
Email_Distributeur char UNIQUE
02 Contrat id_Contart integer PRIMARY KEY
Civilité_Contart char ---
03 Adresse id_Adresse integer PRIMARY KEY
Adresse_Rue char ---
Adresse_Nro char ---
70

85. Chapitre III : La réalisation d’une application de simulation
Adresse_Ville char ---
Adresse_code_postal integer ---
Adresse_Pays char ---
Latitude float ---
Longitude float ---
ClientId_Client integer FOREIGN KEY
04 Client Id_Client integer PRIMARY KEY
Adresse_IP_Client char ---
Pays_Client char ---
Nom_Client char ---
Contact_Client char ---
Email_Client char UNIQUE
Password_Client char ---
Géolocalisation_Client char ---
TelFixe_Client char UNIQUE
05 Simulation id_Simulation integer PRIMARY KEY
Libellé_Simulation char ---
Vue_maisonid_vue integer FOREIGN KEY
71

86. Chapitre III : La réalisation d’une application de simulation
ClientId_Client integer FOREIGN KEY
Formeid_Forme integer FOREIGN KEY
06 Navigateur Id_Navigateur integer PRIMARY KEY
Type_Navigateur char ---
Version_Navigateur char ---
ClientId_Client integer FOREIGN KEY
07 Vue_maison id_vue integer PRIMARY KEY
type_vue char ---
Picture_Maisonid_picture integer ---
08 Picture_Maison id_picture integer PRIMARY KEY
Description_Picture char ---
Luminosité_Picture float ---
Brillance_Picture float ---
Largeur_Picture float ---
Longeur_Picture float ---
09 Forme id_Forme Integer PRIMARY KEY
Libellé_Forme Char ---
10 Ventail id_Element integer PRIMARY KEY
72

87. Chapitre III : La réalisation d’une application de simulation
Libéle_Ventail Char ---
Largeur_Ventail Float ---
Hauteur_min_Ventail Float ---
Largeur_Choisi_Ventail Float ---
Prix_Element Float ---
Vitrageid_vitrage integer FOREIGN KEY
CouleurId_Couleur integer FOREIGN KEY
11 Element_Forme Elementid_Element integer PRIMARY KEY
Formeid_Forme integer PRIMARY KEY
12 Gamme id_Gamme integer PRIMARY KEY
libéllé_Gamme Char ---
description_Gamme Char ---
Materiauid_Materieau integer FOREIGN KEY
113 Materiau id_Materieau integer PRIMARY KEY
libelle_Materieau Char ---
14 Element_Gamme Elementid_Element integer PRIMARY KEY
Gammeid_Gamme integer PRIMARY KEY
15 Cadre id_Cadre integer PRIMARY KEY
73

88. Chapitre III : La réalisation d’une application de simulation
Libéle_cadre Char ---
Largeur_cadre Float ---
Largeur_Choisi_cadre Float ---
Prix_cadre Float ---
HauteurMin_Cadre Float ---
HauteurMax Float ---
16 Cadre_Gamme Cadreid_Cadre integer PRIMARY KEY
Gammeid_Gamme integer PRIMARY KEY
17 Imposte id_imposte integer PRIMARY KEY
Libéle_imposte Char ---
Largeur_imposte Float ---
hoteur_min_imposte Float ---
Largeur_Choisi_imposte Float ---
Prix_imposte Float ---
HauteurMax_Imposte Float ---
HauteurMin_Imposte Float ---
Vitrageid_vitrage integer FOREIGN KEY
18 Imposte_Gamme Imposteid_imposte integer PRIMARY KEY
74

89. Chapitre III : La réalisation d’une application de simulation
Gammeid_Gamme integer PRIMARY KEY
19 Accessoires id_Accessoire integer PRIMARY KEY
Libellè_Accessoire Char ---
Url_Image_Accessoire Char ---
PositionX_Accessoire integer ---
PositionY_Accessoire integer ---
Prix_Supp_Accessoire Float ---
Type integer ---
Accessoiresid_Type_Access
oire
20 Type Accessoires id_Type_Accessoire integer PRIMARY KEY
Libellé_Type_Accessoire char PRIMARY KEY
21 Gamme_Accessoires Gammeid_Gamme integer PRIMARY KEY
Accessoiresid_Accessoire integer PRIMARY KEY
22 Vitrage id_vitrage integer PRIMARY KEY
libelle_vitrage char ---
Sérigraphieid_Sèrigraphie integer FOREIGN KEY
23 Sérigraphie id_Sèrigraphie integer PRIMARY KEY
Libellé_Sèrigraphie char ---
75

90. Chapitre III : La réalisation d’une application de simulation
UrlImage_Sèrigraphie char ---
PrixSupp_Sèrigraphie float ---
24 Chasis id_chasis integer PRIMARY KEY
Libéle_chassis char ---
Largeur_chassis float ---
attribute_min_chassis float ---
Largeur_Choisi_chassis float ---
Prix_chassis float ---
Vitrageid_vitrage integer FOREIGN KEY
25 Chasis_Gamme Chasisid_chasis integer PRIMARY KEY
Gammeid_Gamme integer PRIMARY KEY
26 Couleur Id_Couleur integer PRIMARY KEY
Libellè_Couleur char ---
IntansitéR_Couleur integer ---
IntensitéV_Couleur integer ---
IntensitéB_Couleur integer ---
Prix_Supp_Couleur float ---
76

91. Chapitre III : La réalisation d’une application de simulation
Figure 27: Représentation du Modelé relationnel
77

92. Chapitre III : La réalisation d’une application de simulation
I.5. Test
Le test est un processus manuel ou automatique, qui vise à établir qu’un système
vérifie les propriétés exigées par sa spécification, ou à détecter des différences entre les
résultats engendrés par le système et ceux qui sont attendus par la spécification. (Définition
issue de la norme IEEE-STD729, 1983).
Les activités de test constituent un axe très important dans le cycle de développement
d’un logiciel. Ils permettent de détecter les erreurs afin de les corriger et d’assurer la qualité
du logiciel fourni.
Contrairement aux cycles de développement séquentiel25
, avec la méthodologie agile,
le test n'est pas une phase qui se déroule après la fin de développement. En effet, les tests
seront intégrés dès le début du premier sprint jusqu’à la livraison du produit final. En outre, la
qualité du logiciel n’est pas négligeable, c’est dans ce cadre que Scrum doit être complété par
les bonnes pratiques d’ingénierie techniques du logiciel. Parmi ces pratiques26
, seulement
deux qui nous intéressent et qui sont le pilotage par les tests (TDD, Test Driven
Developement) centrés sur les tests unitaires, et le pilotage par les tests d’acceptation (ATDD,
Acceptance Test Driven Development).
I.5.1. Les tests unitaires
Le principe de cette pratique est d’écrire les tests avant même d’écrire le code et de
profiter par la suite de l’existence des tests automatiques pour l’amélioration et le
remaniement du code. Cette technique permet aux programmeurs de rester simples au niveau
du code et de s’assurer de son bon fonctionnement après des changements.
25
Ce sont les méthodologies dont les activités de développement (spécification, conception, codage et test) se
déroulent séquentiellement notamment le modèle en cascade ou en V. (Nommage de Claude Aubry)
26
Les pratiques les plus connues sont : l’intégration continue, la programmation en binôme, etc.
78

93. Chapitre III : La réalisation d’une application de simulation
Dans ce paragraphe, nous avons choisi de tester les histoires utilisateurs qui sont : La
manipulation de SVG, L’utilisation des plugins Raphael.JS et Fabric.JS et SnapSVG.JS. Pour
la création des tests unitaires de ces histoires, nous avons eu recours à un outil open source
d'intégration continue Jenkins [12].
Figure 28: Exemple de capture d’écran de l’outil de test « Jenkins »
II. Conclusion
Le résultat d’un release est un produit livrable au client contrairement au résultat d’un
sprint qui est un produit potentiellement livrable. A la fin de ce chapitre, nous avons réussi à
produire un incrément ayant suffisamment de valeur pour le client et pourra être utilisé dans
un environnement de production.
Dans le chapitre qui suit, notre effort sera consacré pour produire un nouveau release
couvrant les fonctionnalités de kinnifier le web.
79

94. Chapitre IV : Réalisation d’un Framework Kinect
Chapitre 4:
Release 2 : Réalisation
d’un Framework Kinect
Après avoir entamé le premier release de
notre système informatique, nous pouvons
maintenant nous lancer dans les travaux
nécessaires pour produire le second release.
En effet les méthodologies agiles, et Scrum
en particulier, sont caractérisées par un
rythme régulier. Tout au long de chapitre
nous aurons deux sprints ayant la même
vélocité que les sprints précédents, et nous
allons traiter les histoires utilisateurs de ces
derniers pour avoir à la fin de ce release le
logiciel complet, livrable et fonctionnel.
80

95. Chapitre IV : Réalisation d’un Framework Kinect
I. Le premier sprint
En partant sur le même principe que les sprints précédents, nous commençons par
définir le but de notre premier sprint pour ce release. Suite à une conversation entre le Product
Owner et l’équipe Scrum, nous avons décidé le but suivant : « la conception et la
développement d’une application .Net qui permet de kinnifier le Web».
Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires
inclure dans ce dernier. Le Tableau 23 résume donc le backlog de notre premier sprint :
Tableau 23: Backlog du premier sprint (release 2)
Histoire utilisateur Estimation
La récupération des informations depuis un 15
dispositif Kinect
La transmission des données à travers la 2
technologie du Web Socket
La récupération des données au niveau des 12
Navigateurs
I.1. Spécifications fonctionnelles
La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas
d’utilisation d’UML et la description textuelle de ces derniers.
I.1.1. Diagramme des cas d’utilisation
Dans la figure 29 nous illustrons le diagramme des cas d’utilisation globaux pour ce
premier sprint.
En respectant toujours le même principe que les sprints précédents, nous avons
découpé certaines histoires utilisateurs en un ensemble de tâches.
81

96. Chapitre IV : Réalisation d’un Framework Kinect
Figure 29: Diagramme des cas d'utilisation du premier sprint (release 2)
82

97. Chapitre IV : Réalisation d’un Framework Kinect
I.1.2. Description textuelle des cas d’utilisation
Nous allons maintenant décrire chacun des cas d'utilisations énuméré dans le
paragraphe précédent en identifiants les acteurs et les différents scénarios possible.
a) Description textuelle du cas d’utilisation « Déplacer le curseur»
Tableau 24: Description textuelle du cas d'utilisation « Déplacer le curseur »
Description
Titre Déplacer le curseur
Acteurs Utilisateur
But Permet la navigation dans au niveau des navigateurs en
utilisant l’une des mains.
Pré-condition Si la connexion est détectée, un dispositif Kinect est installé
correctement, le plugin de Kinect server est lancé et
l’utilisateur est engagé.
Scénario nominal L’utilisateur va interagit avec l’application web par le
déplacement de l’un de ses mains dans les différents sens.
L’application tient à changer l’emplacement du curseur en
fonction de la main active.
Enchaînements alternatifs Néant.
Exceptions Néant.
Post-conditions Néant.
b) Description textuelle du cas d’utilisation « engager»
Tableau 25: Description textuelle du cas d'utilisation « engager »
Description
Titre Engager
83

98. Chapitre IV : Réalisation d’un Framework Kinect
Acteurs Utilisateur
But Demande l’interaction avec la console Kinect.
Pré-condition Si la connexion est détectée, un dispositif Kinect est installé
correctement, le plugin de Kinect server est lancé.
Scénario nominal L’utilisateur commence de se positionner devant la console
Kinect.
L’application récupère la liste de tous les utilisateurs suivis.
L’utilisateur lève l’une de ses mains pour exprimer qu’il
veut s’engager à la simulation.
L’application vérifie la liste des conditions minimales et
récupère les informations relatives à cet utilisateur.
Enchaînements alternatifs Néant.
Exceptions Néant.
Post-conditions Néant.
I.2. Conception
Dans cette section nous commençons par le diagramme de séquence système des
différents cas d’utilisation déjà détaillés dans la section précédente.
I.2.1. Diagramme de séquence système
En nous référant aux descriptions textuelles dans la section précédente, nous
présentons les diagrammes de séquences systèmes adéquats.
La figure n°30 illustre les tâches de déplacement du curseur. Dans ce diagramme,
l’utilisateur peut déplacer le curseur dans les différents sens.
84

99. Chapitre IV : Réalisation d’un Framework Kinect
Figure 30: Diagramme de séquence système du cas d'utilisation "engager un utilisateur "
I.2.2. Diagramme de séquence système
En se basant sur la description textuelle des cas d’utilisation, nous modélisons donc
le diagramme de séquence détaillé de ces derniers.
85

100. Chapitre IV : Réalisation d’un Framework Kinect
A. Diagramme de séquence détaillé du cas d’utilisation « engager avec l’utilisateur »
Figure 31: Diagramme de séquence détaillé du cas d'utilisation "engager avec l’utilisateur "
La figure n°31 illustre les tâches pour l’engagement d’un utilisateur. Dans ce diagramme, l’utilisateur peut par la suite interagir librement
avec le dispositif Kinect.
86

101. Chapitre IV : Réalisation d’un Framework Kinect
B. Diagramme de séquence détaillé du cas d’utilisation « Déplacer le Curseur»
Figure 32: Diagramme de séquence détaillé du cas d'utilisation "Déplacer le Curseur"
La figure n°32 illustre les tâches minimales pour le déplacement d’un curseur. Dans ce diagramme, l’utilisateur peut déplacer le curseur au
sein de la page Web.
87

102. Chapitre IV : Réalisation d’un Framework Kinect
1.2.3. Diagramme de classe
Tableau 26: Table liste des objets naturels
Numéro Classe Entités Propriétés
01 Kinect UniqueKinectId Public
AudioSource Private
BodyFrameSource Private
BodyIndexFrameSource Private
ColorFrameSource Private
CoordinateMapper Private
DepthFrameSource Private
InfraredFrameSource Private
IsAvailable Private
IsOpen Private
KinectCapabilities Private
LongExposureInfraredFrameSource Private
02 Body TrackingId Public
Engaged Private
HandLeftState Private
HandLeftConfidence Private
88

103. Chapitre IV : Réalisation d’un Framework Kinect
HandRightState Private
HandRightConfidence Private
JointCount Private
LeanTrackingState Private
03 Joints id_joints Public
X Private
Y Private
Z Private
04 JointsOrientations JointType Public
Orientation Private
05 Expression Happy Private
Engaged Private
WearingGlasses Private
LeftEyeClosed Private
RightEyeClosed Private
MouthOpen Private
MouthMoved Private
LookingAway Private
89

104. Chapitre IV : Réalisation d’un Framework Kinect
FaceYaw Private
FacePich Private
Tableau 27: Table de la représentation des associations
Numéro Association Classe Cardinalité
01 Engager Client 1.1
Kinect 1.1
02 Récupère Kinect 1.1
Body 1.1
03 Détecte Body 1.1
Joints 25.25
04 Suivi Body 1.1
JointsOrientations 25.25
05 Évaluer Expression 1.1
Body 1.1
I.2.3.1. Représentation des méthodes
Tableau 28: représentation des méthodes/classes
Nom de la Classe Numéro Méthodes
Kinect 01 Kinect ()
02 Close ()
03 GetDefault ()
04 Open ()
05 OpenMultiSourceFrameReader ()
Body 06 Body ()
90

105. Chapitre IV : Réalisation d’un Framework Kinect
07 Récupérer JointOrientations ()
08 Récupérer Joints ()
09 IsTracked ()
JointsOrientations 10 JointsOrientations ()
Joints 11 Joints ()
Expression 12 Expression ()
Tableau 29: Table de la représentation des classes
Numéro Classe Attributs
01 Kinect UniqueKinectId
AudioSource
BodyFrameSource
BodyIndexFrameSource
ColorFrameSource
CoordinateMapper
DepthFrameSource
InfraredFrameSource
IsAvailable
IsOpen
KinectCapabilities
LongExposureInfraredFrameSource
91

106. Chapitre IV : Réalisation d’un Framework Kinect
02 Body TrackingId
Engaged
HandLeftState
HandLeftConfidence
HandRightState
HandRightConfidence
JointCount
LeanTrackingState
03 Joints id_joints
X
Y
Z
04 JointsOrientations JointType
Orientation
05 Expression Happy
Engaged
WearingGlasses
LeftEyeClosed
RightEyeClosed
92

107. Chapitre IV : Réalisation d’un Framework Kinect
MouthOpen
MouthMoved
LookingAway
FaceYaw
FacePich
FacenRoll
Après tous le travail de spécification et de conception, nous pouvons maintenant
construire le nouvel incrément de notre diagramme des classes en ajoutant les différents
éléments (classes, associations, attributs, etc.) déduits à partir des activités précédente (Figure
33).
Clé du diagramme
1. Classes déduits à partir du sprint 1 du premier release
2. Classes déduits à partir du sprint 1 du second release
93

108. Chapitre IV : Réalisation d’un Framework Kinect
Figure 33: Diagramme de classe du premier sprint (release 2)
94

109. Chapitre IV : Réalisation d’un Framework Kinect
I.3. Test
En partant toujours du même principe que les sprints précédents, et en appliquant les
bonnes pratiques d’ingénierie logicielle inspirée de la méthodologie extrême programming
(XP), nous commençons par les tests unitaires de l’histoire utilisateur « modifier une unité
d’enseignement »
I.3.1. Test unitaire
Dans ce paragraphe, nous testons toujours nos histoires utilisateur en utilisant un outil
d'intégration continue Jenkins.
II.Le deuxième sprint
En partant sur le même principe que le sprint précédent, nous commençons par définir le
but de notre second sprint. Suite à une conversation entre le Product Owner et l’équipe Scrum,
nous avons décidé le but suivant : « terminer la partie qui concerne Kinnification du Web ».
Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires
inclure dans ce dernier. Le tableau 30 résume donc le backlog de notre second sprint :
Tableau 30: Backlog du second sprint (release 2)
Histoire utilisateur Estimation
La définition des interactions au niveau du JavaScript 15
La définition des gestes 10
Dans le tableau 30, nous pouvons constater que les histoires utilisateur « lister les fonctions
», « ajouter une fonction » et « modifier une fonction » ne figurent pas dans le backlog de produit.
En effet, notre backlog de produit initial ne couvre pas toutes les fonctionnalités requises et c’est
pour cette raison que nous aurons des nouvelles fonctionnalités au fur et mesure
95

110. Chapitre IV : Réalisation d’un Framework Kinect
de notre avancement. En plus, nous pouvons constater que les vélocités de nos histoires ont
changé par rapport à l’estimation initiale tout en gardant la même durée que le sprint précédent.
II.1. Spécifications fonctionnelles
Pour la spécification fonctionnelle de ce sprint, nous commençons par le diagramme
des cas d’utilisation.
II.1.1. Diagramme des cas d’utilisation
Dans la figure 34, nous illustrons le diagramme des cas d’utilisation global pour ce
second sprint.
En respectant toujours le même principe que le sprint précédent, nous avons découpé
certaines histoires utilisateurs en un ensemble de tâches.
Clé du diagramme
1. Cas d’utilisation déduits à partir du sprint 1 du deuxième release
2. Cas d’utilisation déduits à partir du sprint 2 du deuxième release
96

111. Chapitre IV : Réalisation d’un Framework Kinect
Figure 34: Diagramme des cas d'utilisation du second sprint (release 2)
97

112. Chapitre IV : Réalisation d’un Framework Kinect
II.1.2. Description textuelle des cas d’utilisation
Nous allons maintenant décrire chacun des cas d'utilisation énuméré dans le paragraphe
précédent en identifiants les acteurs et les différents scénarios possible.
a) Description textuelle du cas d’utilisation « Redimensionner la porte»
Tableau 31: Description textuelle du cas d'utilisation « Redimensionner la porte»
Description
Titre Redimensionner la porte
Acteurs Utilisateur
But Permet le redimensionnement de la porte à l’aide des gestes
et les interactions NUI.
Pré-condition Si la connexion est détectée, un dispositif Kinect est installé
correctement, le plugin de Kinect server est lancé et
l’utilisateur est engagé.
Scénario nominal L’utilisateur commence à sélectionner l’objet « porte ».
L’utilisateur présente une des gestes relative au
redimensionnement.
L’application commence à changer la taille de la porte
respectivement à la geste tourné.
Enchaînements alternatifs Néant.
Exceptions Néant.
Post-conditions Néant.
b) Description textuelle du cas d’utilisation « Sélectionner et cliquer sur les éléments
interactifs»
98

113. Chapitre IV : Réalisation d’un Framework Kinect
Tableau 32: Description textuelle du cas d'utilisation « Sélectionner et cliquer sur les éléments
interactifs»
Description
Titre Sélectionner et cliquer sur les éléments interactifs
Acteurs Utilisateur
But Permet la sélection et le clique sur les éléments interactifs.
Pré-condition Si la connexion est détectée, un dispositif Kinect est installé
correctement, le plugin de Kinect server est lancé et
l’utilisateur est engagé.
Scénario nominal L’utilisateur ferme et avance l’une des mains.
L’application lance la clique au sein du navigateur.
Enchaînements alternatifs Néant.
Exceptions Néant.
Post-conditions Néant.
c) Description textuelle du cas d’utilisation « Tourner les objets»
Tableau 33: Description textuelle du cas d'utilisation « Tourner les objets »
Description
Titre Tourner les objets
Acteurs Utilisateur
But Permet la rotation des objets en utilisant les gestes.
Pré-condition Si la connexion est détectée, un dispositif Kinect est installé
correctement, le plugin de Kinect server est lancé et
l’utilisateur est engagé.
Scénario nominal L’utilisateur commence à sélectionner l’objet « porte ».
L’utilisateur présente une des gestes relative à la rotation.
99

114. Chapitre IV : Réalisation d’un Framework Kinect
L’application tient la rotation de la porte respectivement à
la position des mains.
Enchaînements alternatifs Néant.
Exceptions Néant.
Post-conditions Néant.
II.1.3. Diagramme de séquence détaillé
En se basant sur la description textuelle des cas d’utilisation, nous modélisons donc le
diagramme de séquence détaillé de ces derniers.
100

115. Chapitre IV : Réalisation d’un Framework Kinect
A. Diagramme de séquence détaillé pour le cas d’utilisation « Tourner les objets »
Figure 35: Diagramme de séquence détaillé du cas d'utilisation "Tourner les objets"
La figure n°35 illustre les tâches pour tourner un objet dans les navigateurs tel que « le porte ». Dans ce diagramme, l’utilisateur peut tourner
la porte de simulation.
101

116. Chapitre IV : Réalisation d’un Framework Kinect
B. Diagramme de séquence détaillé pour le cas d’utilisation « Redimensionner la porte »
Figure 36: Diagramme de séquence détaillé du cas d'utilisation " Redimensionner la porte"
La figure n°36 illustre les tâches pour redimensionner la porte au niveau de la simulation Dans ce diagramme, l’utilisateur peut
redimensionner la porte (horizontale, verticale, perspective) .
102

117. Chapitre IV : Réalisation d’un Framework Kinect
C. Diagramme de séquence détaillé pour le cas d’utilisation « Sélectionner et cliquer sur les éléments interactifs»
Figure 37: Diagramme de séquence détaillé du cas d'utilisation " Sélectionner et cliquer sur les éléments interactifs"
La figure n°37 illustre les tâches pour sélectionner ou faire cliquer sur des interactifs (bouton, lien , canvas …), l’utilisateur peut sélectionner
ou faire des cliques.
103

118. Chapitre IV : Réalisation d’un Framework Kinect
III. Conclusion
A ce stade, nous avons réussir donc à développer le dernier release de notre application
pour arriver à un produit complet et fonctionnel. Il nous reste seulement une dernière étape et
qui consiste à implémenter l’application auprès du client final.
104

119. Chapitre V : La phase closure
Chapitre 5:
La phase closure
La phase closure ou de fermeture est la
dernière phase dans le cycle de
développement d’un logiciel avec Scrum.
Cette phase est souvent appelé sprint de
stabilisation [16]. Les tâches effectuées
pendant cette phase ne sont pas claires, et ils
dépendent fortement du type de déploiement
du logiciel (mise en production à chaud,
packaging du produit, mise à disposition par
téléchargement en ligne...).
Pour notre projet, ce chapitre sera consacré
pour la présentation des langages et outils de
programmation utilisés pour la réalisation de
notre application, le déploiement de notre
application et sa documentation. Nous
finissons pour quelques interfaces graphiques
du logiciel fourni.
105

120. Chapitre V : La phase closure
I. Environnement de développement
L’environnement de développement est un terme qui désigne l’ensemble d’outils et de
langage utilisé pour l’implémentation d’une solution informatique. Nous commençons par
l’environnement matériel.
I.1. Environnement matériel
Pré requis :
Pour pouvoir utiliser la Kinect 2 sur notre PC ou tablette, il va falloir un certain nombre
de pré requis, le volume de donnée qui va transiter entre la Kinect 2 et notre PC étant bien
plus important que la V1, notre machine doit respecter les spécifications minimales suivantes
illustrées dans le tableau 34 :
Tableau 34: Table de caractéristiques matérielles requises
Processeur : 64 bits (x64)
Dual-core 3,1 GHz physique (2 logical cores per physical)
USB : Contrôleur USB 3.0
RAM : 4 GO de RAM au minimum
Carte Graphique : Carte graphique prenant en charge DirectX 11
Système d’exploitation : Windows 8 ou 8.1 ou Windows Embedded 8
La liste est donc beaucoup plus restrictive que sur la V1. Il faut savoir aussi que si nous
souhaitons faire du Kinect Fusion, il vous faudra une carte graphique très robuste.
Notre application a été réalisée sur deux ordinateurs dont les caractéristiques sont les
suivantes illustrées dans le tableau 35 :
106

121. Chapitre V : La phase closure
Tableau 35: Table de caractéristiques matérielles
Marque DELL LATITUDE 5520 DELL OPTIPLEX
RAM : 8 Go 1067 MHz DDR3 8 Go 1067 MHz DDR3
Processeur 2.66 GHz Intel Core I5 2.66 GHz Intel Core I5
Disque dur 800 Go 500 Go SSD
USB 2.0 3.0
Système d’exploitation Windows 8.1 Windows 8.1
Depth Sensor
IR Emitters
Power Light
IR Emitters
RGB Camera
Depth Sensor
Microphone Array
Figure 38: La composition du Kinect V2
Il faut savoir que la Kinect 2 est différente de la première. En effet, là où la V1 utilisait
une matrice infrarouge (lumière structurée) pour la détection de profondeur, la V2 utilise la
technologie Time of Light qui réellement bien plus efficace. Ce qui lui permet d’être bien plus
précise et ce même dans le noir.
107

122. Chapitre V : La phase closure
I.2. Environnement de test
Jenkins, qui s'appelait à l'origine Hudson, est un outil d'Intégration
Continue open source écrit en Java. Bénéficiant d'une part de marché dominante, Jenkins est
utilisé par des équipes de toutes tailles, pour des projets dans des langages et des technologies
variés, incluant Java, NET, Ruby, Grails, PHP …. »
Ils existent plusieurs autres serveurs d’intégration continue tels que « Continuum » et
« Atlassian Bamboo », mais le choix de Jenkins était le plus approprié pour plusieurs raisons.
Tout d‘abord, Jenkins est très facile à utiliser : nous pouvons démarrer avec lui en
quelques minutes. En effet, son interface utilisateur est très simple, clair, intuitive et visuellement
agréable et s’adapte facilement aux désirs de l’utilisateur grâce à sa flexibilité.
Ensuite, la communauté de Jenkins est immense, réactive, dynamique et accueillante et
le rythme de développement est très intense (dernière évolution, correction et mises à jour des
extensions, …).
De plus, nous pouvons installer facilement des centaines d’extensions open source
qui couvrent tous les outils de « build » et de gestion de configuration, les métriques de
qualités de code et beaucoup d’autres fonctionnalités encore par exemple Plagin TestLink,
Plagin Selenium….
Aussi, on peut installer « Jenkins » sur les différents systèmes d'exploitation. Avec
Jenkins, il est possible d'utiliser un grand nombre d'outils qui ne sont pas intégré directement à
Jenkins tels que le système de gestion de version (CVS, Git, SVN) et peut exécuter des projets
basés sur Apache Ant ou Maven.
108

123. Chapitre V : La phase closure
I.3. Environnement de production
« C’est un logiciel de gestion de version distribué, très puissant et récent, il a
été créé par Linus Torvalds, qui est entre autres l’homme à l’origine de Linux.
Il se distingue par sa rapidité et sa gestion des branches qui permettent de
développer en parallèle de nouvelles fonctionnalités. »
Git est considéré comme performant, au point que certains autres logiciels de gestion de
version (Darcs, Arch), qui n'utilisent pas de base de données, se sont montrés intéressés par le
système de stockage des fichiers de Git pour leur propre fonctionnement.
Les principales commandes utilisées avec système de gestion de version sont :
❖ Clone : pour obtenir une copie d’un projet existant.

❖ Checkout : pour récupérer une branche ou un chemin de l’arbre de travail.

❖ Status : pour afficher l’état de la copie de travail, c'est-à-dire les fichiers qui ont
été modifiés par rapport au référentiel.
❖ Add : pour préparer un fichier ou un répertoire à être ajouter sur le serveur.

❖ Delete : pour préparer un fichier ou un répertoire à être supprimer.

❖ Commit : envoyer les fichiers et les répertoires modifiés au serveur.
109

124. Chapitre V : La phase closure
Figure 39: Fonctionnement de Git
I.4. Environnement logiciel
Pour implémenter notre application, nous avons eu recours aux outils de
développement suivants :
❖ Microsoft Visual Studio :
Microsoft Visual Studio est une suite de logiciels de développement pour Windows
conçue par Microsoft. La dernière version s'appelle Visual Studio 2015.
Visual Studio est un ensemble complet d'outils de développement permettant de générer
des applications Web ASP.NET, des Services Web XML, des applications bureautiques et des
applications mobiles. Visual Basic, Visual C++, Visual C# et Visual J# utilisent tous le même
environnement de développement intégré (IDE, Integrated Development Environment), qui leur
permet de partager des outils et facilite la création de solutions faisant appel à plusieurs langages.
Par ailleurs, ces langages permettent de mieux tirer parti des fonctionnalités du Framework .NET,
qui fournit un accès à des technologies clés simplifiant le développement d'applications Web ASP
et de Services Web XML grâce à Visual Web Developer.
❖ Kinect v2 Configuration Verifier
Il vous permet rapidement de tester si vous avez les pré-requis pour Kinect 2 (figure
40) et si elle communique bien avec votre machine. En cas d’erreur, un petit texte vous
permet d’avoir des conseils sur le pré requis ou les causes du dysfonctionnement.
110

125. Chapitre V : La phase closure
Figure 40: Kinect v2 Configuration Verifier
❖ Kinect Studio
Le Kinect Studio (figure 41) nous permet d’enregistrer nos sessions avec Kinect 2 sous
forme d’un fichier replay qui pourra être rejoué plus tard sans forcément avoir une Kinect 2
connecté à votre système. Cela nous permet par exemple d’enregistrer une session de
mouvement pour un cas précis de notre applicatif et de le rejouer à loisir en mettant des points
d’arrêts, sans avoir à bouger de notre siège, car il n’y a rien de plus pénible que de devoir se
lever, se mettre devant la Kinect et revenir à son siège pour voir ou sa cloche ou encore
stopper l’exécution.
Figure 41: Kinect Studio
❖ Visual Gesture Builder :
111

126. Chapitre V : La phase closure
Pour le dernier outil de ce SDK, Visual Gesture Builder. Déjà il faut savoir que cet outil
est une PREVIEW, donc non complet, non terminée, etc. La promesse de cet outil et de pouvoir
décomposer des gestuelles sous forme de données qui pourront être importé dans le SDK au
run time afin de détecter des gestuelles précise.
Après avoir lancé le Visual Gesture Builder, il faut créer une solution (un peu comme
dans Visual Studio) et y mettre des projets. Chaque projet contiendra des gestuelles. L’ajout
d’une gestuelle fera apparaître cette popup :
Figure 42: Visual Gesture Builder
Elle permet de déterminer de quoi sera composée votre gestuelle, en gros s’il y aura les
mains, si le haut du corps suffit et le type. Cela permet à l’outil d’être plus précis dans sa
détection de mouvement.
Photoshop est un logiciel de retouche, de traitement et de dessin assisté par ordinateur
édité par Adobe. Il est principalement utilisé pour le traitement de photographies
numériques, mais sert également à la création d'images ex nihilo. Adobe Illustrator.
112

127. Chapitre V : La phase closure
Adobe Illustrator est le logiciel de création graphique vectorielle de référence dans les
environnements professionnels. Il fait partie de la gamme Adobe et peut être utilisé
indépendamment ou en complément de Photoshop. Il offre des outils de dessin vectoriel
puissants.
Sublime Text est un éditeur de texte générique codé en C++ et Python, disponible sur
Windows, Mac et Linux. Le logiciel a été conçu tout d'abord comme une extension
pour Vim, riche en fonctionnalités.
Depuis la version 2.0, sortie le 26 juin 2012, l'éditeur prend en charge 44 langages de
programmation majeurs, tandis que des plugins sont souvent disponibles pour les langages
plus rares.
WAMP est un acronyme informatique signifiant :
« Windows »« Apache »« MySQL »« PHP » dans la majorité des cas mais aussi
parfois, « Perl », ou « Python ».Il s'agit d'un néologisme basé sur LAMP.
Les rôles de ces quatre composants sont les suivants :
✓ Apache est le serveur web « frontal » : il est « devant » tous les autres et répond
directement aux requêtes du client web (navigateur) ;
✓ Le langage de script PHP sert la logique ;

✓ MySQL stocke toutes les données de l'application ;

✓ Windows assure l'attribution des ressources à ces trois composants.
I.5. Outils de développement de l’application
❖ HTML 5:
L’HyperText Markup Language, généralement abrégé HTML, est le format de
données conçu pour représenter les pages web. Il permet notamment d’implanter
de l’hypertexte dans le contenu des pages et repose sur un langage de balisage,
d’où son nom. HTML permet aussi de structurer sémantiquement et de mettre en
forme le contenu des pages, d’inclure des ressources multimédias dont des images, des
formulaires de saisie, et des éléments programmables tels que des applets. Il est souvent utilisé
113

128. Chapitre V : La phase closure
conjointement avec des langages de programmation (JavaScript) et des formats de
présentation (feuilles de cascade).
❖ CSS 3:
Le langage CSS (Cascading Style Sheets) est utilisé pour définir l'aspect futur de
votre application, comme par exemple la couleur du fond de la page ou le type de
la police.
Plus concrètement, le CSS (ou feuille de style), c'est un petit fichier (exemple "style.css")
dans lequel vous allez définir l'aspect futur de votre site.
❖ SVG :
Le Scalable Vector Graphics (en français « graphique vectoriel adaptable »), ou SVG, est
un format de données conçu pour décrire des ensembles de graphiques vectoriels et basé
sur XML. Ce format inspiré directement du VML et du PGML est spécifié par le
World Wide Web Consortium.
❖ JavaScript :
est un langage de programmation de scripts principalement employé dans les pages
web interactives mais aussi pour les serveurs. 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
prototypage qui permet d’en créer des objets héritiers personnalisés. En outre, les fonctions
sont des objets de première classe.
Le langage a été créé en 1995 par Brendan Eich (Brendan Eich étant membre du conseil
d'administration de la fondation Mozilla à cette époque) pour le compte de Netscape
Communications Corporation. Le langage, actuellement à la version 1.8.2, est une
implémentation de la 3e version de la norme ECMA-262 qui intègre également des éléments
114

129. Chapitre V : La phase closure
inspirés du langage Python. La version 1.8.5 du langage est prévue pour intégrer la 5éme
version
du standard ECMA.
❖ C# :
est un langage de programmation orienté objet à typage fort,
créé par la société Microsoft, et notamment un de ses employés,
Anders Hejlsberg, le créateur du langage Delphi.
Il a été créé afin que la plate-forme Microsoft .NET soit dotée d'un langage permettant
d'utiliser toutes ses capacités. Il est très proche du Java dont il reprend la syntaxe générale ainsi
que les concepts (la syntaxe reste cependant relativement semblable à celle de langages tels que
le C++ et le C). Un ajout notable au C est la possibilité de surcharge des opérateurs, inspirée
du C++. Toutefois, l'implémentation de la redéfinition est plus proche de celle du Pascal Objet.
❖ Web Socket
C’est un standard du Web dont la spécification est en cours de
définition désignant un protocole réseau de la couche application et
une interface de programmation du World Wide Web. Le protocole
a été normalisé par l'IETF dans la RFC 6455 et l'interface de
programmation est en cours de standardisation par le W3C.
❖ 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 des pages web. La
première version est lancée en janvier 2006 par John Resig.
La bibliothèque contient notamment les fonctionnalités suivantes :
- Parcours et modification du Document Object Model (DOM) (y compris le
support des sélecteurs CSS 1 à 3 et un support basique de XPath);
-Événements;

130. 115

131. Chapitre V : La phase closure
- Effets visuels et animations;
- Manipulations des feuilles de style en cascade (ajout/suppression des classes, d’attributs...);
- Ajax;
- Plugins;
- Utilitaires (version du navigateur web...) [18].
❖ AJAX
Ajax permet de modifier partiellement la page affichée par le navigateur pour la mettre à jour
sans avoir à recharger la page entière. Par exemple le contenu d’un champ de formulaire peut
être changé, sans avoir à recharger la page avec les images, le
menu, etc. Ajax est une technique qui fait usage des éléments suivants :
- HTML pour l’interface.
- CSS pour la présentation de la page.
- JavaScript (Ecma Script) pour les traitements locaux, et DOM qui accède aux éléments de la
page ou du formulaire ou aux éléments d’un fichier XML chargé sur le serveur.
- L’objet XML http Request lit des données ou fichiers sur le serveur de façon asynchrone.
- PHP ou un autre langage de scripts peut être utilisé coté serveur [19].
❖ JSON :
(JavaScript Object Notation) est un format de données textuelles, générique, dérivées
de la notation des objets du langage ECMA Script. Il permet de représenter de
l’information structurée. Créé par Douglas Crock ford.
Un document JSON ne comprend que deux éléments structurels :
▪ des ensembles de paires nom / valeur ;
116

132. Chapitre V : La phase closure
▪ des listes ordonnées de valeurs.
Ces mêmes éléments représentent 3 types de données :
▪ des objets ;

▪ des tableaux ;

▪ des valeurs génériques de type tableau, objet, booléen, nombre, chaîne ou null.
I.6. Outils de conception
❖ Visual Paradigm for UML
comme son nom le laisse supposer, un logiciel permettant aux programmeurs de mettre
en place des diagrammes UML. Disposant d'un outil créant des rapports personnalisables aux
formats PDF, Word ou HTML afin de les partager
et les publier sur Internet, cette application est compatible avec de nombreuses applications,
standards et environnements. Ainsi, vous pourrez générer notamment des diagrammes de
séquences ou de cas d'utilisation et ainsi produire du code source dans de nombreux langages
comme le Java ou encore le C++, ou bien faire l'inverse, générer des diagrammes à partir de
code déjà existant.
I.7. Outils de traitement et de présentation
❖ Microsoft Office 2013
Microsoft Office 2013 est la dernière version de Microsoft Office, suite de bureautique
conçue pour Windows. C'est, avec Microsoft Office 365, le successeur de Microsoft Office
2010. Elle propose des nouveautés comme une ergonomie simplifiée avec la prise en charge
optimisée des interfaces tactiles, et une plus grande
117

133. Chapitre V : La phase closure
compatibilité avec tout type de document dont Portable Document Format (PDF) qui peut
désormais s'ouvrir et être modifié directement dans Word 2013.
II.Mesure d’optimisation de niveau technique
a) Architecture modèle/vue/contrôleur
L'organisation globale d'une interface graphique est souvent délicate. Cette architecture
fournit souvent une première approche qui peut ensuite être adaptée. Comme elle offre aussi
un cadre pour structurer une application. Ce patron d'architecture impose la séparation entre
les données, la présentation et les traitements, ce qui donne trois parties fondamentales dans
l'application finale comme le représente la figure suivante (figure 43).
Figure 43: Représentation du modèle MVC et les relations entre les trois parties
Le modèle
Le modèle représente le comportement de l'application : traitements des données,
interactions avec la base de données, etc. Il décrit ou contient les données manipulées par
l'application. Il assure la gestion de ces données et garantit leur intégrité. Dans le cas typique
d'une base de données, c'est le modèle qui la contient. Le modèle offre des méthodes pour mettre
118

134. Chapitre V : La phase closure
à jour ces données (insertion, suppression, changement de valeur). Il offre aussi des méthodes
pour récupérer ces données.
La vue
La vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche
est de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes
les actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons, etc.). Ces différents
événements sont envoyés au contrôleur.
Le contrôleur
Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre
à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l'utilisateur et
enclenche les actions à effectuer. Si une action nécessite un changement des données, le
contrôleur demande la modification des données au modèle, et ce dernier notifie la vue que les
données ont changée pour qu'elle se mette à jour.
▪ La présentation des données : correspondant à l'affichage et au dialogue avec
l'utilisateur à l’intermédiaire d’un navigateur gérer par un serveur web.
▪ Le traitement des données : correspondant à la mise en œuvre de l'ensemble des
règles de gestion et de la logique applicative à l’intermédiaire d’un serveur
d’application.
▪ L’accès aux données: correspondant aux données qui sont destinées à être
échangées à l’intermédiaire d’un serveur de données.
Dans l’architecture à trois niveaux, les applications au niveau serveur sont délocalisées
; c'est-à-dire que chaque serveur est destiné à faire des taches uniques pour garantir :
▪ Une grande flexibilité à la manipulation des données.

▪ Une sécurité accrue, car la sécurité peut être définie indépendamment pour chaque
service et à chaque niveau
119

135. Chapitre V : La phase closure
▪ De meilleures performances, étant donné le partage des tâches entre les
différents serveurs.

b) SVG et performance
L’un des principaux avantages de ce format et que l’on peut redimensionner une image
sans aucune perte de qualité contrairement à une image jpeg ou png par exemple. Ceci est dû
au fait que ces images soient vectorielles.
Afin de vous faciliter la tâche, certaines formes géométriques de base sont déjà gérées
telles que les rectangles ou les ellipses par exemple. Il est également possible d’obtenir
n’importe quelle forme à l’aide des paths qui sont des chemins et vous permettent de tracer ce
que vous souhaitez.
Les éléments dessinés au format SVG sont exportables afin d’être réimporter dans un
autre endroit du dessin SVG.
Enfin, aujourd’hui une très grande partie des navigateurs sont capables de gérer des
éléments au format SVG.
c) Justification de l’utilisation du Web Socket
WebSocket est une fonctionnalité supportée par l'ensemble des navigateurs récents.
Elle permet un échange bilatéral synchrone entre le client et le serveur.
120

136. Chapitre V : La phase closure
Figure 44: Architecture Client/Serveur REST
Habituellement, la communication est asynchrone : le client demande, le serveur répond.
C'était suffisant aux débuts du Web, mais c'est devenu trop limitant ces derniers temps.
On a besoin d'une communication plus réactive et immédiate. Dans ce schéma par exemple, le
serveur ne peut pas décider de lui-même d'envoyer quelque chose au client (par exemple pour
l'avertir "eh il y a un nouveau message !"). Il faut que le client recharge la page ou fasse une
action pour solliciter le serveur, car celui-ci n'a pas le droit de s'adresser au client tout seul.
WebSocket est une nouveauté du Web qui permet de laisser une sorte de "tuyau" de
communication ouvert entre le client et le serveur. Le navigateur et le serveur restent
connectés entre eux et peuvent s'échanger des messages dans un sens comme dans l'autre dans
ce tuyau. Désormais, le serveur peut donc lui-même décider d'envoyer un message au client
comme un grand.
Figure 45: Architecture Client/Serveur WebSocket
Avec les WebSocket, la communication est synchrone : un tuyau de communication
reste ouvert entre client et serveur.
Nous procédons par la suite à une étude comparative entre le Web Socket et le REST
comme il est indiqué dans le tableau 36.
121

137. Chapitre V : La phase closure
Tableau 36: Table de comparaison entre le Web Socket et le REST [13]
Nombre de REST (en fonction Web Socket (en Message/ms
messages ms) fonction ms)
10 17 13 1.31
100 112 20 5.60
500 529 55 7.75
1000 1050 115 9.13
5000 5183 522 9.93
10000 10547 1019 10.35
Web socket n’est donc pas une spécification des techniques de push sur HTTP (long
polling, HTTP Streaming, …), ni une surcouche à HTTP mais bien un protocole à part entière.
Il reste pourtant lié à HTTP en réutilisant l’architecture réseau de celui-ci. En effet,
l’ouverture d’une connexion Web socket s’effectue avec une requête HTTP qui demande au
serveur « de mettre à jour la connexion » en connexion Web socket comme il est indiqué dans
la figure 46.
122

138. Chapitre V : La phase closure
CLIENT (Navigateur) SERVEUR
Connexion TCP établis
HTTP (Requête + Réponse)
Handshake (HTTP upgrade)
Connexion ouverte
Communication Full Duplex
Connexion persistent
Fermeture du canal par un des hôtes
Connexion fermé
Connexion TCP fermé
Figure 46: Architecture Client/Serveur Web Socket
Le serveur, s’il supporte le protocole Web socket, peut ainsi terminer l’ouverture de la
connexion et la suite du dialogue entre le client et le serveur s’effectuera avec le protocole
Web socket.
d) La reconnaissance des gestes
L’analyse et l’interprétation des mouvements humains peuvent aussi être effectuées par
des primitives 3D (positions, angles articulatoires...) qui nécessitent un suivi 3D du corps
entier ou de quelque partie du corps selon les mouvements à interpréter.
Nous proposons de classer des gestes dynamiques à partir de la trajectoire 3D de la main.
La reconnaissance est effectuée par la mesure de la déformation temporelle dynamique. La
Déformation temporelle dynamique (DTW) est une technique de mesure de distance entre deux
séquences qui ont une variation temporelle (exécutées à une vitesse différente par exemple).
123

139. Chapitre V : La phase closure
Elle a été utilisée dans la reconnaissance de la parole et a été appliqué dans la reconnaissance
des gestes. Soient deux séries numériques temporelles U et V, de longueur respective n et m,
Avec :
U = u1, u2, ..., ui , ..., un (4)
V = v1, v2, ..., vj , ..., vm (5)
Pour aligner les deux séquences par la technique DTW nous calculons la
matrice (n sur m) avec le (i eme
, jeme
) élément de cette matrice contient la
distance d (ui,vj) entre les deux points ui et vj.
Dans notre cas, nous utilisons le Visual gesture bluider. C’est un outil qui
nous permet de décomposer des gestuelles sous forme de données qui pourront
être importé dans le SDK au runtime afin de détecter des gestuelles précise.
e) La détection des expressions et des accessoires
La notion d’émotion est très familière, nous avons tous la capacité de la définir.
Mais fournir aux ordinateurs la capacité d’interpréter ou de simuler les émotions peut
améliorer notre manière de communiquer avec les systèmes informatiques.
Kinect nous permet de détecter un certains types d’expressions et d’accessoires tel que :
Heureux,
Gauche / Droite oeil ouvert,
Gauche /Droite œil fermé,
En regardant au loin,
Lunettes.

140. 124

141. Chapitre V : La phase closure
III. Documentation
La documentation logicielle est un texte qui sera livré avec le logiciel en expliquant
comment ce dernier fonctionne et/ou comment il est implémenter. La documentation des
applications informatiques est une pratique primordiale pour s'assurer de l'évolution du
logiciel et la continuité du travail par la suite. Malgré que l’un des valeurs du manifeste agile :
un logiciel qui fonctionne plutôt que la documentation. Cela ne veut pas dire que la
documentation est négligée avec Scrum. Dans ce cadre, nous avons essayé tout au long de
notre travail de préparer la documentation nécessaire pour les futurs développeurs.
IV. Les interfaces de l’application
Dans ce paragraphe, nous présentons quelques interfaces de l’application réalisée.
a) Interface d’accueil
L’interface d’accueil est la première interface de notre application Web, avec laquelle
l’utilisateur peut accéder à notre application.
Au lancement de notre site, l’utilisateur peut consulter une petite démonstration et les
fonctionnalités principales de notre application. Comme il est indiqué dans la figure 47.
125

142. Chapitre V : La phase closure
Figure 47: Page d’accueil du notre site de simulation
a) Message Kinect
Le message de notre application, nous permet de savoir l’état actuel de notre console
Kinect et nous guide à résoudre le problème comme il est indiqué dans la figure 48.
Figure 48: Message qui improuve l’état du Kinect
b) L’interface de simulation
Figure 49: Le menu de simulation
Le menu de notre application
Web, nous permet d’accéder
aux différentes fonctionnalités
de l’application comme il est
indiqué dans la figure 49.
c) Les fonctionnalités de la maison
La rubrique « Ma Maison »nous permet de charger et changer l’image de la maison :
une image requise ou une image des maisons témoins.
126

143. Chapitre V : La phase closure
Figure 50: Les fonctionnalités de la maison
d) Les fonctionnalités de la catégorie« Forme »
Si l’utilisateur veut changer la forme de son porte il suffit de sélectionner le bouton
Frome pour consulter toute une bibliothèque de forme, cela est illustré dans la figure 51.
Figure 51: Les fonctionnalités de la catégorie« Forme »
e) Les fonctionnalités de la catégorie« Matériaux »
127

144. Chapitre V : La phase closure
Notre application offre 6 catégories de matériaux pour les portes d'entrée et une
multitude de combinaisons sont possibles entre elles en fonction de vos envies, de vos
goûtscomme ul est illustré dans la figure 52.
Figure 52: Les fonctionnalités de la catégorie « Matériaux »
Les fonctionnalités de la catégorie« Panneaux »
Cette rubrique dispose un vaste de choix panneaux qui permet au client de satisfaire
son besoin comme il est illustré dans la figure 53.
128

145. Chapitre V : La phase closure
Figure 53: Les fonctionnalités de la catégorie « Panneaux »
Les fonctionnalités de la catégorie « Couleurs »
Depuis la catégorie « Couleurs », l’utilisateur peut changer les couleurs de son porte
selon leur choix comme indiqué dans la figure 54.
Figure 54: Les fonctionnalités de la catégorie « Couleurs »
Les fonctionnalités de la catégorie « Vitrages »
La catégorie « Vitrages » nous permet de choisir le vitrage qui nous plaît selon nos
besoins esthétiques comme indiqué dans la figure 55.
129

146. Chapitre V : La phase closure
Figure 55: Les fonctionnalités de la catégorie « Vitrages »
L’interface « Accessoires » affiche tous les accessoires disponibles comme indiqué
dans la figure 56.
Figure 56: Les fonctionnalités de la catégorie « Accessoires »
Les fonctionnalités de la catégorie « Inclinaisons »
La rubrique « Inclinaisons » nous permet de créer des inclinaisons horizontale et
verticale pour adapter notre porte visée sur l’image requise. Comme il est illustré dans la
figure 57.
130

147. Chapitre V : La phase closure
Figure 57: Les fonctionnalités de la catégorie « Inclinaisons »
La rubrique « Vue intérieur » nous permet de simuler les portes à l’intérieur de la
maison. Comme il est illustré dans la figure 58.
Figure 58: Vue d’intérieur
La rubrique « Conseil Client en ligne » nous permet de contacter l’administrateur.
Comme il est illustré dans la figure 59.
131

148. Chapitre V : La phase closure
Figure 59: Conseil client en ligne
La rubrique « Enregistrement de la simulation » nous permet de recevoir un mail qui
contient des images de notre simulation. Comme il est illustré dans la figure 60.
Figure 60: Enregistrement de la simulation
Les scénarios de mode d’emploi du Kinect V2 :
L’utilisateur est non engagé :
Les deux mains sont baissées.
132

149. Chapitre V : La phase closure
Figure 61: utilisateur est non engagé « Capture IR)
L’utilisateur est engagé
Pour utiliser le Kinect V2 on à fixer un algorithme qui nous permet d’engager les
utilisateurs par la salutation par la main Gauche ou droite
133

150. Chapitre V : La phase closure
Figure 62: Engagement de l’utilisateur
Figure 63: Redimensionnement perspective de l’utilisateur
134

151. Chapitre V : La phase closure
Figure 64: La sélection d’un objet
Figure 65: Avancer la main pour cliquer
Figure 66: Redimensionnement verticale
135

152. Chapitre V : La phase closure
Figure 67: Redimensionnement horizentale
Figure 68: Redimensionnement responsive
Figure 69: Redimensionnement verticale
V. Apports et Evaluation
Ce projet a été une occasion pour étendre, développer et exercer nos compétences de
conception, d’analyse, d’organisation, de développement et même de rédaction, et pour cela
nous allons citer ce que nous avons appris toute au long de cette expérience.
V.1. Apports au niveau des connaissances technique :
La finalisation de ce projet nous a permis d’enrichir nos connaissances techniques à savoir :
✓ La façon d’exploiter l’information.
136

153. Chapitre V : La phase closure
✓ La manipulation des langages théoriques.

✓ L’application de nos connaissances théoriques en informatique et multimédias
sur des cas réels.
✓ L’amélioration des connaissances acquis tout au long de notre études
universitaires et les adapter aux besoins de la réalité quotidienne.
V.2. Apports au niveau de la conception et du développement :
La finalisation de ce projet nous a permis :
✓ De maitriser la méthodologie de conception et de développement de
système d’information «UML ».
✓ De découvrir l’efficacité de développement d’une application sur la base
d’une conception discutée.
✓ D’indiquer l’importance d’une documentation exacte et mise à jour dans la
conception et le développement d’une application informatique.
V.3. Apports au niveau social :
En plus des apports cites précédemment, nous avons eu la chance durant la réalisation
de notre application d’apprendre des apports au niveau social tel que :
✓ La patience et savoir comment gérer les et les surmontés.

✓ L’habilite de prendre l’information et l’exploiter.

✓ L’adaptation à l’environnement professionnel.
V.4. Bilan quantitatif :
Les principaux points qui ont contribué à la qualité de développement du notre
application sont :
137

154. Chapitre V : La phase closure
✓ Assurer un guidage et une assistance à chaque stade du site garantie grâce à
la bonne organisation et au respect de la notion d’ergonomie.
✓ Assurer une navigation et un usage simple.

✓ Assurer une convivialité, une attractivité dans la présentation du site.

✓ L’utilisation d’une méthodologie de conception et modélisation UML,
Le bilan quantitatif du logiciel peut être présenté par le recensement des différents
volumes réalisés durant la phase de réalisation.
V.6. Evaluation
Afin de pouvoir évaluer le travail que nous avons établi, nous proposons de présenter
aussi bien un bilan qualitatif pour apprécier les moyennes utilisées à l’élaboration de cette
application qu’un bilan quantitatif sur les différents volumes.
VI. Bilan quantitatif
Le bilan quantitatif du logiciel peut être présenté par le recensement des différents
volumes réalisés durant la phase de réalisation, et qui est illustré dans ce tableau (tableau 37) :
Tableau 37: Table de la représentation du bilan quantitatif
Nombre de Modèle 39
Nombre de classe 11
Nombre de vue 2
Nombre de contrôleur 1
Nombre de Template 2
138

155. Chapitre V : La phase closure
Les principaux points qui ont contribué à la qualité de développement de notre
application sont :
❖ Assurer pour les utilisateurs une authentification guidée

❖ Utiliser au maximum des commentaires à chaque partie du code source de notre
application pour assurer une convivialité, une simplicité d’usage pour les futurs
utilisateurs qui désirent exploiter et améliorer notre outil.
VII. Conclusion
Tout au long de ce chapitre nous avons essayé de présenter les différents travaux qui se
déroulent à la fin du cycle de développement Scrum. Nous avons présenté les outils de travail
que nous avons utilisé à savoir l’environnement de développement et celui de programmation.
Enfin, nous avons présenté les différentes interfaces de notre outil d’optimisation et préparé la
documentation nécessaire pour les futurs développeurs.
139

156. Conclusion et perspectives
Conclusion et perspectives
Notre projet de fin d’étude porte sur la conception et le développement d’une application qui
permet de kinnifier le web pour la société « SiFast ». C’est une occasion pertinente pour
concrétiser et améliorer nos connaissances informatiques que nous avons acquises pendant
nos études supérieures. Nous avons essayé d’ajouter des nouvelle techniques d’interactions
IHM en utilisant les gestes, cette solution a été développé au sein de cette société en se basant
sur le langage de modélisation UML qui nous a permis de comprendre les besoins, afin
d’aboutir une application facile à utiliser.
Nous avons commencé dans un premier lieu par comprendre le contexte général de notre
application et identifier les différentes exigences de notre futur système. Nous avons préparé
par la suite notre planning de travail en respectant les priorités de nos besoins suite à une
discussion entre l’équipe du développement et le directeur du produit. Lors de notre cycle de
développement nous avons implémenté la méthodologie Scrum.
Malgré toutes les difficultés rencontrées au niveau de la recherche, manque du
documentation et les contraintes de temps, nous avons réussi à réaliser la totalité de notre
application tout en respectant l’aspect sécuritaire.
Comme perspective de ce travail, nous proposons d’améliorer notre application en
créant un Framework générique c.-à-d. une application qui peut être utilisé dans plusieurs
domaine tel que les borne interactive à base des émotions qui permette de présenter un type de
publicité ciblé.
En plus cette solution peut être implémentée au niveau des robots pour avoir la
possibilité de les télécommander sans fil en utilisant les gestes et le mouvement du corps
Enfin, nous voyons que ce projet de fin d’études a permis d’enrichir notre expérience et
de renforcer nos chances de succès dans notre carrière professionnelle.
140

157. Annexe A
Annexe A
I. Présentation
Le développement ou la méthode Agile, appelé aussi développement adaptatif, se
caractérise par un style de conduite de projet itératif incrémental, centré sur
l'autonomie des ressources humaines impliquées dans la spécification, la production et la
validation d'une application intégrée et testée en continu.
Plutôt que :
Figure 70: Processus actuel de développement
On fait :
Figure 71: Processus Agile
Le Manifeste Agile (Les 12 principes de la méthode agile) est considéré comme la définition
canonique du développement agile. Il se compose de quatre valeurs et 12 principes. [11]
141

158. Annexe A
II.Les 4 valeurs du Manifeste Agile
1-Individus et échanges plus que processus et outils.
2-Produit fonctionnel plus que documentation pléthorique.
3-Collaboration du client plus que négociation du contrat.
4-Réactivité au changement plus que suivi d'un plan.
III. Les 12 principes du Manifeste Agile
1-Notre priorité première est de satisfaire le client en livrant au plus tôt et de manière
constante un logiciel de qualité.
2-Tout changement, même tardif, des exigences pendant le développement est bienvenu. Les
méthodes Agiles transforment le changement en avantage compétitif pour le client.
3-Livrer régulièrement un logiciel fonctionnel, toutes les deux semaines à deux mois, en
référant la plus petite périodicité.
4-Maitrise d'ouvrage et développeurs doivent collaborer quotidiennement tout au long du
projet.
5-Bâtir le projet avec des personnes motivées. Leur donner l'environnement et le soutien dont
elles ont besoin et croire en leur capacité à accomplir le travail.
6-La plus efficace des méthodes pour transmettre l'information au sein et à destination d'une
équipe est le face à face.
7-Un logiciel qui fonctionne est le meilleur indicateur de progrès.
8-Les méthodes Agiles favorisent un rythme de développement soutenable. Commanditaires,
développeurs et utilisateurs devraient pouvoir maintenir ce rythme indéfiniment.
9-Une attention constante à l'excellence technique et à la qualité de la conception améliore
l'agilité.
10-La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
11-Les meilleures architectures, spécifications et conceptions sont issues d'équipes auto-
organisées.
12-À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis modifie
et ajuste son comportement dans ce sens.
142

159. Annexe B
Annexe B
I. Dictionnaire apuré des données
Tableau 38: Table dictionnaire apuré des données pour le Release 1 Sprint 1
Lettre Numéro Code Désignation
A 01 Adresse_code_postal L’adresse du notre client ou
notre fournisseur ainsi, le code
postale de cette région.
02 Adresse_IP_Client C’est l’adresse IP ou
l’identifiant de la connexion
pour notre client qui permet par
la suite le Tracking.
03 Adresse_Nro C’est l’identifiant du notre
habitat.
04 Adresse_Pays Le nom de notre pays.
05 Adresse_Rue L’adresse de la rue de l’habitat.
06 Adresse_Ville C’est l’adresse de la ville.
07 attribute_min_Element
B 08 Brillance_Picture C’est une valeur qui indique la
brillance de l’image.
C 09 Civilité_Contart C’est le type du contrat avec le
distributeur.
10 CodeSiret_Distributeur C’est le code fiscal du
distributeur.
143

160. Annexe B
11 Contact_Client La date de la dernière
localisation effectuée par
l’utilisateur
12 description_Gamme C’est une description textuelle
pour la gamme des produits.
13 Description_Picture Une description textuelle pour
l’image pour l’indexer par la
suite.
14 Email_Client L’adresse mail du notre client.
15 Email_Distributeur L’adresse mail du notre
distributeur.
G 16 Géolocalisation_Client un procédé permettant de
positionner un client.
H 17 HauteurMax C’est la hauteur maximum de
la forme.
18 HauteurMax_Imposte C’est la hauteur maximum
d’Imposte.
19 HauteurMax_Vantail C’est la hauteur maximum du
ventail.
20 HauteurMin_Cadre C’est la hauteur minimum du
cadre.
21 HauteurMin_Imposte C’est la hauteur minimum de
l’imposte.
22 HauteurMin_Vantail C’est la hauteur minimum du
ventail.
I 23 id_Accessoire L’identifiant de l’accessoire.
24 id_Adresse L’identifiant de l’adresse.
25 id_Cadre L’identifiant du cadre
144

161. Annexe B
26 id_Chasis L’identifiant du châssis
27 Id_Client L’identifiant du client
28 id_Contart L’identifiant du contrat.
29 Id_Couleur L’identifiant du couleur.
30 id_Distributeur L’identifiant du distributeur.
31 id_Element L’identifiant d’élément.
32 id_Forme L’identifiant de la forme.
33 id_Gamme L’identifiant de la gamme
34 id_Imposte L’identifiant de l’imposte.
35 id_Materieau L’identifiant du matériau.
36 Id_Navigateur L’identifiant du navigateur
37 id_picture L’identifiant d’une image
38 id_Sèrigraphie L’identifiant de la sérigraphie.
39 id_Simulation L’identifiant de la simulation.
40 id_Type_Accessoire L’identifiant du type
d’accessoires.
41 id_Vantail L’identifiant du ventail.
42 id_vitrage L’identifiant du vitrage.
43 id_vue L’identifiant du vue.
44 IntansitéR_Couleur L’intensité du couleur rouge
45 IntensitéB_Couleur L’intensité du couleur bleu
46 IntensitéV_Couleur L’intensité du couleur vert
L 47 Largeur_Choisi_Element C’est la largeur désirée par le
client.
48 Largeur_Element C’est la largeur par défaut d’un
élément.
145

162. Annexe B
49 Largeur_Picture C’est la largeur d’une image.
50 Latitude C’est une coordonnée
géographique représentée par
une valeur angulaire,
expression de la position d'un
point sur Terre.
51 Libéle_Element C’est l’intitulé d’un élément.
52 Libellè_Accessoire C’est l’intitulé d’un accessoire.
53 Libellè_Couleur C’est l’intitulé d’un couleur.
54 Libellé_Forme C’est l’intitulé d’une forme.
55 libéllé_Gamme C’est l’intitulé d’une gamme.
56 libelle_Materieau C’est l’intitulé d’un matériau.
57 Libellé_Sèrigraphie C’est l’intitulé d’un
Sérigraphie.
58 Libellé_Simulation C’est l’intitulé d’une
simulation.
59 Libellé_Type_Accessoire C’est l’intitulé d’un type
d’accessoire.
60 libelle_vitrage C’est l’intitulé d’un vitrage.
61 Longeur_Picture C’est la longueur de l’image
62 Longitude C’est une coordonnée
géographique représentée par
une valeur angulaire,
expression du positionnement
est-ouest d'un point sur Terre
63 Luminosité_Picture C’est une valeur qui présente la
quantité lumineuse de l’image.
N 64 Nom_Client La dénomination du client
146

163. Annexe B
P 65 Password_Client Mot de passe du notre client
66 Pays_Client C’est le pays de notre client
67 PositionX_Accessoire La position horizontale de
l’accessoires par rapport la
simulation.
68 PositionY_Accessoire La position Verticale de
l’accessoires par rapport la
simulation.
69 Prix_Element Le coût de cet élément.
70 Prix_Supp_Accessoire C’est un coût supplémentaire
de l’accessoire.
71 Prix_Supp_Couleur Un coût supplémentaire pour le
couleur.
72 PrixSupp_Sèrigraphie Un coût supplémentaire pour la
sérigraphie.
R 73 RaisonSociale_Distributeur C’est le raison sociale du notre
distributeur.
S 74 Sens_Ouverture_Vantail Il définit le sens d’ouveture de
la porte.
T 75 TelFixe_Client Définit le Numéro fixe du
client.
76 TelMob_Client Définit le Numéro mobile du
client.
77 Type_Navigateur C’est le type du navigateur.
78 type_vue Définit le type de simulation
soit interne soit externe.
U 79 Url_Image_Accessoire Il définit le path de l’image
d’accessoire.
147

164. Annexe B
80 UrlImage_Sèrigraphie Il définit le path de l’image
sérigraphie.
V 81 Version_Navigateur C’est la version du navigateur.
Tableau 39: Table dictionnaire apuré des données pour le Release 2 Sprint 1
Lettre Numéro Code Désignation
A 01 AudioSource Permet d’obtient la source
de trames audio
B
C
D
E
F
02 BodyFrameSource Obtient la source pour les
cadres du corps.
03 BodyIndexFrameSource Obtient la source pour les
cadres de l'indice de
corps.
04 ColorFrameSource Obtient la source pour les
cadres de couleur.
05 CoordinateMapper Obtient le mappeur de
coordonnées.
06 DepthFrameSource Obtient la source pour les
cadres de profondeur.
07 Engaged Obtient le statut de
l'engagement du corps
08 FacenRoll C’est le type du contrat
avec le distributeur.
09 FacePich C’est le code fiscal du
distributeur.
148

165. Annexe B
10 FaceYaw La date de la dernière
localisation effectuée par
l’utilisateur
H 11 HandLeftConfidence Obtient la confiance de
l'Etat de la main gauche
du corps.
12 HandLeftState Obtient le statut d'Etat la
main gauche du corps.
13 HandRightConfidence Obtient la confiance de
l'Etat de la main droite du
corps.
14 HandRightState Obtient le statut d'Etat la
main droite du corps.
15 Happy Détecte si l'utilisateur est
heureux
I 16 id_joints Obtient l’identificateur de
l’articulation
17 InfraredFrameSource Obtient la source pour les
cadres infrarouges
18 IsAvailable Obtient si le capteur
Kinect est disponible et en
mesure de récupérer les
cadres
19 IsOpen Obtient l’état du capteur
l'Kinect.
J 20 JointCount Obtient le nombre de
joints dans un corps.
149

166. Annexe B
21 JointType Définir le type de
l‘articulation.
K 22 KinectCapabilities obtient les capacités de
l'Kinect Sensor
L 23 LeanTrackingState Obtient l'état de suivi
pour le corps maigre.
24 LeftEyeClosed Détecte si les yeux sont
ouvert / fermé
25 LongExposureInfraredFrameSource Obtient la source pour
longtemps exposition
cadres infrarouges.
26 LookingAway Obtient si l’utilisateur
regarder loin de champ de
vision du Kinect.
M 27 MouthMoved Détecte si la bouche est en
mouvement
28 MouthOpen Détecte si la bouche est
ouverte / fermée
O 29 Orientation L'orientation de
l'articulation.
R 30 RightEyeClosed Détecte si les yeux sont
ouvert / fermé
T 31 TrackingId Obtient l'ID de suivi pour
le corps.
U 32 UniqueKinectId Obtient l’ID unique pour
le Kinect Sensor.
150

167. Annexe B
W 33 WearingGlasses Détecte si l’utilisateur
porte des Lunettes
X 34 X Obtient la position
horizontale de
l’articulation par rapport
au corps
Y 35 Y Obtient la position
verticale de l’articulation
par rapport au corps
Z 36 Z Obtient la profondeur de
l’articulation par rapport
la console Kinect.
151

168. Annexe C
Annexe C
La déduction du schéma relationnel se base sur deux règles qui sont présentées comme suit :
(ces règles sont extraites du livre [14]).
I. Règle 1 : transformation des entités/classes
Chaque classe du diagramme UML devient une relation. Il faut choisir un attribut de la classe
pouvant jouer le rôle d’identifiant.
Si aucun attribut ne convient en tant qu’identifiant, il faut en ajouter un de telle sorte que la
relation dispose d’une clé primaire (les outils proposent l’ajout de tels attributs).
Figure 72: Règle 1 du passage du modèle conceptuel vers le modèle logique
II. Règle 2 : transformation des associations :
Les règles de transformation des associations dépendent de leurs cardinalités maximale.
II.1. Association un à plusieurs :
Il faut ajouter un attribut de type clé étrangère dans la relation fils de l’association. L’attribut
porte le nom de la clé primaire de la relation père de l’association.
152

169. Annexe C
Figure 73: Règle 2 du passage du modèle conceptuel vers le modèle logique
II.2. Les associations plusieurs à plusieurs :
L’association (ou la classe classe-association) devient une relation dont la clé primaire est
composée par la concaténation des identifiants des classes connectés à l’association. Chaque
attribut devient clé étrangère si classe connectée dont il provient devient une relation en vertu
de la règle R1.
Les attributs de l’association (ou la classe-association) doivent être ajoutés à la nouvelle
relation. Ces attributs ne sont ni clé primaire, ni clé étrangère.
Figure 74: Règle 3 du passage du modèle conceptuel vers le modèle logique (premier cas)
II.3. Association un à un :
Il faut ajouter un attribut clé étrangère dans la relation dérivée de la classe ayant la multiplicité
minimale égale à un. L’attribut porte le nom de la clé primaire de la relation dérivée de
l’entité (classe) connectée à l’association.
Si les deux cardinalités (multiplicités) minimales sont à zéro, le choix est donné entre les deux
relations dérivées de la règle R1. Si les deux cardinalités minimales sont à un, il est sans doute
préférable de fusionner les deux entités (classes) en une seule.
153

170. Annexe C
Figure 75: Règle 3 du passage du modèle conceptuel vers le modèle logique (deuxième cas)
II.4. Transformation de l’héritage :
S’il existe une contrainte de totalité ou de partition sur l’association, il est possible de ne pas
traduire la relation issue de la surclasse. Il faut alors faire migrer tous ses attributs dans la(les)
relation(s) issue(s) de la (des) sous-classe(s).
Dans le cas contraire, il faut faire migrer tous ses attributs dans la ou les relation(s) issue(s)
de la (des) sous-classe(s) dans la (les) relation(s) issue(s) de la (des) sous-classe(s).
Figure 76: Règle 3 du passage du modèle conceptuel vers le modèle logique (troisième cas)
II.5. Transformation de la composition :
La clé primaire des relations déduites des classes composantes doit contenir l’identifiant de la
classe composite (quelles que soient les multiplicités).
Figure 77: Règle 3 du passage du modèle conceptuel vers le modèle logique (quatrième cas)
154

171. Bibliographie
Bibliographie
[1] SiFast, «SiFast,» [En ligne]. Available: http://www.sifast.com/.
[2] Akamai, [En ligne]. Available: http://www.akamai.fr/.
[3] Etienne Delagrave, «performance-web,» [En ligne]. Available:
http://www.adviso.ca/blog/2014/01/09/performance-web/]..
[4] AirXTouch, «AirXTouch,» [En ligne]. Available: http://www.inui-
studio.com/en/airxtouch/.
[5] wisee, «wisee,» [En ligne]. Available: http://wisee.cs.washington.edu/.
[6] zigfu, «zigfu,» [En ligne]. Available: http://zigfu.com/.
[7] C. Aubry, SCRUM le guide pratique de la méthode agile la plus populaire, Dunod,
2010.
[8] F. V. Pascal Roques, UML2 en action de l'analyse des besoins à la conception,
Paris: Eyrolles, 2007.
[9] C. Schillinger, Artist, Intégration web - Les bonnes pratiques. [Art]. 18 octobre 2012.
[10] serena, «intro-to-agile-devel,» [En ligne]. Available:
http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf.
[11] P. Roques, UML2 modéliser une application web, Eyrolles, 2008.
[12] Wiki, «Wiki,» [En ligne]. Available: http://fr.wikipedia.org/wiki/Jenkins_(logiciel).
[13] «REST WEBSOCKET,» [En ligne]. Available:
http://planet.jboss.org/post/rest_vs_websocket_comparison_and_benchmarks.
[14] C. Soutou, UML2 pour les bases de données, Eyrolles.
[15] 01 05 2013. [En ligne]. Available: http://dictionnaire.phpmyvisites.net/definition-
Release-9456.htm.
155

172. Bibliographie
[16] 26 05 2013. [En ligne]. Available: http://www.aubryconseil.com/post/2006/06/24/50-le-
dernier-sprint-d-une-release.
156