Rapport PFE réalisation d’un Framework Kinect

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

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.

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

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

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

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

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

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
formes » 50
panneaux » 51
couleurs » 52
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

✓ 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

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

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

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

▪ 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

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

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

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

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

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

➢ 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

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

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

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

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

➢ 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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

❖ 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

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

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

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.
Post-conditions Néant.
44

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.
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é.
h) Description textuelle du cas d’utilisation « Choisir la forme »
45

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.
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rapport PFE réalisation d’un Framework Kinect

Rapport PFE réalisation d’un Framework Kinect

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Rapport PFE réalisation d’un Framework Kinect

Similar a Rapport PFE réalisation d’un Framework Kinect (20)

Rapport PFE réalisation d’un Framework Kinect