Rapport finalMise en place d'un FrameWork Kinect

1 100 vues

Publié le

rapport de fin d'étude

Publié dans : Formation
1 commentaire
1 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
1 100
Sur SlideShare
0
Issues des intégrations
0
Intégrations
141
Actions
Partages
0
Téléchargements
17
Commentaires
1
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Rapport finalMise en place d'un FrameWork Kinect

  1. 1. Dédicaces Parce qu’elle était mon école, mon enseignante, ma conseillère, mon soutien continuel … Je dédie ce travail à ma plus chère du monde, à la femme dont je suis fier d’être son fils A ma mère Madame Krichen Fatma Qu’elle trouve dans cette œuvre le fruit de ses sacrifices et le témoignage de mon grand amour et de ma gratitude la plus sincère. A toute ma famille qui n’a jamais cessé de m’encourager et de procurer l’aide nécessaire pour réaliser ce projet. Amine Magdich
  2. 2. Remerciement D’abord, nous devons grâce à Dieu qui nous a comblées de ses bienfaits et nous a données la force pour accomplir ce travail. J’adresse l’expression de ma très grande reconnaissance à mon professeur encadrant Monsieur Ahmed Kharrat Pour la confiance qu’il m’a investie en acceptant d’encadrer mes travaux, pour ses conseils judicieux et pour l’attention qu’il a apporté à ma mémoire à divers stades de son élaboration. J’aurais également le plaisir de présenter mes chaleureux remerciements au membre du jury ; Monsieur Lotfi Chaari Monsieur Tarek Zlitni D’avoir bien voulu assister à la soutenance de mémoire et d’accepter de juger mon travail. En outre, je remercie Monsieur 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.
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Table des figures Figure 1: Mode d’emploi du Kinect ...................................................................................... 2 Figure 2: Logo de SIFAST .................................................................................................... 5 Figure 3: Les secteurs d'activité du SiFast............................................................................. 6 Figure 4: Organigramme de la société SiFast........................................................................ 7 Figure 5: Schéma démonstratif des différents éléments d'une porte .................................... 9 Figure 6: Schéma général de nombre d’internautes dans le monde..................................... 13 Figure 7: Schéma simplifié de la méthode d’interaction actuel........................................... 15 Figure 8: Schéma de la solution choisi ................................................................................ 18 Figure 9: Le processus Scrum.............................................................................................. 21 Figure 10: Diagramme de contexte statique ...................................................................... 25 Figure 11: Équipe Scrum ................................................................................................... 29 Figure 12: Diagramme des cas d’utilisation global ........................................................... 33 Figure 13: architecture Client/serveur ............................................................................... 34 Figure 14: Représentation de l’architecture 1 tiers............................................................ 35 Figure 15: Représentation de l’architecture N tiers........................................................... 36 Figure 16: Plan du release.................................................................................................. 37 Figure 17: Diagramme de cas d’utilisation Front Office................................................... 40 Figure 18: Diagramme de séquence détaillé du cas d’utilisation « création de la simulation » 48 Figure 19: Diagramme de séquence détaillé du cas d’utilisation « modification des matériaux » 49 Figure 20: Diagramme de séquence détaillé du cas d’utilisation « modification des formes » 50 Figure 21: Diagramme de séquence détaillé du cas d’utilisation « modification des panneaux » 51 Figure 22: Diagramme de séquence détaillé du cas d’utilisation « modification des couleurs » 52 Figure 23: Diagramme de séquence détaillé du cas d’utilisation « modification des vitrages » 53 Figure 24: Diagramme de séquence détaillé du cas d’utilisation « changement d’image » 54 Figure 25: Diagramme de séquence détaillé du cas d’utilisation « changement des accessoires » 55 Figure 26: Représentation des classes ............................................................................... 69
  9. 9. 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
  10. 10. 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
  11. 11. Liste des tableaux Tableau 1: Schéma démonstratif des différents éléments d'une porte ...................................... 9 Tableau 2: Tableau comparative entre les deux modes d’utilisations NUI et GUI.................. 11 Tableau 3: Table de critère entre les deux premières solutions ............................................... 17 Tableau 4: Table de critère entre les cinq solutions................................................................. 17 Tableau 5: Tableau comparatif entre les différents Framework disponible............................. 18 Tableau 6: Backlog produit...................................................................................................... 31 Tableau 7: Backlog du premier sprint (release 1) .................................................................... 39 Tableau 8: Description textuelle du cas d'utilisation « Uploader une image » ........................ 41 Tableau 9: Description textuelle du cas d'utilisation « Prendre une image »........................... 42 Tableau 10: Description textuelle du cas d'utilisation « définir la vue » ................................. 43 Tableau 11: Description textuelle du cas d'utilisation « Choisir les accessoires » .................. 43 Tableau 12: Description textuelle du cas d'utilisation « ajuster la taille »............................... 44 Tableau 13: Description textuelle du cas d'utilisation « Changer Type de cadre » ................. 45 Tableau 14: Description textuelle du cas d'utilisation « Personnaliser les éléments «Couleurs »................................................................................................................................................ 45 Tableau 15: Description textuelle du cas d'utilisation « Choisir la forme » ............................ 46 Tableau 16: Description textuelle du cas d'utilisation « Valider Commande » ....................... 46 Tableau 17: Table liste des objets naturels............................................................................... 56 Tableau 18: Table multiplicité des associations....................................................................... 61 Tableau 19: Table de la représentation des associations.......................................................... 61 Tableau 22: Liste des tables du modèle relationnel ................................................................. 70 Tableau 23: Backlog du premier sprint (release 2) .................................................................. 81 Tableau 24: Description textuelle du cas d'utilisation « Déplacer le curseur »........................ 83 Tableau 25: Description textuelle du cas d'utilisation « engager ».......................................... 83 Tableau 26: Table liste des objets naturels............................................................................... 88 Tableau 27: Table de la représentation des associations.......................................................... 90 Tableau 30: Backlog du second sprint (release 2).................................................................... 95 Tableau 31: Description textuelle du cas d'utilisation « Redimensionner la porte» ............... 98 Tableau 32: Description textuelle du cas d'utilisation « Sélectionner et cliquer sur les éléments interactifs»................................................................................................................................ 99 Tableau 33: Description textuelle du cas d'utilisation « Tourner les objets »......................... 99 Tableau 36: Table de comparaison entre le Web Socket et le REST [13]............................. 122
  12. 12. 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
  13. 13. Introduction générale 1 Introduction générale Depuis quelques années, les consoles de jeux vidéo sortent des chambres des adolescents pour venir s’installer dans les laboratoires de recherche, les centres commerciaux …. Dans le cadre de projet de fin d’étude à l’institut Supérieur d’Informatique et de Multimédia de Sfax, nous allons effectuer un projet portant sur la conception de nouvelles techniques d’interaction avec les mondes 3D (dispositifs de réalité virtuelle) en plus ce projet vise à concevoir et à tester de nouvelles techniques d’interaction 3D avec les mondes virtuels « hybrides1 » au sein d’une société de service comme SiFast2 . Ces nouveaux outils qui permettent de jouer « sans fil » offrent aux joueurs une grande liberté de mouvement. La dernière en date, la Kinect3 , commence à apparaître entre les murs des maisons. C’est la première caméra en trois dimensions destinée au grand public. Grâce à ses caméras couleur et infra-rouge, elle permet de restituer une image en trois dimensions du corps humain, en l’intégrant dans un environnement virtuel. Le joueur commande la console uniquement avec son propre corps. L’utilisation de cette « console sans manette » est tout naturellement en train de dépasser le cercle des joueurs pour faire progressivement son entrée dans d’autres domaines. Elle présente l’avantage, par rapport aux autres consoles, avec ses caméras offrant une vision en profondeur et la reconnaissance du squelette par modélisation, d’analyser le mouvement : angles, espace utilisé, vitesse de mouvement, vitesse angulaire. Alors qu’à l’heure actuelle, les systèmes d’analyse du mouvement sont réservés aux 1 Composite 2 Une Entreprise de Services du Numérique 3 Il s’agit d’une caméra utilisant des techniques d’interaction développées par la société PrieSense, longtemps nommée par le nom de code du projet, « Project Natal »
  14. 14. Introduction générale 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
  15. 15. Introduction générale 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.
  16. 16. 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.
  17. 17. CHAPITRE I : ETUDE PREALABLE 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 5 et ISO 9001 6 et de l’expérience du nearshore, SiFast définit son système qualité tout en conservant sa souplesse et son agilité. Figure 2: Logo de SIFAST I.2.Mission SiFast offre à ses clients, en véritable partenaire, un service de qualité et des solutions innovantes, tout en respectant leurs contraintes et leurs spécificités. Elle leur permet 5 Livre CMMI par l'exemple écrit par François Dufay sorti en 2010 6 Livre Dix clés pour réussir sa certification ISO 9001 écrit par Claude Pinet sorti en 2009
  18. 18. CHAPITRE I : ETUDE PREALABLE 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
  19. 19. CHAPITRE I : ETUDE PREALABLE 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
  20. 20. CHAPITRE I : ETUDE PREALABLE 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).
  21. 21. CHAPITRE I : ETUDE PREALABLE 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âssis Composé 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 ®nitions choisies. Il a également un rôle important dans la résistance à l'effraction et l'isolation.
  22. 22. CHAPITRE I : ETUDE PREALABLE 10 Le vitrage Source 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 ferrage Il 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 seuil de 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
  23. 23. CHAPITRE I : ETUDE PREALABLE 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)
  24. 24. CHAPITRE I : ETUDE PREALABLE 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
  25. 25. CHAPITRE I : ETUDE PREALABLE 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 :
  26. 26. CHAPITRE I : ETUDE PREALABLE 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.
  27. 27. CHAPITRE I : ETUDE PREALABLE 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.
  28. 28. CHAPITRE I : ETUDE PREALABLE 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. 17 Tactile 18 Capable de suivre les mains et les doigts ou les outils similaires de l’utilisateur
  29. 29. CHAPITRE I : ETUDE PREALABLE 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 à
  30. 30. CHAPITRE I : ETUDE PREALABLE 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.
  31. 31. CHAPITRE I : ETUDE PREALABLE 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 19 Unified Modeling Language
  32. 32. CHAPITRE I : ETUDE PREALABLE 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
  33. 33. CHAPITRE I : ETUDE PREALABLE 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.
  34. 34. CHAPITRE I : ETUDE PREALABLE 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.
  35. 35. 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.
  36. 36. Chapitre II : Planification et architecture 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.
  37. 37. Chapitre II : Planification et architecture 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),
  38. 38. Chapitre II : Planification et architecture 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.
  39. 39. Chapitre II : Planification et architecture 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.
  40. 40. Chapitre II : Planification et architecture 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
  41. 41. Chapitre II : Planification et architecture 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
  42. 42. Chapitre II : Planification et architecture 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.
  43. 43. Chapitre II : Planification et architecture 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 Réalisation d’une application de simulation 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. Réalisation d’une application de simulation 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
  44. 44. Chapitre II : Planification et architecture 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 Réalisation d’un Framework Kinect 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. Réalisation d’un Framework Kinect 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. Réalisation d’un Framework Kinect Moyen Élevé La définition des gestes 1 8 Permet la reconnaissance d’un certain type de geste au niveau de l’application. Réalisation d’un Framework Kinect Moyen Élevé
  45. 45. Chapitre II : Planification et architecture 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
  46. 46. Chapitre II : Planification et architecture 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
  47. 47. Chapitre II : Planification et architecture 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é.
  48. 48. Chapitre II : Planification et architecture 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. 24 Backlog du sprint : c’est l’ensemble des user story inclus dans le sprint
  49. 49. Chapitre II : Planification et architecture 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.
  50. 50. 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.
  51. 51. Chapitre III : La réalisation d’une application de simulation 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
  52. 52. Chapitre III : La réalisation d’une application de simulation 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
  53. 53. Chapitre III : La réalisation d’une application de simulation 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.
  54. 54. Chapitre III : La réalisation d’une application de simulation 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.
  55. 55. Chapitre III : La réalisation d’une application de simulation 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é.
  56. 56. Chapitre III : La réalisation d’une application de simulation 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. Enchaînements alternatifs Néant. Post-conditions Néant.
  57. 57. Chapitre III : La réalisation d’une application de simulation 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. Enchaînements alternatifs Néant. Post-conditions Néant. g) Description textuelle du cas d’utilisation « Personnaliser les éléments «Couleurs » Tableau 14: Description textuelle du cas d'utilisation « Personnaliser les éléments «Couleurs » Description Titre Personnaliser les éléments « Couleurs » But Permet à l’utilisateur de changer le couleur des éléments de son porte. Pré-condition l’utilisateur appuie sur la rubrique « Couleurs». Scénario nominal L’application affiche la liste des couleurs disponible. L’internaute appuie sur leur couleur souhaité. L’application affiche la nouvelle simulation dont le couleur modifié. Enchaînements alternatifs Néant. Post-conditions Néant. h) Description textuelle du cas d’utilisation « Choisir la forme »
  58. 58. Chapitre III : La réalisation d’une application de simulation 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. Enchaînements alternatifs Néant. Post-conditions Néant. i) Description textuelle du cas d’utilisation « Valider Commande » Tableau 16: Description textuelle du cas d'utilisation « Valider Commande » Description Titre Valider Commande But Permet de passer son commande à un fournisseur dans le but d’obtenir un devis. Pré-condition l’utilisateur appuie sur le bouton « J’enregistre ma simulation» Scénario nominal L’application affiche un formulaire a rempli. Le mainteneur rempli le formulaire. L’application vérifie les champs et enregistre les informations ainsi la simulation au niveau de la base de données. L’application affiche un message de confirmation.
  59. 59. Chapitre III : La réalisation d’une application de simulation 47 Enchaînements alternatifs Néant. Post-conditions L’application envoie un mail de validation pour le client et un autre pour le fournisseur. I.2.Diagrammes de séquences Le diagramme de séquences permet de cacher les interactions d'objets dans le cadre d'un scénario d'un diagramme de cas d'utilisation. Dans un souci de simplification, nous représentons l'acteur principal à gauche du diagramme, et les acteurs secondaires éventuels à droite du système. Le but étant de décrire comment se déroulent les actions entre les acteurs ou objets. La dimension verticale du diagramme représente le temps, permettant de visualiser l'enchainement des actions dans le temps, et de spécifier la naissance et la mort d'objets. Les périodes d'activité des objets sont symbolisées par des rectangles, et ces objets dialoguent par le biais de messages.
  60. 60. Chapitre III : La réalisation d’une application de simulation 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.
  61. 61. Chapitre III : La réalisation d’une application de simulation 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.
  62. 62. Chapitre III : La réalisation d’une application de simulation 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.
  63. 63. Chapitre III : La réalisation d’une application de simulation 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é.
  64. 64. Chapitre III : La réalisation d’une application de simulation 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é.
  65. 65. Chapitre III : La réalisation d’une application de simulation 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 »
  66. 66. Chapitre III : La réalisation d’une application de simulation 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 »
  67. 67. Chapitre III : La réalisation d’une application de simulation 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.
  68. 68. Chapitre III : La réalisation d’une application de simulation 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
  69. 69. Chapitre III : La réalisation d’une application de simulation 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
  70. 70. Chapitre III : La réalisation d’une application de simulation 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
  71. 71. Chapitre III : La réalisation d’une application de simulation 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
  72. 72. Chapitre III : La réalisation d’une application de simulation 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
  73. 73. Chapitre III : La réalisation d’une application de simulation 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)
  74. 74. Chapitre III : La réalisation d’une application de simulation 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.*
  75. 75. Chapitre III : La réalisation d’une application de simulation 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
  76. 76. Chapitre III : La réalisation d’une application de simulation 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
  77. 77. Chapitre III : La réalisation d’une application de simulation 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
  78. 78. Chapitre III : La réalisation d’une application de simulation 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
  79. 79. Chapitre III : La réalisation d’une application de simulation 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
  80. 80. Chapitre III : La réalisation d’une application de simulation 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.
  81. 81. Chapitre III : La réalisation d’une application de simulation 69 Figure 26: Représentation des classes

×