rapport finalmise en place 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 Fadhel Abid

Le gérant de la société « SiFAST »

& 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

’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

L

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

Tabledesfigures

Figure 1: Mode d’emploi du Kinect ...................................................................................... 2

Figure 2: Logo de SIFAST .................................................................................................... 5

Figure 3: Les secteurs d'activité du SiFast ............................................................................. 6

Figure 4: Organigramme de la société SiFast ........................................................................ 7

Figure 5: Schéma démonstratif des différents éléments d'une porte .................................... 9

Figure 6: Schéma général de nombre d’internautes dans le monde..................................... 13

Figure 7: Schéma simplifié de la méthode d’interaction actuel ........................................... 15

Figure 8: Schéma de la solution choisi ................................................................................ 18

Figure 9: Le processus Scrum .............................................................................................. 21

Figure 10: Diagramme de contexte statique ...................................................................... 25

Figure 11: Équipe Scrum ................................................................................................... 29

Figure 12: Diagramme des cas d’utilisation global ........................................................... 33

Figure 13: architecture Client/serveur ............................................................................... 34

Figure 14: Représentation de l’architecture 1 tiers ............................................................ 35

Figure 15: Représentation de l’architecture N tiers ........................................................... 36

Figure 16: Plan du release .................................................................................................. 37

Figure 17: Diagramme de cas d’utilisation Front Office ................................................... 40

Figure 18: Diagramme de séquence détaillé du cas d’utilisation « création de la simulation » 48

Figure 19: Diagramme de séquence détaillé du cas d’utilisation « modification des matériaux » 49

Figure 20: Diagramme de séquence détaillé du cas d’utilisation « modification des formes » 50

Figure 21: Diagramme de séquence détaillé du cas d’utilisation « modification des panneaux » 51

Figure 22: Diagramme de séquence détaillé du cas d’utilisation « modification des couleurs » 52

Figure 23: Diagramme de séquence détaillé du cas d’utilisation « modification des vitrages » 53

Figure 24: Diagramme de séquence détaillé du cas d’utilisation « changement d’image » 54

Figure 25: Diagramme de séquence détaillé du cas d’utilisation « changement des accessoires » 55

Figure 26: Représentation des classes ............................................................................... 69

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

ListedestableauxTableau 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

1


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

1Composite2Une Entreprise de Services du Numérique3 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 »


2

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


3

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.

CHAPITRE I : ETUDE PREALABLE

4

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.


5

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 5et ISO 9001 6et 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

5Livre CMMI par l'exemple écrit par François Dufay sorti en 2010 6Livre Dix clés pour réussir sa certification ISO 9001 écrit par Claude Pinet sorti en 2009


6

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


7

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


8

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


9

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

Le châssisComposé d'un dormant et d'un ouvrant, il est l'armature de la porte.

Il supporte les autres éléments le composant : panneau, vitrage, ferrage

(quincaillerie), joints et seuil.

Le

panneau

Il habille la porte et apporte une touche esthétique à celle-ci en fonction

des moulures et des finitions choisies.

Il a également un rôle important dans la résistance à l'effraction et

l'isolation.


10

Le vitrageSource de lumière, il offre de multiples possibilités esthétiques. Il joue

un rôle non négligeable en matière d'isolation et de résistance à

l'effraction.

Le ferrageIl comporte tous les éléments qui assurent les mouvements de l'ouvrant

et le verrouillage/déverrouillage de la porte. Il a une très forte incidence

sur la résistance à l'effraction.

Les

paumelles

Support de l'ouvrant, elles sont des pièces importantes. Chez Monsieur

Store, nous avons fait le choix de paumelles lourdes qui assurent une

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.

Le seuilde conception basique, en métal, il est souvent le point faible des portes

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


11

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)


12

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


13

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 :


14

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.


15

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.


16

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.

17Tactile18 Capable de suivre les mains et les doigts ou les outils similaires de l’utilisateur


17

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 à


18

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.


19

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

19Unified Modeling Language


20

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


21

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.


22

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.

Chapitre II : Planification et architecture

23

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.


24

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.


25

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),


26

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.


27

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.


28

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


29

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


30

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.


31

Tableau 6: Backlog produit

Nom Effort Rang Description Thème23 Risque Priorité

La récupération des données.

1 1 La récupération des informations sous format JSON en utilisant les Web Services REST.

Réalisation d’une application de simulation

Faible Élevé

La manipulation de SVG 2 2 Consiste de reconstruire une image SVG avec des formules mathématiques


Faible Élevé

L’utilisation des plugins Raphael.JS et Fabric.JS et SnapSVG.JS

1 3 Permet la reconstruction et la manipulation de la plateforme de simulation d’une manière dynamique.


Moyen Élevé

Nom Effort Rang Description Thème Risque Priorité

La récupération des informations depuis un dispositif Kinect

2 4 Permet de parcourir la liste des personnes et de sélectionner l’un des utilisateurs engagés puis la récupération de toute information relative à ce

Réalisation d’un Framework Kinect

Moyen Élevé

23 Thème : c’est la traduction du mot « features » selon Claude Aubry


32

dernier en utilisant la plateforme .Net.

La transmission des données à travers la technologie du Web Socket

2 5 Consiste de stocker les informations d’utilisateur engagé dans un vecteur ensuite les transformer sous format JSON et enfin les envoyer au niveau du Web Socket


Moyen Élevé

La récupération des données au niveau des Navigateurs

1 6 Permet de récupérer les informations transmis au niveau du Web Socket.


Moyen Élevé

La définitions des interactions au niveau du JavaScript

1 7 L’implémentation d’un Script qui nous permet le Click, le déplacement du curseur.


Moyen Élevé

La définition des gestes 1 8 Permet la reconnaissance d’un certain type de geste au niveau de l’application.


Moyen Élevé


33

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


34

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


35

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


36

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.

24Backlog du sprint : c’est l’ensemble des user story inclus dans le sprint


37

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.

Chapitre III : La réalisation d’une application de simulation

38

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.


39

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


40

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


41

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.


42

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.


43

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


44

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.


45

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 »


46

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.


47


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.


48

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.


49

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.


50

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.


51

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


52

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


53

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 »


54

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 »


55

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.


56

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


57

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


58

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


59

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


60

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


61

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

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

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)


62

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


63

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


64

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


65

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


66

Libellè_Accessoire

Url_Image_Accessoire

PositionX_Accessoire

PositionY_Accessoire

Prix_Supp_Accessoire

17 Picture_Maison id_picture

Description_Picture

Luminosité_Picture

Brillance_Picture

Largeur_Picture

Longeur_Picture

18 Simulation id_Simulation

Libellé_Simulation

19 Adresse id_Adresse

Adresse_Rue

Adresse_Nro

Adresse_Ville

Adresse_code_postal


67

Adresse_Pays

Latitude

Longitude

20 Navigateur Id_Navigateur

Type_Navigateur

Version_Navigateur

21 Client Id_Client

Adresse_IP_Client

Pays_Client

Nom_Client

Contact_Client

Email_Client

Password_Client

Géolocalisation_Client

TelFixe_Client

TelMob_Client

I.3.3. Représentation des méthodes


68

Tableau 21: représentation des méthodes/classes

Nom de la Classe Numéro Méthodes

Forme 01 Forme ()

02 Récupérer Elements ()

03 Récupérer Matériau ()

04 Récupérer Gamme ()

05 Simulation () Simulation 06 Récupérer Forme ()

07 Récupérer Vue_Maison ()

I.3.4. Présentation du diagramme de classe Les diagrammes de classes expriment la structure statique du système, en termes de classes et

de relations entre ces classes.

Un diagramme de classes n’exprime rien de particulier sur les liens d’un objet donné, mais

décrit de manière abstraite les liens potentiels d’un objet vers d’autres objets.


69

Figure 26: Représentation des classes


70

I.4. Transformation en modèle relationnel

Les travaux menés dans cette activité se résument tout simplement dans

l’implémentation et la réalisation des histoires utilisateurs analysés lors des étapes précédentes.

Pour notre cas, nous nous intéresserons seulement au schéma de la base de données.

Pour construire le schéma de base de données de notre application, nous devons

appliquer certaines règles pour passer d’un schéma entité association (diagramme de classe)

vers un schéma relationnel. Ces règles sont bien définies dans l’annexe B.

Dans ce qui suit, nous présentons les tables de notre base de données, tout en tenant

compte du type et des contraintes de leurs champs.

Tableau 22: Liste des tables du modèle relationnel

Numéro Nom de la Table Attributs TYPE Contraintes

01 Distributeur id_Distributeur integer PRIMARY KEY

RaisonSociale_Distributeur char UNIQUE

CodeSiret_Distributeur char UNIQUE

Email_Distributeur char UNIQUE

02 Contrat id_Contart integer PRIMARY KEY

Civilité_Contart char ---

03 Adresse id_Adresse integer PRIMARY KEY

Adresse_Rue char ---

Adresse_Nro char ---


71

Adresse_Ville char ---

Adresse_code_postal integer ---

Adresse_Pays char ---

Latitude float ---

Longitude float ---

ClientId_Client integer FOREIGN KEY

04 Client Id_Client integer PRIMARY KEY

Adresse_IP_Client char ---

Pays_Client char ---

Nom_Client char ---

Contact_Client char ---

Email_Client char UNIQUE

Password_Client char ---

Géolocalisation_Client char ---

TelFixe_Client char UNIQUE

05 Simulation id_Simulation integer PRIMARY KEY

Libellé_Simulation char ---

Vue_maisonid_vue integer FOREIGN KEY


72


Formeid_Forme integer FOREIGN KEY

06 Navigateur Id_Navigateur integer PRIMARY KEY

Type_Navigateur char ---

Version_Navigateur char ---


07 Vue_maison id_vue integer PRIMARY KEY

type_vue char ---

Picture_Maisonid_picture integer ---

08 Picture_Maison id_picture integer PRIMARY KEY

Description_Picture char ---

Luminosité_Picture float ---

Brillance_Picture float ---

Largeur_Picture float ---

Longeur_Picture float ---

09 Forme id_Forme Integer PRIMARY KEY

Libellé_Forme Char ---

10 Ventail id_Element integer PRIMARY KEY


73

Libéle_Ventail Char ---

Largeur_Ventail Float ---

Hauteur_min_Ventail Float ---

Largeur_Choisi_Ventail Float ---

Prix_Element Float ---

Vitrageid_vitrage integer FOREIGN KEY

CouleurId_Couleur integer FOREIGN KEY

11 Element_Forme Elementid_Element integer PRIMARY KEY

Formeid_Forme integer PRIMARY KEY

12 Gamme id_Gamme integer PRIMARY KEY

libéllé_Gamme Char ---

description_Gamme Char ---

Materiauid_Materieau integer FOREIGN KEY

113 Materiau id_Materieau integer PRIMARY KEY

libelle_Materieau Char ---

14 Element_Gamme Elementid_Element integer PRIMARY KEY

Gammeid_Gamme integer PRIMARY KEY

15 Cadre id_Cadre integer PRIMARY KEY


74

Libéle_cadre Char ---

Largeur_cadre Float ---

Largeur_Choisi_cadre Float ---

Prix_cadre Float ---

HauteurMin_Cadre Float ---

HauteurMax Float ---

16 Cadre_Gamme Cadreid_Cadre integer PRIMARY KEY


17 Imposte id_imposte integer PRIMARY KEY

Libéle_imposte Char ---

Largeur_imposte Float ---

hoteur_min_imposte Float ---

Largeur_Choisi_imposte Float ---

Prix_imposte Float ---

HauteurMax_Imposte Float ---

HauteurMin_Imposte Float ---


18 Imposte_Gamme Imposteid_imposte integer PRIMARY KEY


75


19 Accessoires id_Accessoire integer PRIMARY KEY

Libellè_Accessoire Char ---

Url_Image_Accessoire Char ---

PositionX_Accessoire integer ---

PositionY_Accessoire integer ---

Prix_Supp_Accessoire Float ---

Type Accessoiresid_Type_Accessoire

integer ---

20 Type Accessoires id_Type_Accessoire integer PRIMARY KEY

Libellé_Type_Accessoire char PRIMARY KEY

21 Gamme_Accessoires Gammeid_Gamme integer PRIMARY KEY

Accessoiresid_Accessoire integer PRIMARY KEY

22 Vitrage id_vitrage integer PRIMARY KEY

libelle_vitrage char ---

Sérigraphieid_Sèrigraphie integer FOREIGN KEY

23 Sérigraphie id_Sèrigraphie integer PRIMARY KEY

Libellé_Sèrigraphie char ---


76

UrlImage_Sèrigraphie char ---

PrixSupp_Sèrigraphie float ---

24 Chasis id_chasis integer PRIMARY KEY

Libéle_chassis char ---

Largeur_chassis float ---

attribute_min_chassis float ---

Largeur_Choisi_chassis float ---

Prix_chassis float ---


25 Chasis_Gamme Chasisid_chasis integer PRIMARY KEY


26 Couleur Id_Couleur integer PRIMARY KEY

Libellè_Couleur char ---

IntansitéR_Couleur integer ---

IntensitéV_Couleur integer ---

IntensitéB_Couleur integer ---

Prix_Supp_Couleur float ---


77

Figure 27: Représentation du Modelé relationnel


78

I.5. Test

Le test est un processus manuel ou automatique, qui vise à établir qu’un système vérifie

les propriétés exigées par sa spécification, ou à détecter des différences entre les résultats

engendrés par le système et ceux qui sont attendus par la spécification. (Définition issue de la

norme IEEE-STD729, 1983).

Les activités de test constituent un axe très important dans le cycle de développement

d’un logiciel. Ils permettent de détecter les erreurs afin de les corriger et d’assurer la qualité du

logiciel fourni.

Contrairement aux cycles de développement séquentiel25, avec la méthodologie agile, le

test n'est pas une phase qui se déroule après la fin de développement. En effet, les tests seront

intégrés dès le début du premier sprint jusqu’à la livraison du produit final. En outre, la qualité

du logiciel n’est pas négligeable, c’est dans ce cadre que Scrum doit être complété par les

bonnes pratiques d’ingénierie techniques du logiciel. Parmi ces pratiques26, seulement deux qui

nous intéressent et qui sont le pilotage par les tests (TDD, Test Driven Developement) centrés

sur les tests unitaires, et le pilotage par les tests d’acceptation (ATDD, Acceptance Test Driven

Development).

I.5.1. Les tests unitaires

Le principe de cette pratique est d’écrire les tests avant même d’écrire le code et de

profiter par la suite de l’existence des tests automatiques pour l’amélioration et le remaniement

du code. Cette technique permet aux programmeurs de rester simples au niveau du code et de

s’assurer de son bon fonctionnement après des changements.

25 Ce sont les méthodologies dont les activités de développement (spécification, conception, codage et test) se déroulent séquentiellement notamment le modèle en cascade ou en V. (Nommage de Claude Aubry) 26 Les pratiques les plus connues sont : l’intégration continue, la programmation en binôme, etc.


79

Dans ce paragraphe, nous avons choisi de tester les histoires utilisateurs qui sont : La

manipulation de SVG, L’utilisation des plugins Raphael.JS et Fabric.JS et SnapSVG.JS. Pour

la création des tests unitaires de ces histoires, nous avons eu recours à un outil open source

d'intégration continue Jenkins [12].

Figure 28: Exemple de capture d’écran de l’outil de test « Jenkins »

II. Conclusion

Le résultat d’un release est un produit livrable au client contrairement au résultat d’un

sprint qui est un produit potentiellement livrable. A la fin de ce chapitre, nous avons réussi à

produire un incrément ayant suffisamment de valeur pour le client et pourra être utilisé dans un

environnement de production.

Dans le chapitre qui suit, notre effort sera consacré pour produire un nouveau release

couvrant les fonctionnalités de kinnifier le web.

Chapitre IV : Réalisation d’un Framework Kinect

80

Chapitre 4: Release 2 : Réalisation d’un

Framework Kinect

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


81

I. Le premier sprint

En partant sur le même principe que les sprints précédents, nous commençons par définir

le but de notre premier sprint pour ce release. Suite à une conversation entre le Product Owner

et l’équipe Scrum, nous avons décidé le but suivant : « la conception et la développement d’une

application .Net qui permet de kinnifier le Web».


inclure dans ce dernier. Le Tableau 23 résume donc le backlog de notre premier sprint :

Tableau 23: Backlog du premier sprint (release 2)


La récupération des informations depuis un dispositif Kinect

15

La transmission des données à travers la technologie du Web Socket

2

La récupération des données au niveau des Navigateurs

12

I.1. Spécifications fonctionnelles

La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas

d’utilisation d’UML et la description textuelle de ces derniers.

I.1.1. Diagramme des cas d’utilisation

Dans la figure 29 nous illustrons le diagramme des cas d’utilisation globaux pour ce

premier sprint.

En respectant toujours le même principe que les sprints précédents, nous avons découpé

certaines histoires utilisateurs en un ensemble de tâches.


82

Figure 29: Diagramme des cas d'utilisation du premier sprint (release 2)


83

I.1.2. Description textuelle des cas d’utilisation

Nous allons maintenant décrire chacun des cas d'utilisations énuméré dans le paragraphe

précédent en identifiants les acteurs et les différents scénarios possible.

a) Description textuelle du cas d’utilisation « Déplacer le curseur»

Tableau 24: Description textuelle du cas d'utilisation « Déplacer le curseur »

Description

Titre Déplacer le curseur

Acteurs Utilisateur

But Permet la navigation dans au niveau des navigateurs en

utilisant l’une des mains.

Pré-condition Si la connexion est détectée, un dispositif Kinect est installé

correctement, le plugin de Kinect server est lancé et

l’utilisateur est engagé.

Scénario nominal L’utilisateur va interagit avec l’application web par le

déplacement de l’un de ses mains dans les différents sens.

L’application tient à changer l’emplacement du curseur en

fonction de la main active.


Exceptions Néant.


b) Description textuelle du cas d’utilisation « engager»

Tableau 25: Description textuelle du cas d'utilisation « engager »

Description

Titre Engager


84

Acteurs Utilisateur

But Demande l’interaction avec la console Kinect.


correctement, le plugin de Kinect server est lancé.

Scénario nominal L’utilisateur commence de se positionner devant la console

Kinect.

L’application récupère la liste de tous les utilisateurs suivis.

L’utilisateur lève l’une de ses mains pour exprimer qu’il

veut s’engager à la simulation.

L’application vérifie la liste des conditions minimales et

récupère les informations relatives à cet utilisateur.


Exceptions Néant.


I.2. Conception

Dans cette section nous commençons par le diagramme de séquence système des

différents cas d’utilisation déjà détaillés dans la section précédente.

I.2.1. Diagramme de séquence système

En nous référant aux descriptions textuelles dans la section précédente, nous présentons

les diagrammes de séquences systèmes adéquats.

La figure n°30 illustre les tâches de déplacement du curseur. Dans ce diagramme,

l’utilisateur peut déplacer le curseur dans les différents sens.


85

Figure 30: Diagramme de séquence système du cas d'utilisation "engager un utilisateur "

I.2.2. Diagramme de séquence système

En se basant sur la description textuelle des cas d’utilisation, nous modélisons donc le

diagramme de séquence détaillé de ces derniers.


86

A. Diagramme de séquence détaillé du cas d’utilisation « engager avec l’utilisateur »

Figure 31: Diagramme de séquence détaillé du cas d'utilisation "engager avec l’utilisateur "

La figure n°31 illustre les tâches pour l’engagement d’un utilisateur. Dans ce diagramme, l’utilisateur peut par la suite interagir librement

avec le dispositif Kinect.


87

B. Diagramme de séquence détaillé du cas d’utilisation « Déplacer le Curseur»

Figure 32: Diagramme de séquence détaillé du cas d'utilisation "Déplacer le Curseur"

La figure n°32 illustre les tâches minimales pour le déplacement d’un curseur. Dans ce diagramme, l’utilisateur peut déplacer le curseur au

sein de la page Web.


88

1.2.3. Diagramme de classe Tableau 26: Table liste des objets naturels

Numéro Classe Entités Propriétés

01 Kinect UniqueKinectId Public

AudioSource Private

BodyFrameSource Private

BodyIndexFrameSource Private

ColorFrameSource Private

CoordinateMapper Private

DepthFrameSource Private

InfraredFrameSource Private

IsAvailable Private

IsOpen Private

KinectCapabilities Private

LongExposureInfraredFrameSource Private

02 Body TrackingId Public

Engaged Private

HandLeftState Private

HandLeftConfidence Private


89

HandRightState Private

HandRightConfidence Private

JointCount Private

LeanTrackingState Private

03 Joints id_joints Public

X Private

Y Private

Z Private

04 JointsOrientations JointType Public

Orientation Private

05 Expression Happy Private

Engaged Private

WearingGlasses Private

LeftEyeClosed Private

RightEyeClosed Private

MouthOpen Private

MouthMoved Private

LookingAway Private


90

FaceYaw Private

FacePich Private

Tableau 27: Table de la représentation des associations

Numéro Association Classe Cardinalité

01 Engager Client 1.1

Kinect 1.1

02 Récupère Kinect 1.1

Body 1.1

03 Détecte Body 1.1

Joints 25.25

04 Suivi Body 1.1

JointsOrientations 25.25

05 Évaluer Expression 1.1

Body 1.1

I.2.3.1. Représentation des méthodes

Tableau 28: représentation des méthodes/classes

Nom de la Classe Numéro Méthodes

Kinect 01 Kinect ()

02 Close ()

03 GetDefault ()

04 Open ()

05 OpenMultiSourceFrameReader ()

Body 06 Body ()


91

07 Récupérer JointOrientations ()

08 Récupérer Joints ()

09 IsTracked ()

JointsOrientations 10 JointsOrientations ()

Joints 11 Joints ()

Expression 12 Expression ()

Tableau 29: Table de la représentation des classes

Numéro Classe Attributs

01 Kinect UniqueKinectId

AudioSource

BodyFrameSource

BodyIndexFrameSource

ColorFrameSource

CoordinateMapper

DepthFrameSource

InfraredFrameSource

IsAvailable

IsOpen

KinectCapabilities

LongExposureInfraredFrameSource


92

02 Body TrackingId

Engaged

HandLeftState

HandLeftConfidence

HandRightState

HandRightConfidence

JointCount

LeanTrackingState

03 Joints id_joints

X

Y

Z

04 JointsOrientations JointType

Orientation

05 Expression Happy

Engaged

WearingGlasses

LeftEyeClosed

RightEyeClosed


93

MouthOpen

MouthMoved

LookingAway

FaceYaw

FacePich

FacenRoll

Après tous le travail de spécification et de conception, nous pouvons maintenant

construire le nouvel incrément de notre diagramme des classes en ajoutant les différents

éléments (classes, associations, attributs, etc.) déduits à partir des activités précédente (Figure

33).

Clé du diagramme

1. Classes déduits à partir du sprint 1 du premier release

2. Classes déduits à partir du sprint 1 du second release


94

Figure 33: Diagramme de classe du premier sprint (release 2)


95

I.3. Test

En partant toujours du même principe que les sprints précédents, et en appliquant les

bonnes pratiques d’ingénierie logicielle inspirée de la méthodologie extrême programming

(XP), nous commençons par les tests unitaires de l’histoire utilisateur « modifier une unité

d’enseignement »

I.3.1. Test unitaire

Dans ce paragraphe, nous testons toujours nos histoires utilisateur en utilisant un outil

d'intégration continue Jenkins.

II.Le deuxième sprint

En partant sur le même principe que le sprint précédent, nous commençons par définir

le but de notre second sprint. Suite à une conversation entre le Product Owner et l’équipe Scrum,

nous avons décidé le but suivant : « terminer la partie qui concerne Kinnification du Web ».


inclure dans ce dernier. Le tableau 30 résume donc le backlog de notre second sprint :

Tableau 30: Backlog du second sprint (release 2)


La définition des interactions au niveau du JavaScript 15

La définition des gestes 10

Dans le tableau 30, nous pouvons constater que les histoires utilisateur « lister les

fonctions », « ajouter une fonction » et « modifier une fonction » ne figurent pas dans le backlog

de produit. En effet, notre backlog de produit initial ne couvre pas toutes les fonctionnalités

requises et c’est pour cette raison que nous aurons des nouvelles fonctionnalités au fur et mesure


96

de notre avancement. En plus, nous pouvons constater que les vélocités de nos histoires ont

changé par rapport à l’estimation initiale tout en gardant la même durée que le sprint précédent.

II.1. Spécifications fonctionnelles

Pour la spécification fonctionnelle de ce sprint, nous commençons par le diagramme des

cas d’utilisation.

II.1.1. Diagramme des cas d’utilisation

Dans la figure 34, nous illustrons le diagramme des cas d’utilisation global pour ce

second sprint.

En respectant toujours le même principe que le sprint précédent, nous avons découpé

certaines histoires utilisateurs en un ensemble de tâches.

Clé du diagramme

1. Cas d’utilisation déduits à partir du sprint 1 du deuxième release 2. Cas d’utilisation déduits à partir du sprint 2 du deuxième release


97

Figure 34: Diagramme des cas d'utilisation du second sprint (release 2)


98

II.1.2. Description textuelle des cas d’utilisation

Nous allons maintenant décrire chacun des cas d'utilisation énuméré dans le paragraphe

précédent en identifiants les acteurs et les différents scénarios possible.

a) Description textuelle du cas d’utilisation « Redimensionner la porte»

Tableau 31: Description textuelle du cas d'utilisation « Redimensionner la porte»

Description

Titre Redimensionner la porte

Acteurs Utilisateur

But Permet le redimensionnement de la porte à l’aide des gestes

et les interactions NUI.




Scénario nominal L’utilisateur commence à sélectionner l’objet « porte ».

L’utilisateur présente une des gestes relative au

redimensionnement.

L’application commence à changer la taille de la porte

respectivement à la geste tourné.


Exceptions Néant.


b) Description textuelle du cas d’utilisation « Sélectionner et cliquer sur les éléments

interactifs»


99

Tableau 32: Description textuelle du cas d'utilisation « Sélectionner et cliquer sur les éléments

interactifs»

Description

Titre Sélectionner et cliquer sur les éléments interactifs

Acteurs Utilisateur

But Permet la sélection et le clique sur les éléments interactifs.




Scénario nominal L’utilisateur ferme et avance l’une des mains.

L’application lance la clique au sein du navigateur.


Exceptions Néant.


c) Description textuelle du cas d’utilisation « Tourner les objets»

Tableau 33: Description textuelle du cas d'utilisation « Tourner les objets »

Description

Titre Tourner les objets

Acteurs Utilisateur

But Permet la rotation des objets en utilisant les gestes.




Scénario nominal L’utilisateur commence à sélectionner l’objet « porte ».

L’utilisateur présente une des gestes relative à la rotation.


100

L’application tient la rotation de la porte respectivement à la

position des mains.


Exceptions Néant.


II.1.3. Diagramme de séquence détaillé

En se basant sur la description textuelle des cas d’utilisation, nous modélisons donc le

diagramme de séquence détaillé de ces derniers.


101

A. Diagramme de séquence détaillé pour le cas d’utilisation « Tourner les objets »

Figure 35: Diagramme de séquence détaillé du cas d'utilisation "Tourner les objets"

La figure n°35 illustre les tâches pour tourner un objet dans les navigateurs tel que « le porte ». Dans ce diagramme, l’utilisateur peut tourner

la porte de simulation.


102

B. Diagramme de séquence détaillé pour le cas d’utilisation « Redimensionner la porte »

Figure 36: Diagramme de séquence détaillé du cas d'utilisation " Redimensionner la porte"

La figure n°36 illustre les tâches pour redimensionner la porte au niveau de la simulation Dans ce diagramme, l’utilisateur peut

redimensionner la porte (horizontale, verticale, perspective) .


103

C. Diagramme de séquence détaillé pour le cas d’utilisation « Sélectionner et cliquer sur les éléments interactifs»

Figure 37: Diagramme de séquence détaillé du cas d'utilisation " Sélectionner et cliquer sur les éléments interactifs"

La figure n°37 illustre les tâches pour sélectionner ou faire cliquer sur des interactifs (bouton, lien , canvas …), l’utilisateur peut sélectionner

ou faire des cliques.


104

III. Conclusion

A ce stade, nous avons réussir donc à développer le dernier release de notre application

pour arriver à un produit complet et fonctionnel. Il nous reste seulement une dernière étape et

qui consiste à implémenter l’application auprès du client final.

Chapitre V : La phase closure

105

Chapitre 5: La phase closure

La phase closure ou de fermeture est la dernière phase dans le cycle de développement d’un logiciel avec Scrum. Cette phase est souvent appelé sprint de stabilisation [16]. Les tâches effectuées pendant cette phase ne sont pas claires, et ils dépendent fortement du type de déploiement du logiciel (mise en production à chaud, packaging du produit, mise à disposition par téléchargement en ligne...).

Pour notre projet, ce chapitre sera consacré pour la présentation des langages et outils de programmation utilisés pour la réalisation de notre application, le déploiement de notre application et sa documentation. Nous finissons pour quelques interfaces graphiques du logiciel fourni.


106

I. Environnement de développement

L’environnement de développement est un terme qui désigne l’ensemble d’outils et de

langage utilisé pour l’implémentation d’une solution informatique. Nous commençons par

l’environnement matériel.

I.1. Environnement matériel Pré requis :

Pour pouvoir utiliser la Kinect 2 sur notre PC ou tablette, il va falloir un certain nombre

de pré requis, le volume de donnée qui va transiter entre la Kinect 2 et notre PC étant bien plus

important que la V1, notre machine doit respecter les spécifications minimales suivantes

illustrées dans le tableau 34 :

Tableau 34: Table de caractéristiques matérielles requises

Processeur : 64 bits (x64)

Dual-core 3,1 GHz physique (2 logical cores per physical)

USB : Contrôleur USB 3.0

RAM : 4 GO de RAM au minimum

Carte Graphique : Carte graphique prenant en charge DirectX 11

Système d’exploitation : Windows 8 ou 8.1 ou Windows Embedded 8

La liste est donc beaucoup plus restrictive que sur la V1. Il faut savoir aussi que si nous

souhaitons faire du Kinect Fusion, il vous faudra une carte graphique très robuste.

Notre application a été réalisée sur deux ordinateurs dont les caractéristiques sont les

suivantes illustrées dans le tableau 35 :


107

Tableau 35: Table de caractéristiques matérielles

Marque DELL LATITUDE 5520 DELL OPTIPLEX

RAM : 8 Go 1067 MHz DDR3 8 Go 1067 MHz DDR3

Processeur 2.66 GHz Intel Core I5 2.66 GHz Intel Core I5

Disque dur 800 Go 500 Go SSD

USB 2.0 3.0

Système d’exploitation Windows 8.1 Windows 8.1

Figure 38: La composition du Kinect V2

Il faut savoir que la Kinect 2 est différente de la première. En effet, là où la V1 utilisait

une matrice infrarouge (lumière structurée) pour la détection de profondeur, la V2 utilise la

technologie Time of Light qui réellement bien plus efficace. Ce qui lui permet d’être bien plus

précise et ce même dans le noir.

Image: iFixit, http://www.ifixit.com

Power

RGB

IR

Depth Microp

Depth IR

RGB Camera Depth Sensor

IR Emitters

Depth Sensor

IR Emitters

Power Light

Microphone Array


108

I.2. Environnement de test

Jenkins, qui s'appelait à l'origine Hudson, est un outil d'Intégration Continue

open source écrit en Java. Bénéficiant d'une part de marché dominante, Jenkins est utilisé par

des équipes de toutes tailles, pour des projets dans des langages et des technologies variés,

incluant Java, NET, Ruby, Grails, PHP …. »

Ils existent plusieurs autres serveurs d’intégration continue tels que « Continuum » et

« Atlassian Bamboo », mais le choix de Jenkins était le plus approprié pour plusieurs raisons.

Tout d‘abord, Jenkins est très facile à utiliser : nous pouvons démarrer avec lui en

quelques minutes. En effet, son interface utilisateur est très simple, clair, intuitive et

visuellement agréable et s’adapte facilement aux désirs de l’utilisateur grâce à sa flexibilité.

Ensuite, la communauté de Jenkins est immense, réactive, dynamique et accueillante et

le rythme de développement est très intense (dernière évolution, correction et mises à jour des

extensions, …).

De plus, nous pouvons installer facilement des centaines d’extensions open source qui

couvrent tous les outils de « build » et de gestion de configuration, les métriques de qualités de

code et beaucoup d’autres fonctionnalités encore par exemple Plagin TestLink, Plagin

Selenium….

Aussi, on peut installer « Jenkins » sur les différents systèmes d'exploitation. Avec

Jenkins, il est possible d'utiliser un grand nombre d'outils qui ne sont pas intégré directement à

Jenkins tels que le système de gestion de version (CVS, Git, SVN) et peut exécuter des projets

basés sur Apache Ant ou Maven.


109

I.3. Environnement de production « C’est un logiciel de gestion de version distribué, très puissant et récent, il a

été créé par Linus Torvalds, qui est entre autres l’homme à l’origine de Linux.

Il se distingue par sa rapidité et sa gestion des branches qui permettent de

développer en parallèle de nouvelles fonctionnalités. »

Git est considéré comme performant, au point que certains autres logiciels de gestion de

version (Darcs, Arch), qui n'utilisent pas de base de données, se sont montrés intéressés par le

système de stockage des fichiers de Git pour leur propre fonctionnement.

Les principales commandes utilisées avec système de gestion de version sont :

Clone : pour obtenir une copie d’un projet existant.

Checkout : pour récupérer une branche ou un chemin de l’arbre de travail.

Status : pour afficher l’état de la copie de travail, c'est-à-dire les fichiers qui ont été

modifiés par rapport au référentiel.

Add : pour préparer un fichier ou un répertoire à être ajouter sur le serveur.

Delete : pour préparer un fichier ou un répertoire à être supprimer.

Commit : envoyer les fichiers et les répertoires modifiés au serveur.


110

Figure 39: Fonctionnement de Git

I.4. Environnement logiciel

Pour implémenter notre application, nous avons eu recours aux outils de développement

suivants :

Microsoft Visual Studio :

Microsoft Visual Studio est une suite de logiciels de développement

pour Windows conçue par Microsoft. La dernière version s'appelle Visual Studio 2015.

Visual Studio est un ensemble complet d'outils de développement permettant de générer

des applications Web ASP.NET, des Services Web XML, des applications bureautiques et des

applications mobiles. Visual Basic, Visual C++, Visual C# et Visual J# utilisent tous le même

environnement de développement intégré (IDE, Integrated Development Environment), qui

leur permet de partager des outils et facilite la création de solutions faisant appel à plusieurs

langages. Par ailleurs, ces langages permettent de mieux tirer parti des fonctionnalités

du Framework .NET, qui fournit un accès à des technologies clés simplifiant le développement

d'applications Web ASP et de Services Web XML grâce à Visual Web Developer.

Kinect v2 Configuration Verifier

Il vous permet rapidement de tester si vous avez les pré-requis pour Kinect 2 (figure 40)

et si elle communique bien avec votre machine. En cas d’erreur, un petit texte vous permet

d’avoir des conseils sur le pré requis ou les causes du dysfonctionnement.


111

Figure 40: Kinect v2 Configuration Verifier

Kinect Studio

Le Kinect Studio (figure 41) nous permet d’enregistrer nos sessions avec Kinect 2 sous

forme d’un fichier replay qui pourra être rejoué plus tard sans forcément avoir une Kinect 2

connecté à votre système. Cela nous permet par exemple d’enregistrer une session de

mouvement pour un cas précis de notre applicatif et de le rejouer à loisir en mettant des points

d’arrêts, sans avoir à bouger de notre siège, car il n’y a rien de plus pénible que de devoir se

lever, se mettre devant la Kinect et revenir à son siège pour voir ou sa cloche ou encore stopper

l’exécution.

Figure 41: Kinect Studio

Visual Gesture Builder :


112

Pour le dernier outil de ce SDK, Visual Gesture Builder. Déjà il faut savoir que cet outil

est une PREVIEW, donc non complet, non terminée, etc. La promesse de cet outil et de pouvoir

décomposer des gestuelles sous forme de données qui pourront être importé dans le SDK au

run time afin de détecter des gestuelles précise.

Après avoir lancé le Visual Gesture Builder, il faut créer une solution (un peu comme

dans Visual Studio) et y mettre des projets. Chaque projet contiendra des gestuelles. L’ajout

d’une gestuelle fera apparaître cette popup :

Figure 42: Visual Gesture Builder

Elle permet de déterminer de quoi sera composée votre gestuelle, en gros s’il y aura les

mains, si le haut du corps suffit et le type. Cela permet à l’outil d’être plus précis dans sa

détection de mouvement.

Photoshop est un logiciel de retouche, de traitement et de dessin assisté par ordinateur

édité par Adobe. Il est principalement utilisé pour le traitement de photographies

numériques, mais sert également à la création d'images ex nihilo. Adobe Illustrator.


113

Adobe Illustrator est le logiciel de création graphique vectorielle de référence dans les

environnements professionnels. Il fait partie de la gamme Adobe et peut être utilisé

indépendamment ou en complément de Photoshop. Il offre des outils de dessin vectoriel

puissants.

Sublime Text est un éditeur de texte générique codé en C++ et Python, disponible

sur Windows, Mac et Linux. Le logiciel a été conçu tout d'abord comme une extension

pour Vim, riche en fonctionnalités.

Depuis la version 2.0, sortie le 26 juin 2012, l'éditeur prend en charge 44 langages de

programmation majeurs, tandis que des plugins sont souvent disponibles pour les langages plus

rares.

WAMP est un acronyme informatique signifiant :

« Windows »« Apache »« MySQL »« PHP » dans la majorité des cas mais aussi

parfois, « Perl », ou « Python ».Il s'agit d'un néologisme basé sur LAMP.

Les rôles de ces quatre composants sont les suivants :

Apache est le serveur web « frontal » : il est « devant » tous les autres et répond

directement aux requêtes du client web (navigateur) ;

Le langage de script PHP sert la logique ;

MySQL stocke toutes les données de l'application ;

Windows assure l'attribution des ressources à ces trois composants.

I.5. Outils de développement de l’application

HTML 5:

L’HyperText Markup Language, généralement abrégé HTML, est le format de

données conçu pour représenter les pages web. Il permet notamment d’implanter

de l’hypertexte dans le contenu des pages et repose sur un langage de balisage,

d’où son nom. HTML permet aussi de structurer sémantiquement et de mettre en

forme le contenu des pages, d’inclure des ressources multimédias dont des images, des

formulaires de saisie, et des éléments programmables tels que des applets. Il est souvent utilisé


114

conjointement avec des langages de programmation (JavaScript) et des formats de présentation

(feuilles de cascade).

CSS 3:

Le langage CSS (Cascading Style Sheets) est utilisé pour définir l'aspect futur de

votre application, comme par exemple la couleur du fond de la page ou le type de la

police.

Plus concrètement, le CSS (ou feuille de style), c'est un petit fichier (exemple "style.css") dans

lequel vous allez définir l'aspect futur de votre site.

SVG :

Le Scalable Vector Graphics (en français « graphique vectoriel adaptable »), ou SVG,

est un format de données conçu pour décrire des ensembles de graphiques vectoriels

et basé sur XML. Ce format inspiré directement du VML et du PGML est spécifié par le

World Wide Web Consortium.

JavaScript :

est un langage de programmation de scripts principalement employé dans les pages

web interactives mais aussi pour les serveurs. C’est un langage orienté

objet à prototype, c’est-à-dire que les bases du langage et ses principales interfaces

sont fournies par des objets qui ne sont pas des instances de classes, mais qui sont chacun

équipés de constructeurs permettant de créer leurs propriétés, et notamment une propriété de

prototypage qui permet d’en créer des objets héritiers personnalisés. En outre, les fonctions sont

des objets de première classe.

Le langage a été créé en 1995 par Brendan Eich (Brendan Eich étant membre du conseil

d'administration de la fondation Mozilla à cette époque) pour le compte de Netscape

Communications Corporation. Le langage, actuellement à la version 1.8.2, est une

implémentation de la 3e version de la norme ECMA-262 qui intègre également des éléments


115

inspirés du langage Python. La version 1.8.5 du langage est prévue pour intégrer la 5éme version

du standard ECMA.

C# :

est un langage de programmation orienté objet à typage fort, créé par la société

Microsoft, et notamment un de ses employés, Anders Hejlsberg, le créateur du

langage Delphi.

Il a été créé afin que la plate-forme Microsoft .NET soit dotée d'un langage permettant

d'utiliser toutes ses capacités. Il est très proche du Java dont il reprend la syntaxe générale ainsi

que les concepts (la syntaxe reste cependant relativement semblable à celle de langages tels que

le C++ et le C). Un ajout notable au C♯ est la possibilité de surcharge des opérateurs, inspirée

du C++. Toutefois, l'implémentation de la redéfinition est plus proche de celle du Pascal Objet.

Web Socket

C’est un standard du Web dont la spécification est en cours de

définition désignant un protocole réseau de la couche application et

une interface de programmation du World Wide Web. Le protocole

a été normalisé par l'IETF dans la RFC 6455 et l'interface de programmation est en cours

de standardisation par le W3C.

JQUERY

JQuery est une bibliothèque JavaScript libre et multiplateforme créée pour

faciliter l’écriture de scripts côté client dans le code HTML des pages web. La

première version est lancée en janvier 2006 par John Resig.

La bibliothèque contient notamment les fonctionnalités suivantes :

- Parcours et modification du Document Object Model (DOM) (y compris le support des

sélecteurs CSS 1 à 3 et un support basique de XPath);

- Événements;


116

- Effets visuels et animations;

- Manipulations des feuilles de style en cascade (ajout/suppression des classes, d’attributs...);

- Ajax;

- Plugins;

- Utilitaires (version du navigateur web...) [18].

AJAX

Ajax permet de modifier partiellement la page affichée par le navigateur pour

la mettre à jour sans avoir à recharger la page entière. Par exemple le contenu

d’un champ de formulaire peut être changé, sans avoir à recharger la page avec les images, le

menu, etc. Ajax est une technique qui fait usage des éléments suivants :

- HTML pour l’interface.

- CSS pour la présentation de la page.

- JavaScript (Ecma Script) pour les traitements locaux, et DOM qui accède aux éléments de la

page ou du formulaire ou aux éléments d’un fichier XML chargé sur le serveur.

- L’objet XML http Request lit des données ou fichiers sur le serveur de façon asynchrone.

- PHP ou un autre langage de scripts peut être utilisé coté serveur [19].

JSON :

(JavaScript Object Notation) est un format de données textuelles, générique, dérivées

de la notation des objets du langage ECMA Script. Il permet de représenter de

l’information structurée. Créé par Douglas Crock ford.

Un document JSON ne comprend que deux éléments structurels :

des ensembles de paires nom / valeur ;


117

des listes ordonnées de valeurs.

Ces mêmes éléments représentent 3 types de données :

des objets ;

des tableaux ;

des valeurs génériques de type tableau, objet, booléen, nombre, chaîne ou null.

I.6. Outils de conception

Visual Paradigm for UML

comme son nom le laisse supposer, un logiciel permettant aux

programmeurs de mettre en place des diagrammes UML. Disposant d'un

outil créant des rapports personnalisables aux formats PDF, Word ou HTML afin de les partager

et les publier sur Internet, cette application est compatible avec de nombreuses applications,

standards et environnements. Ainsi, vous pourrez générer notamment des diagrammes de

séquences ou de cas d'utilisation et ainsi produire du code source dans de nombreux langages

comme le Java ou encore le C++, ou bien faire l'inverse, générer des diagrammes à partir de

code déjà existant.

I.7. Outils de traitement et de présentation

Microsoft Office 2013

Microsoft Office 2013 est la dernière version de Microsoft Office, suite

de bureautique conçue pour Windows. C'est, avec Microsoft Office 365,

le successeur de Microsoft Office 2010. Elle propose des nouveautés comme une ergonomie

simplifiée avec la prise en charge optimisée des interfaces tactiles, et une plus grande


118

compatibilité avec tout type de document dont Portable Document Format (PDF) qui peut

désormais s'ouvrir et être modifié directement dans Word 2013.

II.Mesure d’optimisation de niveau technique

a) Architecture modèle/vue/contrôleur

L'organisation globale d'une interface graphique est souvent délicate. Cette architecture

fournit souvent une première approche qui peut ensuite être adaptée. Comme elle offre aussi un

cadre pour structurer une application. Ce patron d'architecture impose la séparation entre les

données, la présentation et les traitements, ce qui donne trois parties fondamentales dans

l'application finale comme le représente la figure suivante (figure 43).

Figure 43: Représentation du modèle MVC et les relations entre les trois parties

Le modèle

Le modèle représente le comportement de l'application : traitements des données,

interactions avec la base de données, etc. Il décrit ou contient les données manipulées par

l'application. Il assure la gestion de ces données et garantit leur intégrité. Dans le cas typique

d'une base de données, c'est le modèle qui la contient. Le modèle offre des méthodes pour mettre


119

à jour ces données (insertion, suppression, changement de valeur). Il offre aussi des méthodes

pour récupérer ces données.

La vue

La vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche est

de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les

actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons, etc.). Ces différents

événements sont envoyés au contrôleur.

Le contrôleur

Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre

à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l'utilisateur et

enclenche les actions à effectuer. Si une action nécessite un changement des données, le

contrôleur demande la modification des données au modèle, et ce dernier notifie la vue que les

données ont changée pour qu'elle se mette à jour.

La présentation des données : correspondant à l'affichage et au dialogue avec

l'utilisateur à l’intermédiaire d’un navigateur gérer par un serveur web.

Le traitement des données : correspondant à la mise en œuvre de l'ensemble des

règles de gestion et de la logique applicative à l’intermédiaire d’un serveur

d’application.

L’accès aux données: correspondant aux données qui sont destinées à être

échangées à l’intermédiaire d’un serveur de données.

Dans l’architecture à trois niveaux, les applications au niveau serveur sont délocalisées ;

c'est-à-dire que chaque serveur est destiné à faire des taches uniques pour garantir :

Une grande flexibilité à la manipulation des données.

Une sécurité accrue, car la sécurité peut être définie indépendamment pour chaque

service et à chaque niveau


120

De meilleures performances, étant donné le partage des tâches entre les différents

serveurs.

b) SVG et performance

L’un des principaux avantages de ce format et que l’on peut redimensionner une image

sans aucune perte de qualité contrairement à une image jpeg ou png par exemple. Ceci est dû

au fait que ces images soient vectorielles.

Afin de vous faciliter la tâche, certaines formes géométriques de base sont déjà gérées

telles que les rectangles ou les ellipses par exemple. Il est également possible d’obtenir

n’importe quelle forme à l’aide des paths qui sont des chemins et vous permettent de tracer ce

que vous souhaitez.

Les éléments dessinés au format SVG sont exportables afin d’être réimporter dans un

autre endroit du dessin SVG.

Enfin, aujourd’hui une très grande partie des navigateurs sont capables de gérer des

éléments au format SVG.

c) Justification de l’utilisation du Web Socket

WebSocket est une fonctionnalité supportée par l'ensemble des navigateurs récents. Elle

permet un échange bilatéral synchrone entre le client et le serveur.


121

Figure 44: Architecture Client/Serveur REST

Habituellement, la communication est asynchrone : le client demande, le serveur répond.

C'était suffisant aux débuts du Web, mais c'est devenu trop limitant ces derniers temps.

On a besoin d'une communication plus réactive et immédiate. Dans ce schéma par exemple, le

serveur ne peut pas décider de lui-même d'envoyer quelque chose au client (par exemple pour

l'avertir "eh il y a un nouveau message !"). Il faut que le client recharge la page ou fasse une

action pour solliciter le serveur, car celui-ci n'a pas le droit de s'adresser au client tout seul.

WebSocket est une nouveauté du Web qui permet de laisser une sorte de "tuyau" de

communication ouvert entre le client et le serveur. Le navigateur et le serveur restent connectés

entre eux et peuvent s'échanger des messages dans un sens comme dans l'autre dans ce tuyau.

Désormais, le serveur peut donc lui-même décider d'envoyer un message au client comme un

grand.

Figure 45: Architecture Client/Serveur WebSocket

Avec les WebSocket, la communication est synchrone : un tuyau de communication reste

ouvert entre client et serveur.

Nous procédons par la suite à une étude comparative entre le Web Socket et le REST

comme il est indiqué dans le tableau 36.


122

Tableau 36: Table de comparaison entre le Web Socket et le REST [13]

Nombre de

messages

REST (en fonction

ms)

Web Socket (en

fonction ms)

Message/ms

10 17 13 1.31

100 112 20 5.60

500 529 55 7.75

1000 1050 115 9.13

5000 5183 522 9.93

10000 10547 1019 10.35

Web socket n’est donc pas une spécification des techniques de push sur HTTP (long

polling, HTTP Streaming, …), ni une surcouche à HTTP mais bien un protocole à part entière.

Il reste pourtant lié à HTTP en réutilisant l’architecture réseau de celui-ci. En effet,

l’ouverture d’une connexion Web socket s’effectue avec une requête HTTP qui demande au

serveur « de mettre à jour la connexion » en connexion Web socket comme il est indiqué dans

la figure 46.


123

Figure 46: Architecture Client/Serveur Web Socket

Le serveur, s’il supporte le protocole Web socket, peut ainsi terminer l’ouverture de la

connexion et la suite du dialogue entre le client et le serveur s’effectuera avec le protocole Web

socket.

d) La reconnaissance des gestes

L’analyse et l’interprétation des mouvements humains peuvent aussi être effectuées par

des primitives 3D (positions, angles articulatoires...) qui nécessitent un suivi 3D du corps entier

ou de quelque partie du corps selon les mouvements à interpréter.

Nous proposons de classer des gestes dynamiques à partir de la trajectoire 3D de la main.

La reconnaissance est effectuée par la mesure de la déformation temporelle dynamique. La

Déformation temporelle dynamique (DTW) est une technique de mesure de distance entre deux

séquences qui ont une variation temporelle (exécutées à une vitesse différente par exemple).

SERVEURCLIENT (Navigateur)

Handshake (HTTP upgrade)

Connexion ouverte

Connexion fermé

Fermeture du canal par un des hôtes

Communication Full Duplex

Connexion persistent

Connexion TCP établis

HTTP (Requête + Réponse)

Connexion TCP fermé


124

Elle a été utilisée dans la reconnaissance de la parole et a été appliqué dans la reconnaissance

des gestes. Soient deux séries numériques temporelles U et V, de longueur respective n et m,

Avec :

U = u1, u2, ..., ui , ..., un (4)

V = v1, v2, ..., vj , ..., vm (5)

Pour aligner les deux séquences par la technique DTW nous calculons la matrice (n −

sur − m) avec le (i eme, jeme) élément de cette matrice contient la distance d (ui,vj) entre les deux

points ui et vj.

Dans notre cas, nous utilisons le Visual gesture bluider. C’est un outil qui nous permet

de décomposer des gestuelles sous forme de données qui pourront être importé dans le SDK au

runtime afin de détecter des gestuelles précise.

e) La détection des expressions et des accessoires

La notion d’émotion est très familière, nous avons tous la capacité de la définir.

Mais fournir aux ordinateurs la capacité d’interpréter ou de simuler les émotions peut améliorer

notre manière de communiquer avec les systèmes informatiques.

Kinect nous permet de détecter un certains types d’expressions et d’accessoires tel que :

Heureux,

Gauche / Droite oeil ouvert,

Gauche /Droite œil fermé,

En regardant au loin,

Lunettes.


125

III. Documentation

La documentation logicielle est un texte qui sera livré avec le logiciel en expliquant

comment ce dernier fonctionne et/ou comment il est implémenter. La documentation des

applications informatiques est une pratique primordiale pour s'assurer de l'évolution du logiciel

et la continuité du travail par la suite. Malgré que l’un des valeurs du manifeste agile : un logiciel

qui fonctionne plutôt que la documentation. Cela ne veut pas dire que la documentation est

négligée avec Scrum. Dans ce cadre, nous avons essayé tout au long de notre travail de préparer

la documentation nécessaire pour les futurs développeurs.

IV. Les interfaces de l’application

Dans ce paragraphe, nous présentons quelques interfaces de l’application réalisée.

a) Interface d’accueil

L’interface d’accueil est la première interface de notre application Web, avec laquelle

l’utilisateur peut accéder à notre application.

Au lancement de notre site, l’utilisateur peut consulter une petite démonstration et les

fonctionnalités principales de notre application. Comme il est indiqué dans la figure 47.


126

Figure 47: Page d’accueil du notre site de simulation

a) Message Kinect

Le message de notre application, nous permet de savoir l’état actuel de notre console

Kinect et nous guide à résoudre le problème comme il est indiqué dans la figure 48.

Figure 48: Message qui improuve l’état du Kinect

b) L’interface de simulation

Figure 49: Le menu de simulation

Le menu de notre application

Web, nous permet d’accéder

aux différentes fonctionnalités

de l’application comme il est

indiqué dans la figure 49.

c) Les fonctionnalités de la maison

La rubrique « Ma Maison »nous permet de charger et changer l’image de la maison :

une image requise ou une image des maisons témoins.


127

Figure 50: Les fonctionnalités de la maison

d) Les fonctionnalités de la catégorie« Forme »

Si l’utilisateur veut changer la forme de son porte il suffit de sélectionner le bouton

Frome pour consulter toute une bibliothèque de forme, cela est illustré dans la figure 51.

Figure 51: Les fonctionnalités de la catégorie« Forme »

e) Les fonctionnalités de la catégorie« Matériaux »


128

Notre application offre 6 catégories de matériaux pour les portes d'entrée et une

multitude de combinaisons sont possibles entre elles en fonction de vos envies, de vos

goûtscomme ul est illustré dans la figure 52.

Figure 52: Les fonctionnalités de la catégorie « Matériaux »

Les fonctionnalités de la catégorie« Panneaux »

Cette rubrique dispose un vaste de choix panneaux qui permet au client de satisfaire son

besoin comme il est illustré dans la figure 53.


129

Figure 53: Les fonctionnalités de la catégorie « Panneaux »

Les fonctionnalités de la catégorie « Couleurs »

Depuis la catégorie « Couleurs », l’utilisateur peut changer les couleurs de son porte

selon leur choix comme indiqué dans la figure 54.

Figure 54: Les fonctionnalités de la catégorie « Couleurs »

Les fonctionnalités de la catégorie « Vitrages »

La catégorie « Vitrages » nous permet de choisir le vitrage qui nous plaît selon nos

besoins esthétiques comme indiqué dans la figure 55.


130

Figure 55: Les fonctionnalités de la catégorie « Vitrages »

L’interface « Accessoires » affiche tous les accessoires disponibles comme indiqué dans

la figure 56.

Figure 56: Les fonctionnalités de la catégorie « Accessoires »

Les fonctionnalités de la catégorie « Inclinaisons »

La rubrique « Inclinaisons » nous permet de créer des inclinaisons horizontale et

verticale pour adapter notre porte visée sur l’image requise. Comme il est illustré dans la figure

57.


131

Figure 57: Les fonctionnalités de la catégorie « Inclinaisons »

La rubrique « Vue intérieur » nous permet de simuler les portes à l’intérieur de la

maison. Comme il est illustré dans la figure 58.

Figure 58: Vue d’intérieur

La rubrique « Conseil Client en ligne » nous permet de contacter l’administrateur.

Comme il est illustré dans la figure 59.


132

Figure 59: Conseil client en ligne

La rubrique « Enregistrement de la simulation » nous permet de recevoir un mail qui

contient des images de notre simulation. Comme il est illustré dans la figure 60.

Figure 60: Enregistrement de la simulation

Les scénarios de mode d’emploi du Kinect V2 :

L’utilisateur est non engagé :

Les deux mains sont baissées.


133

Figure 61: utilisateur est non engagé « Capture IR)

L’utilisateur est engagé

Pour utiliser le Kinect V2 on à fixer un algorithme qui nous permet d’engager les utilisateurs

par la salutation par la main Gauche ou droite


134

Figure 62: Engagement de l’utilisateur

Figure 63: Redimensionnement perspective de l’utilisateur


135

Figure 64: La sélection d’un objet

Figure 65: Avancer la main pour cliquer

Figure 66: Redimensionnement verticale


136

Figure 67: Redimensionnement horizentale

Figure 68: Redimensionnement responsive

Figure 69: Redimensionnement verticale

V. Apports et Evaluation

Ce projet a été une occasion pour étendre, développer et exercer nos compétences de

conception, d’analyse, d’organisation, de développement et même de rédaction, et pour cela

nous allons citer ce que nous avons appris toute au long de cette expérience.

V.1. Apports au niveau des connaissances technique : La finalisation de ce projet nous a permis d’enrichir nos connaissances techniques à savoir :

La façon d’exploiter l’information.


137

La manipulation des langages théoriques.

L’application de nos connaissances théoriques en informatique et multimédias

sur des cas réels.

L’amélioration des connaissances acquis tout au long de notre études

universitaires et les adapter aux besoins de la réalité quotidienne.

V.2. Apports au niveau de la conception et du développement :

La finalisation de ce projet nous a permis :

De maitriser la méthodologie de conception et de développement de système

d’information «UML ».

De découvrir l’efficacité de développement d’une application sur la base d’une

conception discutée.

D’indiquer l’importance d’une documentation exacte et mise à jour dans la

conception et le développement d’une application informatique.

V.3. Apports au niveau social :

En plus des apports cites précédemment, nous avons eu la chance durant la réalisation

de notre application d’apprendre des apports au niveau social tel que :

La patience et savoir comment gérer les et les surmontés.

L’habilite de prendre l’information et l’exploiter.

L’adaptation à l’environnement professionnel.

V.4. Bilan quantitatif :

Les principaux points qui ont contribué à la qualité de développement du notre

application sont :


138

Assurer un guidage et une assistance à chaque stade du site garantie grâce à la

bonne organisation et au respect de la notion d’ergonomie.

Assurer une navigation et un usage simple.

Assurer une convivialité, une attractivité dans la présentation du site.

L’utilisation d’une méthodologie de conception et modélisation UML,

Le bilan quantitatif du logiciel peut être présenté par le recensement des différents

volumes réalisés durant la phase de réalisation.

V.6. Evaluation

Afin de pouvoir évaluer le travail que nous avons établi, nous proposons de présenter

aussi bien un bilan qualitatif pour apprécier les moyennes utilisées à l’élaboration de cette

application qu’un bilan quantitatif sur les différents volumes.

VI. Bilan quantitatif

Le bilan quantitatif du logiciel peut être présenté par le recensement des différents

volumes réalisés durant la phase de réalisation, et qui est illustré dans ce tableau (tableau 37) :

Tableau 37: Table de la représentation du bilan quantitatif

Nombre de Modèle 39

Nombre de classe 11

Nombre de vue 2

Nombre de contrôleur 1

Nombre de Template 2


139

Les principaux points qui ont contribué à la qualité de développement de notre

application sont :

Assurer pour les utilisateurs une authentification guidée

Utiliser au maximum des commentaires à chaque partie du code source de notre

application pour assurer une convivialité, une simplicité d’usage pour les futurs

utilisateurs qui désirent exploiter et améliorer notre outil.

VII. Conclusion

Tout au long de ce chapitre nous avons essayé de présenter les différents travaux qui se

déroulent à la fin du cycle de développement Scrum. Nous avons présenté les outils de travail

que nous avons utilisé à savoir l’environnement de développement et celui de programmation.

Enfin, nous avons présenté les différentes interfaces de notre outil d’optimisation et préparé la

documentation nécessaire pour les futurs développeurs.

Conclusion et perspectives

140

Conclusion et perspectives

Notre projet de fin d’étude porte sur la conception et le développement d’une application qui

permet de kinnifier le web pour la société « SiFast ». C’est une occasion pertinente pour

concrétiser et améliorer nos connaissances informatiques que nous avons acquises pendant

nos études supérieures. Nous avons essayé d’ajouter des nouvelle techniques d’interactions

IHM en utilisant les gestes, cette solution a été développé au sein de cette société en se

basant sur le langage de modélisation UML qui nous a permis de comprendre les besoins, afin

d’aboutir une application facile à utiliser.

Nous avons commencé dans un premier lieu par comprendre le contexte général de notre

application et identifier les différentes exigences de notre futur système. Nous avons préparé

par la suite notre planning de travail en respectant les priorités de nos besoins suite à une

discussion entre l’équipe du développement et le directeur du produit. Lors de notre cycle de

développement nous avons implémenté la méthodologie Scrum.

Malgré toutes les difficultés rencontrées au niveau de la recherche, manque du

documentation et les contraintes de temps, nous avons réussi à réaliser la totalité de notre

application tout en respectant l’aspect sécuritaire.

Comme perspective de ce travail, nous proposons d’améliorer notre application en

créant un Framework générique c.-à-d. une application qui peut être utilisé dans plusieurs

domaine tel que les borne interactive à base des émotions qui permette de présenter un type de

publicité ciblé.

En plus cette solution peut être implémentée au niveau des robots pour avoir la

possibilité de les télécommander sans fil en utilisant les gestes et le mouvement du corps

Enfin, nous voyons que ce projet de fin d’études a permis d’enrichir notre expérience et

de renforcer nos chances de succès dans notre carrière professionnelle.

Annexe A

141

Annexe A

I. Présentation Le développement ou la méthode Agile, appelé aussi développement adaptatif, se caractérise par un style de conduite de projet itératif incrémental, centré sur l'autonomie des ressources humaines impliquées dans la spécification, la production et la validation d'une application intégrée et testée en continu.

Plutôt que :

Figure 70: Processus actuel de développement

On fait :

Figure 71: Processus Agile

Le Manifeste Agile (Les 12 principes de la méthode agile) est considéré comme la définition canonique du développement agile. Il se compose de quatre valeurs et 12 principes. [11]

Annexe A

142

II.Les 4 valeurs du Manifeste Agile 1-Individus et échanges plus que processus et outils.

2-Produit fonctionnel plus que documentation pléthorique.

3-Collaboration du client plus que négociation du contrat.

4-Réactivité au changement plus que suivi d'un plan.

III. Les 12 principes du Manifeste Agile 1-Notre priorité première est de satisfaire le client en livrant au plus tôt et de manière constante un logiciel de qualité.

2-Tout changement, même tardif, des exigences pendant le développement est bienvenu. Les méthodes Agiles transforment le changement en avantage compétitif pour le client.

3-Livrer régulièrement un logiciel fonctionnel, toutes les deux semaines à deux mois, en référant la plus petite périodicité.

4-Maitrise d'ouvrage et développeurs doivent collaborer quotidiennement tout au long du projet.

5-Bâtir le projet avec des personnes motivées. Leur donner l'environnement et le soutien dont elles ont besoin et croire en leur capacité à accomplir le travail.

6-La plus efficace des méthodes pour transmettre l'information au sein et à destination d'une équipe est le face à face.

7-Un logiciel qui fonctionne est le meilleur indicateur de progrès.

8-Les méthodes Agiles favorisent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir ce rythme indéfiniment.

9-Une attention constante à l'excellence technique et à la qualité de la conception améliore l'agilité.

10-La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.

11-Les meilleures architectures, spécifications et conceptions sont issues d'équipes auto-organisées.

12-À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis modifie et ajuste son comportement dans ce sens.

Annexe B

143

Annexe B

I. Dictionnaire apuré des données

Tableau 38: Table dictionnaire apuré des données pour le Release 1 Sprint 1

Lettre Numéro Code Désignation

A 01 Adresse_code_postal L’adresse du notre client ou

notre fournisseur ainsi, le code

postale de cette région.

02 Adresse_IP_Client C’est l’adresse IP ou

l’identifiant de la connexion

pour notre client qui permet par

la suite le Tracking.

03 Adresse_Nro C’est l’identifiant du notre

habitat.

04 Adresse_Pays Le nom de notre pays.

05 Adresse_Rue L’adresse de la rue de l’habitat.

06 Adresse_Ville C’est l’adresse de la ville.

07 attribute_min_Element

B 08 Brillance_Picture C’est une valeur qui indique la

brillance de l’image.

C 09 Civilité_Contart C’est le type du contrat avec le

distributeur.

10 CodeSiret_Distributeur C’est le code fiscal du

distributeur.

Annexe B

144

11 Contact_Client La date de la dernière

localisation effectuée par

l’utilisateur

12 description_Gamme C’est une description textuelle

pour la gamme des produits.

13 Description_Picture Une description textuelle pour

l’image pour l’indexer par la

suite.

14 Email_Client L’adresse mail du notre client.

15 Email_Distributeur L’adresse mail du notre

distributeur.

G 16 Géolocalisation_Client un procédé permettant de

positionner un client.

H 17 HauteurMax C’est la hauteur maximum de

la forme.

18 HauteurMax_Imposte C’est la hauteur maximum

d’Imposte.

19 HauteurMax_Vantail C’est la hauteur maximum du

ventail.

20 HauteurMin_Cadre C’est la hauteur minimum du

cadre.

21 HauteurMin_Imposte C’est la hauteur minimum de

l’imposte.

22 HauteurMin_Vantail C’est la hauteur minimum du

ventail.

I 23 id_Accessoire L’identifiant de l’accessoire.

24 id_Adresse L’identifiant de l’adresse.

25 id_Cadre L’identifiant du cadre

Annexe B

145

26 id_Chasis L’identifiant du châssis

27 Id_Client L’identifiant du client

28 id_Contart L’identifiant du contrat.

29 Id_Couleur L’identifiant du couleur.

30 id_Distributeur L’identifiant du distributeur.

31 id_Element L’identifiant d’élément.

32 id_Forme L’identifiant de la forme.

33 id_Gamme L’identifiant de la gamme

34 id_Imposte L’identifiant de l’imposte.

35 id_Materieau L’identifiant du matériau.

36 Id_Navigateur L’identifiant du navigateur

37 id_picture L’identifiant d’une image

38 id_Sèrigraphie L’identifiant de la sérigraphie.

39 id_Simulation L’identifiant de la simulation.

40 id_Type_Accessoire L’identifiant du type

d’accessoires.

41 id_Vantail L’identifiant du ventail.

42 id_vitrage L’identifiant du vitrage.

43 id_vue L’identifiant du vue.

44 IntansitéR_Couleur L’intensité du couleur rouge

45 IntensitéB_Couleur L’intensité du couleur bleu

46 IntensitéV_Couleur L’intensité du couleur vert

L 47 Largeur_Choisi_Element C’est la largeur désirée par le

client.

48 Largeur_Element C’est la largeur par défaut d’un

élément.

Annexe B

146

49 Largeur_Picture C’est la largeur d’une image.

50 Latitude C’est une coordonnée

géographique représentée par

une valeur angulaire,

expression de la position d'un

point sur Terre.

51 Libéle_Element C’est l’intitulé d’un élément.

52 Libellè_Accessoire C’est l’intitulé d’un accessoire.

53 Libellè_Couleur C’est l’intitulé d’un couleur.

54 Libellé_Forme C’est l’intitulé d’une forme.

55 libéllé_Gamme C’est l’intitulé d’une gamme.

56 libelle_Materieau C’est l’intitulé d’un matériau.

57 Libellé_Sèrigraphie C’est l’intitulé d’un

Sérigraphie.

58 Libellé_Simulation C’est l’intitulé d’une

simulation.

59 Libellé_Type_Accessoire C’est l’intitulé d’un type

d’accessoire.

60 libelle_vitrage C’est l’intitulé d’un vitrage.

61 Longeur_Picture C’est la longueur de l’image

62 Longitude C’est une coordonnée

géographique représentée par

une valeur angulaire,

expression du positionnement

est-ouest d'un point sur Terre

63 Luminosité_Picture C’est une valeur qui présente la

quantité lumineuse de l’image.

N 64 Nom_Client La dénomination du client

Annexe B

147

P 65 Password_Client Mot de passe du notre client

66 Pays_Client C’est le pays de notre client

67 PositionX_Accessoire La position horizontale de

l’accessoires par rapport la

simulation.

68 PositionY_Accessoire La position Verticale de

l’accessoires par rapport la

simulation.

69 Prix_Element Le coût de cet élément.

70 Prix_Supp_Accessoire C’est un coût supplémentaire

de l’accessoire.

71 Prix_Supp_Couleur Un coût supplémentaire pour le

couleur.

72 PrixSupp_Sèrigraphie Un coût supplémentaire pour la

sérigraphie.

R 73 RaisonSociale_Distributeur C’est le raison sociale du notre

distributeur.

S 74 Sens_Ouverture_Vantail Il définit le sens d’ouveture de

la porte.

T 75 TelFixe_Client Définit le Numéro fixe du

client.

76 TelMob_Client Définit le Numéro mobile du

client.

77 Type_Navigateur C’est le type du navigateur.

78 type_vue Définit le type de simulation

soit interne soit externe.

U 79 Url_Image_Accessoire Il définit le path de l’image

d’accessoire.

Annexe B

148

Tableau 39: Table dictionnaire apuré des données pour le Release 2 Sprint 1

80 UrlImage_Sèrigraphie Il définit le path de l’image

sérigraphie.

V 81 Version_Navigateur C’est la version du navigateur.

Lettre Numéro Code Désignation

A 01 AudioSource Permet d’obtient la source

de trames audio

B 02 BodyFrameSource Obtient la source pour les

cadres du corps.

03 BodyIndexFrameSource Obtient la source pour les

cadres de l'indice de

corps.

C 04 ColorFrameSource Obtient la source pour les

cadres de couleur.

05 CoordinateMapper Obtient le mappeur de

coordonnées.

D 06 DepthFrameSource Obtient la source pour les

cadres de profondeur.

E 07 Engaged Obtient le statut de

l'engagement du corps

F 08 FacenRoll C’est le type du contrat

avec le distributeur.

09 FacePich C’est le code fiscal du

distributeur.

Annexe B

149

10 FaceYaw La date de la dernière

localisation effectuée par

l’utilisateur

H 11 HandLeftConfidence Obtient la confiance de

l'Etat de la main gauche

du corps.

12 HandLeftState Obtient le statut d'Etat la

main gauche du corps.

13 HandRightConfidence Obtient la confiance de

l'Etat de la main droite du

corps.

14 HandRightState Obtient le statut d'Etat la

main droite du corps.

15 Happy Détecte si l'utilisateur est

heureux

I 16 id_joints Obtient l’identificateur de

l’articulation

17 InfraredFrameSource Obtient la source pour les

cadres infrarouges

18 IsAvailable Obtient si le capteur

Kinect est disponible et en

mesure de récupérer les

cadres

19 IsOpen Obtient l’état du capteur

l'Kinect.

J 20 JointCount Obtient le nombre de

joints dans un corps.

Annexe B

150

21 JointType Définir le type de

l‘articulation.

K 22 KinectCapabilities obtient les capacités de

l'Kinect Sensor

L 23 LeanTrackingState Obtient l'état de suivi

pour le corps maigre.

24 LeftEyeClosed Détecte si les yeux sont

ouvert / fermé

25 LongExposureInfraredFrameSource Obtient la source pour

longtemps exposition

cadres infrarouges.

26 LookingAway Obtient si l’utilisateur

regarder loin de champ de

vision du Kinect.

M 27 MouthMoved Détecte si la bouche est en

mouvement

28 MouthOpen Détecte si la bouche est

ouverte / fermée

O 29 Orientation L'orientation de

l'articulation.

R 30 RightEyeClosed Détecte si les yeux sont

ouvert / fermé

T 31 TrackingId Obtient l'ID de suivi pour

le corps.

U 32 UniqueKinectId Obtient l’ID unique pour

le Kinect Sensor.

Annexe B

151

W 33 WearingGlasses Détecte si l’utilisateur

porte des Lunettes

X 34 X Obtient la position

horizontale de

l’articulation par rapport

au corps

Y 35 Y Obtient la position

verticale de l’articulation

par rapport au corps

Z 36 Z Obtient la profondeur de

l’articulation par rapport

la console Kinect.

Annexe C

152

Annexe C

La déduction du schéma relationnel se base sur deux règles qui sont présentées comme suit :

(ces règles sont extraites du livre [14]).

I. Règle 1 : transformation des entités/classes Chaque classe du diagramme UML devient une relation. Il faut choisir un attribut de la classe

pouvant jouer le rôle d’identifiant.

Si aucun attribut ne convient en tant qu’identifiant, il faut en ajouter un de telle sorte que la

relation dispose d’une clé primaire (les outils proposent l’ajout de tels attributs).

Figure 72: Règle 1 du passage du modèle conceptuel vers le modèle logique

II. Règle 2 : transformation des associations : Les règles de transformation des associations dépendent de leurs cardinalités maximale.

II.1. Association un à plusieurs : Il faut ajouter un attribut de type clé étrangère dans la relation fils de l’association. L’attribut

porte le nom de la clé primaire de la relation père de l’association.

Annexe C

153

Figure 73: Règle 2 du passage du modèle conceptuel vers le modèle logique

II.2. Les associations plusieurs à plusieurs : L’association (ou la classe classe-association) devient une relation dont la clé primaire est

composée par la concaténation des identifiants des classes connectés à l’association. Chaque

attribut devient clé étrangère si classe connectée dont il provient devient une relation en vertu

de la règle R1.

Les attributs de l’association (ou la classe-association) doivent être ajoutés à la nouvelle

relation. Ces attributs ne sont ni clé primaire, ni clé étrangère.

Figure 74: Règle 3 du passage du modèle conceptuel vers le modèle logique (premier cas)

II.3. Association un à un : Il faut ajouter un attribut clé étrangère dans la relation dérivée de la classe ayant la multiplicité

minimale égale à un. L’attribut porte le nom de la clé primaire de la relation dérivée de l’entité

(classe) connectée à l’association.

Si les deux cardinalités (multiplicités) minimales sont à zéro, le choix est donné entre les deux

relations dérivées de la règle R1. Si les deux cardinalités minimales sont à un, il est sans doute

préférable de fusionner les deux entités (classes) en une seule.

Annexe C

154

Figure 75: Règle 3 du passage du modèle conceptuel vers le modèle logique (deuxième cas)

II.4. Transformation de l’héritage : S’il existe une contrainte de totalité ou de partition sur l’association, il est possible de ne pas

traduire la relation issue de la surclasse. Il faut alors faire migrer tous ses attributs dans la(les)

relation(s) issue(s) de la (des) sous-classe(s).

Dans le cas contraire, il faut faire migrer tous ses attributs dans la ou les relation(s) issue(s) de

la (des) sous-classe(s) dans la (les) relation(s) issue(s) de la (des) sous-classe(s).

Figure 76: Règle 3 du passage du modèle conceptuel vers le modèle logique (troisième cas)

II.5. Transformation de la composition : La clé primaire des relations déduites des classes composantes doit contenir l’identifiant de la

classe composite (quelles que soient les multiplicités).

Figure 77: Règle 3 du passage du modèle conceptuel vers le modèle logique (quatrième cas)

Bibliographie

155

Bibliographie

[1] SiFast, «SiFast,» [En ligne]. Available: http://www.sifast.com/.

[2] Akamai, [En ligne]. Available: http://www.akamai.fr/.

[3] Etienne Delagrave, «performance-web,» [En ligne]. Available: http://www.adviso.ca/blog/2014/01/09/performance-web/]..

[4] AirXTouch, «AirXTouch,» [En ligne]. Available: http://www.inui-studio.com/en/airxtouch/.

[5] wisee, «wisee,» [En ligne]. Available: http://wisee.cs.washington.edu/.

[6] zigfu, «zigfu,» [En ligne]. Available: http://zigfu.com/.

[7] C. Aubry, SCRUM le guide pratique de la méthode agile la plus populaire, Dunod, 2010.

[8] F. V. Pascal Roques, UML2 en action de l'analyse des besoins à la conception, Paris: Eyrolles, 2007.

[9] C. Schillinger, Artist, Intégration web - Les bonnes pratiques. [Art]. 18 octobre 2012.

[10] serena, «intro-to-agile-devel,» [En ligne]. Available: http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf.

[11] P. Roques, UML2 modéliser une application web, Eyrolles, 2008.

[12] Wiki, «Wiki,» [En ligne]. Available: http://fr.wikipedia.org/wiki/Jenkins_(logiciel).

[13] «REST WEBSOCKET,» [En ligne]. Available: http://planet.jboss.org/post/rest_vs_websocket_comparison_and_benchmarks.

[14] C. Soutou, UML2 pour les bases de données, Eyrolles.

[15] 01 05 2013. [En ligne]. Available: http://dictionnaire.phpmyvisites.net/definition-Release-9456.htm.

Bibliographie

156

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

rapport finalmise en place d'un framework kinect

Education