Front office back office caisse

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA
RECHERCHE SCIENTIFIQUE
UNIVERSITE TUNIS EL MANAR
INSTITUT SUPERIEUR D’INFORMATIQUE
RAPPORT DE STAGE DE FIN D’ETUDES
Présenté en vue de l’obtention du
Diplôme National de Master Professionnel en Sciences et Technologies
Mention : Informatique
Spécialité : Sécurité des Systèmes Informatiques Communicants et Embarqués
Par
Mr.Mohamed Ridha BEN SASSI Mr.Wissem KHITMI
Encadrant professionnel Mr.Abderrazek CHINE
Encadrant académique M.Lobna HSAIRI
Réalisé au sein de (Horizon Ingénierie Informatique)
Année Universitaire 2015/2016
CONCEPTION ET REALISTION D’UNE Front Office
& BackOffice De « GESTION DES POINTS DE VENTES »

Encadrant Entreprise
Encadrant ISI
Signature et cachet :
Signature :

Dédicaces
On dédie ce modeste travail à :
Mes chers parents en guise de reconnaissance et de gratitude pour les sacrifices
qu’ils ont faits.
Mon cher frère pour leur grand amour, avec tous mes vœux de les voir réussir
dans leur vie.
Nos chers amis à qui nous souhaitons le succès, pour l’amitié qui nous a toujours
unis.
A tous ceux qui nous sont chers et toujours dans mon pensée.
Wissem

Dédicaces
A ma mère,
Tu m'as donné la vie, la tendresse et le courage pour réussir. Tout ce
que je peux t'offrir ne pourra exprimer l’amour et la reconnaissance que
je porte.
En témoigne, je t'offre ce modeste travail pour te remercier pour tes
sacrifices et pour l'affectation dont tu m'a toujours entourée
A mon père,
L'épaule solide, l'œil attentif compréhensif et la personne la plus
digne de mon estime et de mon respect.
Aucune dédicace ne saurait exprimer mes sentiments, que Dieu te
préserve et te procure santé et longue vie
Ridha

Remerciements
Comme l’a dit SIR ISAAC NEWTON :
« Si j’ai pu voir plus loin, c’est en montant sur les épaules des géants »
Nous tenons à adresser mon sincère remerciement :
A Mr. Chine ABDERRAZAK et M. Lobna HSAIRI pour avoir bien
voulu nous encadrer, pour tout le temps qu’ils me ont octroyés et pour
Tous les conseils qu’ils me ont prodigués.
Qu’ils trouvent ici l’expression de notre profonde gratitude.
A tous les membres du jury.
A tous ceux qui, directement ou indirectement, ont aidé à la
Finalisation de ce travail.

Sommaire
Introduction Générale …………...……………………………………………………...1
Chapitre 1. Etude Préalable………................................................................................. 3
I. Présentation de l’organisme d’accueil .................................................................... .................. 3
I.1. L’entreprise ........................................................................................................................ 3
I.2. Activités d’Horizon Informatique ...................................................................................... 3
I.3. L’organigramme ................................................................................................................. 4
II. Etude de l’existant…………......................................................................................................... 4
II.1. Analyse de logiciel XL POS................................................................................................ 5
II.2. Analyse de logiciel Ebp Caisse…………............................................................................... 6
II.3. Solution proposée ....................................................................................... ...................... 8
III. Contexte et motivation du projet ............................................................................................. 9
III.1. Contexte ............................................................................................................................ 9
III.2. But de projet ..................................................................................................................... 9
III.3. Travail demandé ............................................................................................................. 10
IV. Langage et méthodologie de conception................................................................................. 10
IV.1. Pourquoi Scrum .................................................................................... .......................... 11
Chapitre 2. Planification et spécification des besoins……...…...................................... 13
I. Capture des besoins.....................................................................................................................13
I.1. Identification des acteurs.................................................................................................... . 13
I.2. Les besoins fonctionnels....................................................................................................... 15
I.3. Les besoins non fonctionnels................................................................................................15
II. Planning du traitement des cas d’utilisation ............................................................................. 17
II.1. Priorités………………………......................................................................................................17
III. Prototypage des interfaces.........................................................................................................17
IV. Pilotage du projet avec Scrum................................................................................................ . 20
IV.1. Outils Scrum..................................................................................................……………......20
IV.2. Equipe et rôles................................................................................................................... 20
IV.3. Le backlog du produit......................................................................................................... 21
IV.4. Diagramme des cas d’utilisation global............................................................................. 25
IV.5. Architecture logique………..................................................................................................26
IV.6. Planification des sprints.................................................................................................... 26
Chapitre 3. Release 1 - Gestion Des Articles.................................................................... 29
I. Le premier sprint.........................................................................................................................29
I.1. Spécification fonctionnelle.................................................................................................. 30
I.1.1. Diagramme des cas d’utilisation.................................................................................. 30

I.1.2. Description textuelle des cas d’utilisation.................................................................... 30
I.2. Conception…………………………..............................................................................................36
I.2.1. Diagramme de séquence système............................................................................... 36
I.2.2. Diagramme des classes................................................................................……………. 38
I.3. Codage………………………….....................................................................................................39
I.4. Test…………………………..........................................................................................................41
I.4.1. Les Test unitaires ……………………................................................................................ 41
II. Le deuxième sprint.....................................................................................................................43
II.1. Spécification fonctionnelle................................................................................................. 44
II.1.1. Diagramme des cas d’utilisation................................................................................. 44
II.1.2. Description textuelle des cas d’utilisation................................................................... 45
II.2. Conception………………………….............................................................................................49
II.2.1. Diagramme de séquence système.............................................................................. 49
II.2.2. Diagramme des classes...............................................................................……………. 51
II.3. Codage…………………………....................................................................................................51
II.4. Test…………………..……..........................................................................................................53
II.4.1. Les Test unitaires …………………….............................................................................. 53
Chapitre 4. Release 2 - Gestion de magasin & Faire des traitements............................ 55
I. Le premier sprint.........................................................................................................................55
I.1.2. Description textuelle des cas d’utilisation..................................................................... 57
I.2. Conception…………………………..............................................................................................60
I.2.1. Diagramme de séquence système................................................................................ 60
I.3. Codage………………………….....................................................................................................62
I.4. Test…………………………..........................................................................................................64
II.2. Conception………………………….............................................................................................69
II.2.2. Diagramme des classes...............................................................................……………. 70
II.3. Codage…………………………....................................................................................................71
II.4. Test…………………..……..........................................................................................................72
II.4.1. Les Test unitaires ……………………............................................................................... 72
Chapitre 5. Release 3 – Administration……................................................................... 75

I. Le premier sprint...............................................................................................z.........................75
I.1.2. Description textuelle des cas d’utilisation..................................................................... 77
I.2. Conception…………………………..............................................................................................78
I.2.1. Diagramme de séquence système............................................................................... 78
I.3. Codage………………………….....................................................................................................81
I.4. Test…………………………..........................................................................................................83
II.2. Conception………………………….............................................................................................87
II.2.2. Diagramme des classes..............................................................................……………. 88
Chapitre 6. La phase de closure………………………………………............................ 90
I. Environnement de développement ............................................................................................90
I.1. Environnement matériel………............................................................................................ 90
I.1.1. Environnement de développement.............................................................................. 90
I.1.2. Environnement de test.................................................................................................. 91
I.1.3. Environnement de production...................................................................................... 91
I.2. Environnement logiciel………………………..............................................................................91
I.2.1. Eclipse……………………………………................................................................................. 91
I.2.2. Sybase POWER AMC...................................................................................……………. 92
I.2.3. Oracle Database 10g.....................................................................................……………. 92
I.3. Langage de programmation…...............................................................................................93
I.3.1. java EE……………………………………................................................................................ 93
I.3.2. UML………………………..................................................................................……………. 94
I.3.3. Le langage SQL……............................................................................................………. 93
I.4. Les Framework….……….........................................................................................................95
I.4.1. JSF2.0……………………………………….............................................................................. 95
I.4.2. Spring…………………….................................................................................................... 95
I.4.3. Hibernate……………………………......................................................................................95
II. Déploiement………......................................................................................................................96
II.1. Diagramme de déploiement............................................................................................... 96
II.2. Les interfaces de l’application……………..............................................................................98
Conclusion et perspectives…….………………………...………….............................. 102
Annexe A……………………….………………………...………….............................. 103

I. Règle 1 : transformation des entités/classes…………................................................................. 103
II. Règle 1 : transformation des associations…..............................................................................103
II.1. Association un à plusieurs................................................................................................ 103
II.2. Association plusieurs à plusieurs……………….…................................................................104
II.3. Association un à un.......................................................................................................... 105
II.4. Transformation de l’héritage………………...........................................................................105
II.5. Transformation de la composition................................................................................... 106
Bibliographie.………………….…………………………………….............................. 107

Liste des Figures
Figure 1.1 : L’organigramme de la société ………………………………………………….4
Figure 1.2: FrontOffice & BackOffice XL POS ………………………………………….5
Figure1.3 : FrontOffice & BackOffice Ebp Caisse ……………………………………………...7
Figure 1.3 : Le processus de Scrum ……………………………………………………………..11
Figure 2.1 : Diagramme de contexte statique…………………………………………………… 14
Figure 2.2 : Page d’authentification (BackOffice)………………………………………………. 18
Figure 2.3 : Tableau de bord (BackOffice) ………………………………………………………18
Figure 2.4 : Fenêtre principale (FrontOffice) ……………………………………………………19
Figure 2.5 : Gestion des articles (BackOffice) ………………………………………………….19
Figure 2.6 : Equipe Scrum ………………………………………………………………………. 21
Figure 2.7 : Diagramme des cas d’utilisation global…………………………………………….. 25
Figure 2.8 : Diagramme de package …………………………………………………………….26
Figure 2.9 : Plan de release ………………………………………………………………………27
Figure 3.1 : Diagramme des cas d’utilisation de premier sprint (release 1) ……………………..31
Figure 3.2 : Exemple d’une histoire utilisateur ………………………………………………… 32
Figure 3.3 : Diagramme de séquence «consulter la liste des sous catégorie» …………………...37
Figure 3.4 : Diagramme de séquence «chercher une famille»…………………………………... 38
Figure 3.5 : Diagramme de classe du premier sprint (release 1) …………………………………39
Figure 3.6 : Code source de la classe de test pour l’histoire «supprimer une famille» …………..42
Figure 3.7 : Cas de succès pour la suppression d’une famille ……………………………………42
Figure 3.8 : Cas d’échec pour la suppression d’une famille ………………………………………43
Figure 3.9 : Diagramme des cas d’utilisation du second sprint (release 1)……………………… 45
Figure 3.10 : Diagramme de séquence système du cas d’utilisation «consulter la liste des articles»
……………………………………………………………………………………………………..49
Figure 3.11 : Diagramme de séquence système du cas d’utilisation «ajouter un article» ………50
Figure 3.12 : Diagramme des classe du second sprint (release 1)………………………………..51

Figure 3.13 : Code source de la classe de test pour l’histoire «ajouter un article»……………… 53
Figure 3.14 : Cas du succès de la classe de test pour l’histoire «ajouter un article» …………….54
Figure 4.1 : Diagramme des cas d’utilisation du premier sprint (release 2) ……………………..57
Figure 4.2 : Diagramme de séquence «supprimer une caisse» …………………………………..60
Figure 4.3 : Diagramme de séquence «chercher un client» ………………………………………61
Figure 4.4 : Diagramme de classe du premier sprint (release 2) …………………………………62
Figure 4.5 : Code source de la classe de test pour l’histoire «modifier un vendeur»…………… 64
Figure 4.6 : Cas de succès pour la modification d’un vendeur …………………………………..65
Figure 4.7 : Diagramme des cas d’utilisation du second sprint (release 2) ………………………66
Figure 4.8 : Diagramme de séquence système du cas d’utilisation «Annuler ticket» …………..69
Figure 4.9 : Diagramme de séquence système du cas d’utilisation «Clôturer service»………… 70
Figure 4.10 : Diagramme des classes du second sprint (release 2)…………………………….. 71
Figure 4.11 : Code source de la classe de test pour l’histoire «supprimer un service»…………. 73
Figure 4.12 : Cas de succès pour la suppression d’un service …………………………………..73
Figure 5.1 : Diagramme des cas d’utilisation du premier sprint (release 3) ……………………..76
Figure 5.2 : Diagramme de séquence «modifier un utilisateur» …………………………………79
Figure 5.3 : Diagramme de séquence «supprimer une fonction»………………………………… 80
Figure 5.4 : Diagramme de classe du premier sprint (release3) ………………………………….81
Figure 5.5 : Code source de la classe de test pour l’histoire «ajouter un utilisateur»…………… 83
Figure 5.6 : Cas de succès pour l’ajout d’un utilisateur…………………………………………. 84
Figure 5.7 : Diagramme des cas d’utilisation du second sprint (release 3)……………………… 85
Figure 5.8 : Diagramme de séquence système du cas d’utilisation «consulter tableau de bord» ..87
Figure 5.9 : Diagramme de séquence système du cas d’utilisation «Authentification» …………88
Figure 5.10 : Diagramme de classe du premier sprint (release3) …………………………………89
Figure 6.1 : Eclipse ……………………………………………………………………………….91
Figure 6.2 : Power AMC ………………………………………………………………………… 92
Figure 6.3 : Oracle Data Base……………………………………………………………………. 92
Figure 6.4 : java EE ………………………………………………………………………………93
Figure 6.5 : UML………………………………………………………………………………… 94
Figure 6.6 : Langage SQL……………………………………………………………………….. 94
Figure 6.7 : JSF …………………………………………………………………………………..95
Figure 6.8 : Spring ……………………………………………………………………………….95
Figure 6.9 : Hibernate…………………………………………………………………………… 96

Figure 6.10 : Diagramme de déploiement de FrontOffice ………………………………………...97
Figure 6.11 : Diagramme de déploiement BackOffice …………………………………………...97
Figure 6.12 : Page d’authentification (BackOffice) …………………………………….………..98
Figure 6.13 : Tableau de Bord (BackOffice) ………………………………………………….….98
Figure 6.14 : Gestion Des Vendeurs (BackOffice) ………………………………………….…..99
Figure 6.15 : Fenêtre d’accueil (FrontOffice) ……………………………………………………99
Figure 6.16 : Fenêtre Principale (FrontOffice)………………………………………………….. 100
Figure 6.17 : Fenêtre d’ajout d’article (FrontOffice) …………………………………………...100
Figure A.1 : Les règles de transformation des associations dépendent de leur cardinalités maximale
………………………………………………………………………………………………….103
Figure A.2 : Règle 2 du passage du modèle conceptuel vers le modèle logique ………………104
Figure A.3 : Règle 3 du passage du modèle conceptuel vers le modèle logique (premier cas) ..104
Figure A.4 : Règle 3 du passage du modèle conceptuel vers le modèle logique (deuxième cas)
……………………………………………………………………………………………….……105
Figure A.5: Règle 3 du passage du modèle conceptuel vers le modèle logique (troisième cas)
…………………………………………………………………………………………………….106
Figure A.6: Règle 3 du passage du modèle conceptuel vers le modèle logique (quatrième cas)..106

Liste des tableaux
Tableau 2.1 : Backlog de produit ………………………………………………………………….21
Tableau 3.1 : Backlog de premier sprint (release 1) ………………………………………………30
Tableau 3.2 : Description textuelle du cas d’utilisation «consulter la liste des types articles»…... 32
Tableau 3.3 : Description textuelle du cas d’utilisation «chercher un type article» …………….. 33
Tableau 3.4 : Description textuelle du cas d’utilisation «ajouter une famille» …………………...33
Tableau 3.5 : Description textuelle du cas d’utilisation «supprimer une catégorie»……………... 34
Tableau 3.6 : Description textuelle du cas d’utilisation «modifier un sous catégorie» …………...35
Tableau 3.7 : Table «Type_Article» ………………………………………………………………40
Tableau 3.8 : Table «Catégorie» …………………………………………………………………..40
Tableau 3.9 : Table «Sous_Catégorie»……………………………………………………….........40
Tableau 3.10 : Table «Famille»……………………………………………………………………40
Tableau 3.11 : Backlog de second sprint (release 1) ……………………………………………... 44
Tableau 3.12 : Description textuelle du cas d’utilisation «ajouter un article»…………………….. 45
Tableau 3.13 : Description textuelle du cas d’utilisation «supprimer une taille»………………… 46
Tableau 3.14 : Description textuelle du cas d’utilisation «modifier une marque» ………………..47
Tableau 3.15 : Description textuelle du cas d’utilisation «chercher un couleur» …………………48
Tableau 3.16 : Table «Article» …………………………………………………………………… 52
Tableau 3.17 : Table «Taille»……………………………………………………………………… 52
Tableau 3.18 : Table «Couleur» ……………………………………………………………………52
Tableau 3.19 : Table «Marque»…………………………………………………………………….52
Tableau 4.1 : Backlog du premier sprint (release 2) ………………………………………………55
Tableau 4.2 : Description textuelle du cas d’utilisation «consulter la liste des vendeurs» ………..58
Tableau 4.3 : Description textuelle du cas d’utilisation «supprimer une caisse» …………………58
Tableau 4.4 : Description textuelle du cas d’utilisation «ajouter un client»……………………… 59
Tableau 4.5 : Table «Vendeur» …………………………………………………………………….63
Tableau 4.6 : Table «Caisse»……………………………………………………………………… 63
Tableau 4.7 : Table «Client» ……………………………………………………………………… 63

Tableau 4.8 : Backlog de second sprint (release 2) ………………………………………………66
Tableau 4.9 : Description textuelle du cas d’utilisation «Annuler un ticket»…………………… 67
Tableau 4.10 : Description textuelle du cas d’utilisation «Clôturer un service»………………... 68
Tableau 4.11 : Table «Service» ………………………………………………………………….72
Tableau 4.12 : Table «Ticket» ……………………………………………………………………72
Tableau 5.1 : Backlog du premier sprint (release3)………………………………………………. 75
Tableau 5.2 : Description textuelle du cas d’utilisation «consulter la liste des utilisateurs»……..77
Tableau 5.3 : Description textuelle du cas d’utilisation «ajouter un utilisateur»………………... 77
Tableau 5.4 : Table «Utilisateur» …………………………………………………………………82
Tableau 5.5 : Table «Groupe»……………………………………………………………………. 82
Tableau 5.6 : Table «Fonction»…………………………………………………………………... 82
Tableau 5.7 : Table «Privilège»………………………………………………………………….. 82
Tableau 5.8 : Backlog de second sprint (release3) ………………………………………………..85
Tableau 5.9 : Description textuelle du cas d’utilisation «Authentification» ……………………..86

1
Introduction Générale
De l’âge de la pierre à nos jours, l’esprit perfectionniste de l’Homme n’a cessé de lui
permettre d’améliorer sa vie quotidienne. Le passage de la mécanique aux domaines
d’informatique, d’électronique, d’automatique et de domotique a révolutionné la vie journalière
de l’être humain. Les nouvelles technologies de l’information et de communication illustrent ce
phénomène.
Aujourd’hui, vu l’intérêt de vouloir gagner en temps, de conserver les données, de limiter le
nombre d’employés et pas mal d’autres raisons, ont poussé petites, moyennes et grandes
entreprises à chercher des solutions informatique capables de répondre à leurs besoins.
Dans ce cadre s’inscrit notre projet de fin d’études qui consiste à réaliser un BackOffice
et un FrontOffice sur mesure de gestion des points de ventes pour n’importe quelle surface
de vente.
Notre Objectif consiste donc à développer un logiciel FrontOffice qui aide les vendeurs de
point de vente à automatiser la tache de la vente, de mode de règlement et de la gestion de
commande et une application web qui représente BackOffice qui aide le responsable du
magasin à automatiser les tâches de la gestion des vendeurs, la gestion des clés et la gestion
des caisses .
Outre l’originalité de l’application à développer, nous essayerons en plus d’utiliser une
méthodologie, issue des méthodes agile, à savoir la méthode SCRUM. Nous essayerons à
travers ce rapport de mettre en évidence les étapes effectuées, dans lesquelles nous avons usé
des avantages de ladite méthode, surtout le plan de productivité et l’efficacité.
Notre rapport se compose de cinq chapitres répartis comme suit :

2
 Le premier chapitre «étude préalable» permet de placer le projet dans son contexte
général. Dans ce premier chapitre introductif nous présentons l’organisme d’accueil
ainsi qu’une brève description du projet.
 Le second chapitre «planning et spécification des besoins» qui consiste en la première
phase dans le cycle Scrum. Dans ce chapitre nous dévoilons les principales exigences de
notre application, nous préparons quelques interfaces graphiques pour mettre notre
application dans son contexte et nous le clôturons par un planning de travail.
 Le troisième chapitre «gestion des articles», le quatrième chapitre «gestion de magasin
et faire traitement» et le cinquième chapitre «administration & états et statistique»
constituent le corps de notre rapport. Ces trois chapitres seront consacrés pour le
développement des trois releases de notre système en respectant les principes
fondamentaux de Scrum.
 Le dernier chapitre « la phase de closue » 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.
En conclusion, nous mentionnons les différents atouts de ce projet et les perspectives
d’améliorations possibles
.

3
Chapitre I. Etude Préalable
Introduction :
L’étude du projet est une démarche stratégique visant à organiser le bon déroulement d’un
projet et d’assurer la conduite de toutes les phases qui le constituent.
Une étude complète et efficace conduit généralement à la réussite d’un projet. Cette étude fera
donc l’objet de notre premier chapitre qui sera consacré à la présentation de l’organisme
d’accueil, et la présentation du projet ainsi que la définition de notre langage et méthodologie
de développement.
I. Présentation de l’organisme d’accueil :
I.1. L’entreprise :
Horizon Ingénierie Informatique (HII) est une équipe d’informaticiens expérimentés à
l’écoute des nouvelles technologies dont l’objectif est de répondre aux besoins des
professionnels et des particuliers et de résoudre leurs problèmes en informatique.
I.2. Activités d’Horizon Informatique :
Les activités d’Horizon Ingénierie Informatique sont très variées, nous puissions mentionner
quelques-unes :
 Conception et développement des logiciels sur mesure.
 Vente, Achats et maintenance des matériels informatique
 Installation et maintenance des réseaux locaux.
 Développement d’applications.
 Rédaction des cahiers de charges.

4
I.3. L’organigramme :
La figure 1.1 montre l’organigramme de la société Horizon Informatique :
II. Etude de l’existant :
L’étude de l’existant permet de déterminer les points faibles et les points forts d’un produit
actuel pour pouvoir déterminer les besoins du client, en vue d’en prendre en considération lors
de la conception et de la réalisation du système de la gestion du point de vente. Dans cette
section, nous présentons une analyse de quelques exemples d’application marchands. Ensuit,
nous formulerons une solution de la problématique.
Figure 2.1 : L’organigramme de la société

5
II.1. Analyse de Logicielle XL POS :
 Aperçu :
La figure 1.2 montre un aperçu sur le logiciel
 URL:
http://www.xlsoft.fr/logiciel-gestion/caisse-gestion/xlpos-caisse-gestion.html
 Description :
XL Pos est un logiciel de caisse et de gestion complète de point de vente. De la caisse, à la
gestion des clients et des stocks en passant par la fidélité, XL Pos est une solution qui
prendre en charge l’ensemble de l’activité du magasin. XL Pos est une solution capable
d’apporter une réponse à la plupart des exigences du client.
 Les points forts :
Figure 1.2: FrontOffice & BackOffice XL POS

6
 Fiable et simple, le client peut utiliser XL Pos en toute sécurité.
 Paramétrable, la personnalisation du clavier de caisse, des documents et des
statistiques en ferrant un outil adapté aux méthodes de travail du client.
 Evolutif, les modules complémentaires permettront d’évoluer tant en superficie
ou nombre de points de ventes, qu’en richesse fonctionnelle. Chaque année
l’équipe XL pos propose un ensemble de nouveautés pour garantir la
performance de son solution.
 Les points faibles
 Partie front Office n’est pas portable.
 Format de ticket n’est pas modifiable
 Oblige une seule thème (thème bleu)
 La documentation en ligne n’est pas la plus complète. Pour avoir accès à toutes
les directives de configuration, il faut télécharger le logiciel pour consulter les
pages de manuels. éventuellement, certaines pages de la FAQ peuvent se
révéler d’un grand secours.
 Cout relativement élevé.
II.2. Analyse de logiciel Ebp Caisse :
 Aperçu :

7
Figure 1.3 : FrontOffice & BackOffice Ebp Caisse
 URL:
http://boutique.ebp.com/
 Description :
Très complet, cet outil 2 en 1 allie dans un seul logiciel : la rapidité d’une caisse enregistreuse
et la puissance d’une gestion commerciale. Il est alors très simple d’encaisser, de gérer les
ventes, de fidéliser les clients et de transférer les données en comptabilité sans aucune
ressaisie.

8
 Les points forts :
 Facilité d’encaissement quotidien
 Un écran de caisse intuitif, personnalisable selon les préférences de travail.
 Réalisation des opérations commerciales
 Epb logiciel permet d’éditer un coupon supplémentaire lors de l’impression du ticket
de caisse. Idéal pour mettre en avant une offre promotionnelle ou communiquer sur un
produit en particulier !
 Simplifiez tous les aspects de la gestion,
 Suivi des stocks, réapprovisionnement, commandes fournisseurs, inventaire … tout
est centralisé dans le logiciel pour une gestion optimale
 Visualisez en un coup d’œil les chiffres clés
 Analyse efficace des activités avec des statistiques détaillées sur les articles, les
clients, le CA...
 Les points faibles :
 Format de ticket n’est pas modifiable
 Ne gère pas la mise en attente d’un ticket
 Oblige une seule thème (thème bleu)
 La documentation en ligne n’est pas la plus complète. Pour avoir accès à toutes les
directives de configuration, il faut télécharger le logiciel pour consulter les pages de
manuels. éventuellement, certaines pages de la FAQ peuvent se révéler d’un grand
secours.
II.3. Solution proposée :
Suite aux inconvénients cités dans la section précédente, nous proposons la mise en place d’un
logiciel de gestion du point de vente qui automatise les différentes activités du magasin tel que
la gestion de la vente (règlement, remise, commentaire) et la gestion de magasin (caisse,
vendeur, etc.) de point de vente ainsi que la gestion du stock.

9
III. Contexte et motivation du projet :
Le présent projet intitulé «Développement d’une Back Office et Front Office de gestion des
points de ventes (GPVhorizon).
III.1. Contexte :
Comme on l’a cité précédemment, Horizon Ingénierie Informatique n’est pas une société
consommatrice, elle est plutôt productrice. Toutes les applications développées sont
destinées alors à la vente. L’application en question s’agit d’une commande d’une
surface de vente (magasin). Il s’agit donc d’une application de gestion de point de
vente composée par deux partie (Back Office et Front Office ) , cette solution doit être
capable d’automatiser les taches et d’améliorer la productivité de point de vente tout en
respectant les exigences de client .
III.2. But de projet :
La gestion de points de vente est souvent compliquée. Gestion de stocks multiples, personnels
aux horaires variables, gestion des caisses ou encore du service après-vente sont autant de défis
qu’il faut relever au quotidien.
Dans cette situation, il est primordial de bien organiser afin de répondre à ces exigences tout en
garantissant la rentabilité de magasin.
Il faut pouvoir évaluer rapidement les disponibilités de stocks, les entrées et sorties prévues afin
de répondre dans les meilleurs délais aux demandes des clients.
Pour faire face à toutes ces exigences, vous devez posséder un système d’information
souple, adapté et évolutif. Un système qui vous permettra de suivre en quelques clics
l’activité et de gérer un magasin.
Une réaction rapide aux problèmes sera un atout de plus pour garantir la satisfaction de
des clientèles.
L’objet de ce projet est la conception et la réalisation d’une application web (Back Office) et une

10
application Desktop (front Office) fiable, agréable et simple d’utilisation, pour la gestion des
stocks, la gestion du magasin et la gestion de vente.
III .3. Travail demandé :
Notre travail consiste à concevoir et à développer une application informatique qui permettra la
gestion des clients, des vendeurs, des clés, des caisses, du stock, de cartes de fidélité, génération
des rapports et statistiques, génération des journaux tickets, gérer les promotions, faire des
traitements (annulation ticket, clôturer service…) , gestion de Vente( appliquer remise , règlement
... ).
IV. 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 UML 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 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

11
De conception et de développement que nous devons l’adopter
IV.1. Pourquoi SCRUM :
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,
 Un Sprint aboutit toujours sur la livraison d’un produit partiel fonctionnel appelé
incrément.
La figure 1.4 illustre le principe de Scrum.
Figure 1.4 : Le processus de Scrum

12
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 prograrnrning ( XP ) 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.
Conclusion :
Dans ce chapitre, nous avons présenté le cadre générale de notre projet en déterminant la
problématique et en proposant une solution envisagé pour faire face à la situation courante. Nous
avons dévoilé le langage et la méthodologie de conception qui seront utilisés dans les prochains
chapitres de ce rapport et nous avons argumenté notre choix.

13
Chapitre II. Planification et
Spécification des besoins
Introduction
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.
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
Tout simplement un acteur est une entité physique (personne) ou abstraite (logiciel) capable

14
d’utilisée le système afin de répondre à un besoin bien définit. Les acteurs de notre application
sont:
 Administrateur Système : Peut-être le Gérant ou le responsable du magasin, c’est la
personne possédant le privilège du plus haut niveau. Cet acteur est capable de manipuler
toutes les fonctionnalités proposées par l’application notamment l’ajout des articles,
attribution des droits d’accès aux autres acteurs, etc. II s’agit principalement le
responsable de point de vente.
 Agent comptable : Peut-être un comptable ou responsable financier.
 Vendeur : Il s’agit du vendeur du point de vente.
b. Diagramme de contexte statique
Ce diagramme d’UML, illustré par la figure 2.1, 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é.
Figure 2.1 : Diagramme de contexte statique

15
Pour expliquer le diagramme présenté par la figure 2.1, nous pouvons dire qu’à un instant donné
nous pouvons avoir zéro ou deux administrateurs qui manipule l’application, et zéro ou
plusieurs agent comptable et vendeur 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» [1]
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:
 Gestion de Vente : Consiste à gérer toutes les processus de vente (lecture article
via son code barre, faire de remise, mode de règlement …)
 Gestion des Tickets : Consiste à gérer les tickets (annulation ticket, mettre un
ticket en attente …)
 Gestion de magasin : Consiste à gérer les caisses, les vendeurs, les clients.
 Gestion des Articles : Consiste à gérer les catégories, les sous catégories, les
familles, les types article, les couleurs et les tailles
 Consulter des statistiques : Consiste à consulter le tableau de bord, les états x
services, le meilleur vendeur, chiffre d’affaire pour une période de temps
 Gestion de sécurité : Attribution des droits d’accès (clés) aux vendeurs
I.3. Les besoins non fonctionnels :
Ces besoins sont les contraintes techniques exigées et les fonctionnalités nécessaires pour
rendre le logiciel plus performant et qui se résument généralement en :
 La simplicité : plus une application de gestion des points de ventes est simple dans
l’apprentissage et dans l’utilisation, plus ses fonctionnalités sont utilisées.
 L’accessibilité de l’application et la facilité d’administration : Une application de
gestion des points de ventes permet de gérer trois principales fonctions vitales
d’administration de magasin :

16
 La gestion du stock : répartir et organiser les articles dans des catégories,
sous-catégories, familles, types articles, marques.
 La gestion les éléments du magasin : qui permet la gestion des vendeurs, des
clés et des caisses.
 La gestion des statistiques, des rapports et des journaux : c’est à dire
fournisse des statistiques sur les ventes, des rapports services et des journaux de
tickets et de paiements.
 Le paramétrage et l’ergonomie : une application de gestion des points de ventes doit
avoir plusieurs fenêtres adaptables aux types d’utilisateurs. En effet, les interfaces,
les fonctionnalités et les profils doivent être modifiables et ajustables aux besoins.
 L’économie : il est important que l’application soit plus concurrent économiquement
de point de vue ressources utilisés (connexion à la base de données…).
 L’évolutivité : il est intéressant que l’application assure un pouvoir d’évolution, de
développement et d’amélioration au cours du temps et ce selon les besoins des
utilisateurs. Le code doit être clair pour permettre des futures évolutions.
 La sécurité : il est nécessaire que l’application gère :
 La confidentialité : l’information échangée entre deux correspondants ne peut
pas être consultée par un tiers
 L’authentification : les personnes utilisant une ressource correspondent aux
groupes d’utilisateurs.
 La disponibilité : les données ainsi que les ressources du système
d’information sont accessibles par ceux qui ont besoin à chaque fois qu’ils ont
l’utilité.
 L’intégrité : l’information n’est modifiée que par les personnes ayant le
droit et de façon volontaire.
 Le contrôle d’accès : une ressource n’est accessible que par les personnes
autorisées.

17
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, nous disons 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 des remises sur des articles tant que nous n’avons pas encore terminé la gestion des
articles et celles des catégories. Par conséquent, nous pouvons dégager trois niveaux de priorité
qui sont: priorité haute, moyenne et faible.
III. Prototypage des interfaces :
Dans le domaine du web, une technique est apparue et prend une place très importante dans le
développement des applications Web; il s’agit du prototypage. Cette technique consiste à
préparer quelques interfaces graphiques de l’application en utilisant un outil de conception de
prototypes afin de mesurer le degré de satisfaction du client par rapport à la compréhension du
projet par le développeur. L’interaction qui se produit entre l’utilisateur final et le
développeur, à la suite de la discussion sur ces interfaces, permet d’ajuster les besoins et de les
concevoir de manière précise et exacte. En effet, les interfaces graphiques font que l’utilisateur
final soit plus interactif, précis et le poussent à mieux s’exprimer quant à ses attentes.
Quelques interfaces réalisées avec l’outil MokFlow4
sont illustrées par les figures : Figure 2.2,
Figure 2.3, Figure 2.4, Figure 2.5, Figure 2.5.

18
Figure 2.2 : Page d’authentification (BackOffice)
Figure 2.3 : Tableau de bord (BackOffice)

19
Figure 2.4 : Fenêtre principale (FrontOffice)
Figure 2.5 : Gestion des articles (BackOffice)

20
IV. 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 temps et les artefacts.
IV.I. 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 iceScrum.
IV.2. Equipe 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 ». [2] 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 maîtriser
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 infographistes, des testeurs, etc.
Dans le contexte de notre projet, Abderazek Chine sera à la fois le propriétaire et le directeur
de produit puisqu’il satisfait les différents prés requis de ces deux rôles et nous formons

21
nous-mêmes les deux membres de l’équipe Scrum (voir Figure 2.6).
Figure 2.6 : Equipe Scrum
IV.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 2.1 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 il 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 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.
Tableau 2.1 : Backlog de produit

22
Nom Effort Rang Description Thème Risque Priorité
Ajouter un
article
1 30 En tant qu’administrateur
je peux ajouter un article
afin de renforcer mes
ventes
Gestion
des articles
Faible Élevé
Mettre à jour les
articles
je peux mettre à jour un
article afin de garder
l’intégrité de mes
données
Gestion
des articles
Faible Élevé
Ajouter un
administrateur
je peux ajouter un admin
afin de renforcer mes
ressources humaines du
point de vente
Gestion
des
utilisateurs
Faible Moyen
Mettre à jour un
administrateur
admin afin de garder
données
Gestion
des
utilisateurs
Faible Moyen
Ajouter une
catégorie
je peux ajouter une
catégorie afin d’organiser
mes articles
Gestion
des
catégories
Faible Élevé
Mettre à jour
une catégorie
je peux mettre à jour une
catégorie afin de garder
données
Gestion
des
catégories
Faible Élevé

23
Nom Effort Rang Description Théme Risque Priorité
Ajouter un
vendeur
je peux ajouter un
vendeur afin de renforcer
les ressources humaines
du point de vente
Gestion
des
vendeurs
Faible Élevé
Mettre à jour un
vendeur
vendeur afin de garder
données
Gestion
des
vendeurs
Faible Élevé
Ajouter une
caisse
je peux ajouter une caisse
afin de renforcer les
ressources matérielles de
point de vente
Gestion
des caisses
Faible Élevé
Mettre à jour
une caisse
caisse afin de garder
données
Gestion
des caisses
Faible Élevé
Ajouter un
client
je peux ajouter un client
afin de contrôler les
achats et les points de
fidélités
Gestion
des clients
Moyen Élevé
Mettre à jour un
client
caisse afin de garder
l’intégrité de mes données
Gestion
des clients
Moyen Élevé

24
Nom Effort Rang Description Théme Risque Priorité
Ajouter une
famille
je peux ajouter une
famille afin d’organiser
mes articles
Gestion
des
familles
Faible Élevé
Mettre à jour
une famille
famille afin de garder
données
Gestion
des
familles
Faible Élevé
Authentification 3 1 En tant qu’administrateur
je peux faire une
authentification afin
d’accéder à mon espace
de travail
-------- Faible Faible
Lister les
articles
je peux lister les articles
afin de sélectionner un
article
Gestion
des articles
Faible Élevé
Consulter
tableau de bord
je peux consulter le
tableau de bord afin
d’assurer une meilleur
gestion des ressources
Statistique
et états
Moyen Faible
Annuler un
ticket
je peux annuler un ticket
afin de prendre le
contrôle sur les tickets
Faire des
traitements
Moyen Faible

25
IV.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 nous utilisons le diagramme des cas d’utilisation du langage de modélisation UML.
Dans la Figure 13, tous les cas d’utilisation nécessitent une authentification préalable.
Figure 2.7 : Diagramme des cas d’utilisation global

26
IV.5. Architecture logique :
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 : Architecture logique, l’architecture physique, architecture logicielle, etc. Dans
ce paragraphe nous nous intéressons à l’architecture logique traduite par le diagramme de
package en terme d’UML qui est illustré par la figure 2.8.
Figure 2.8 : Diagramme de package
IV .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 Sprints[7]
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
trois releases :

27
 Le premier sprint sera nommé gestion des articles (catégorie, sous catégorie, famille,
marque, couleur, taille).
 Le second sprint sera pour la gestion de magasin (vendeur, caisse, client ...) et pour faire
des traitements (clôturer caisse, annuler ticket, consulter états stock ...),
 Le troisième sera intitulé administration (groupe, utilisateur, droit d’accès ...) et états et
statistique (tableau de bord, recap de vente, journal de ticket annulé ...),
Pour notre cas la durée de 20 jours pour un sprint semble adéquate.
La Figure 14 résume notre planning de travail.
Figure 2.9 : Plan de release

28
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 logique ainsi que le plan de release de notre projet.

29
Chapitre 3. Release 1-
Gestion Des Articles
Introduction :
Le terme release peut être défini comme une version distribuée d’une application 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, chacun ayant une vélocité de 20 jours.
Tout au long de ce chapitre, nous allons traiter les histoires utilisateurs de nos sprints pour
produire un incrément potentiellement livrable.
I. Le premier sprint :
Le sprint est le cœur de Scrum. Il s’agit d’un bloc de temps durant lequel un incrément du
produit sera réalisé. Tous les sprints d’une release ont une durée constante et ne se
chevauchent jamais, c’est-à-dire qu’un sprint ne peut pas démarrer tant que le précédent n’est
pas encore terminé.
Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir le but de ce
dernier. Ce but doit être défini en terme métier et non pas en terme technique pour qu’il soit
compréhensible par les membres en dehors de l’équipe. Il s’agit de répondre à une question
fondamentale «pourquoi faisons-nous ce sprint?». Suite à une conversation entre le Product
Owner et l’équipe Scrum, nous avons décidé le but suivant: «terminer la partie qui concerne la
gestion des articles du point de vente».

30
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 2 résume donc le backlog de notre premier sprint:
Tableau 3.1 : Backlog de premier sprint (release 1)
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 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. Diagramme des cas d’utilisation :
Dans la Figure 3.1 nous illustrons le diagramme des cas d’utilisation globaux pour ce premier
sprint
Histoire utilisateur Estimation
Lister les types des articles 2
Ajouter un type d’article 2
Modifier un type d’article 1
Lister les familles 1
Ajouter une famille 2
Modifier une famille 2
Lister les catégories 2
Ajouter un catégorie 2
Modifier un catégorie 2
Lister les sous catégorie 1
Ajouter un sous catégorie 1
Modifier un sous catégorie 2

31
Figure 3.1 : Diagramme des cas d’utilisation de premier sprint (release 1)
Dans ce diagramme, certains cas d’utilisation à l’instar « chercher une famille », « chercher une
catégorie », etc. ne figurent pas dans le backlog de notre sprint pour une simple raison, avec
Scrum, une des pratiques intéressante consiste à découper une histoire en un ensemble de
tâches. La différence entre une histoire et une tâche c’est que l’histoire est sous-produit livrable
qui intéresse le directeur de produit. La figure 3.2 illustre un exemple :
Lister les catégories

32
Figure 3.2 : Exemple d’une histoire utilisateur
I.1.2. Description textuelle des cas d’utilisation :
Pour rendre notre diagramme des cas d’utilisation plus lisible et afin de décrire le
comportement de notre système, nous présentons la description textuelle des principaux cas
d’utilisation.
A. Cas d’utilisation : Gestion des types articles
 Description textuelle du cas d’utilisation « consulter la liste des types article »
(voir tableau 3.2)
Tableau 3.2 : Description textuelle du cas d’utilisation «consulter la liste des types articles»
Cas d’utilisation Consulter la liste des types articles
Acteurs Administrateur, Agent comptable, Vendeur
Pré - condition Une authentification préalable
Post - condition La liste des types article est affichée sur l’écran
Scénario nominal 1-l’acteur demande l’affichage de la liste des
types articles
2-le système affiche la liste des types articles
Scénario alternatif 2-a-aucun résultat
2-a-1- le système affiche un message de type
« aucun résultat trouvé »
 Description textuelle du cas d’utilisation « chercher un type article » (voir
tableau 3.3)

33
Tableau 3.3 : Description textuelle du cas d’utilisation «chercher un type article»
B. Cas d’utilisation : Gestion des Familles
 Description textuelle du cas d’utilisation « ajouter une famille » (voir Tableau
3.4)
Tableau 3.4 : Description textuelle du cas d’utilisation «ajouter une famille»
Cas d’utilisation Ajouter une famille
Acteurs Administrateur
Pré-condition Une authentification préalable
Formulaire d’ajout disponible
Post-condition La liste des familles est affichée sur l’écran
Scénario nominal 1-l’administrateur demande le formulaire
d’ajout
2-le système affiche les formulaires
3-l’administrateur rempli les champs
nécessaire et valide
Cas d’utilisation Chercher un type article
Formulaire de recherche disponible
Post-condition La liste des types articles est affichée sur l’écran
Scénario nominal 1-l’acteur saisi les critères de recherche
2-le système cherche les types article aux critère
répondant aux critères mentionnés
3-le système affiche la liste des types articles
2-a-1- le système affiche un message de type «
aucun résultat correspondant à vos critères,
essayer de nouveau »
2-a-2-reprise de l’étape 1 du scénario nominal

34
4-le système enregistre la nouvelle famille et
affiche un message de succès
4-a-l’administrateur saisie des données
manquantes
4-a-1- le système affiche un message d’erreur
4-a-2-reprise de l’étape 1 du scénario
nominal
4-b-la famille existe déjà
4-b-1-le système demande à l’administrateur
de Modifier les données saisies
4-b-2-reprise de l’étape 3 du scénario
nominal
C. Cas d’utilisation : Gestion des catégories
 Description textuelle du cas d’utilisation «supprimer une catégorie» (voir
Tableau 3.5)
Tableau 3.5 : Description textuelle du cas d’utilisation «supprimer une catégorie»
Cas d’utilisation Supprimer une catégorie
La catégorie existant
Post - condition La liste des catégories est affichée sur l’écran
Scénario nominal 1-l’administrateur choisi la catégorie à
supprimer
2- le système affiche un message de
confirmation
3-l’administrateur valide son choix

35
4-le système supprime la catégorie
5-le système affiche un message de succès
Scénario alternatif 3-a-l’administrateur annule son choix
3-a-1-le système annule la suppression
C. Cas d’utilisation : Gestion des sous catégories
 Description textuelle du cas d’utilisation «modifier un sous catégories » (voir le
Tableau 3.6)
Tableau 3.6 : Description textuelle du cas d’utilisation «modifier un sous catégorie»
Cas d’utilisation Modifier un sous catégorie
Le sous catégorie existant
Post-condition Les informations ont bien été mises à jour
Scénario nominal 1-l’administrateur choisi le sous catégorie à
modifier
2-le système affiche le formulaire de
modification
3-l’administrateur modifie les informations et
valide
4-le système vérifie les données saisies
5-le système enregistre les données et affiche
un message de succès
Scénario alternatif 4-a-l’administrateur saisie des données
manquantes
4-a-1-le système affiche un message
d’erreur
nominal
4-b- le libellé de sous catégorie existe déjà
4-b-1-le système demande à
l’administrateur de modifier les données
saisies

36
nominal
I.2. Conception :
La conception est la deuxième activité dans un sprint. Elle se traduit par le diagramme de classe
et le diagramme de séquence d’UML.
1.2.1. Diagramme de séquence système
Pour schématiser la vue comportementale de notre système informatique, nous faisons recours
au diagramme de séquence d’UML. Ce diagramme permet de présenter les interactions entre
l’acteur et le système avec des messages présentés dans un ordre chronologique .Le digramme
de séquence système traite le système informatique comme étant une boite noire. Le
comportement du système est décrit vu de l’extérieur sans avoir d’idée sur comment il le
réalisera.
En nous référant aux descriptions textuelles dans la section précédente, nous présentons les
diagrammes de séquences systèmes adéquats. Sur la base de ces descriptions, nous pouvons
constater que certains cas d’utilisations sont similaires à l’instar de la consultation des types
articles, la consultation des familles, etc. c’est pour cette raison que nous avons choisi de
sélectionner quelques exemples pour les traiter.
A. Diagramme de séquence système du cas d’utilisation « consulter la liste des catégorie»
Le cas d’utilisation consulter la liste des catégorie est similaire au cas d’utilisation suivant :
consulter la liste des familles, consulter la liste des sous catégorie, consulter la liste des types
articles.
La figure 3.3 illustre le diagramme de séquence «consulter la liste des catégorie»

37
Figure 3.3 : Diagramme de séquence «consulter la liste des sous catégorie»
B. Diagramme de séquence système du cas d’utilisation « chercher une famille»
Pour chercher une famille, l’administrateur doit s’authentifier dans un premier lieu en utilisant
son login et son mot de passe. Par la suite, il choisit les critères de recherche correspondant à
ces besoins (voir figure 3.4).

38
Figure 3.4 : Diagramme de séquence «chercher une famille»
1.2.2. Le diagramme des classes :
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. (Voir
Figure 3.5)

39
Figure 3.5 : Diagramme de classe du premier sprint (release 1)
I.3. Codage :
Les travaux menés dans cette activité se résument tout simplement dans l’implémentation et la
réalisation des histoires utilisateurs analysés lors des étapes précédentes. Pour notre cas, nous
nous intéresserons seulement au schéma de la base de données.
Pour construire le schéma de base de données de notre application, nous devons appliquer
certaines règles pour passer vers un schéma relationnel. Ces règles sont bien définies dans
l’annexe A.
Dans ce qui suit, nous présentons les tables de notre base de données (voir Tableau 3.7,
Tableau 3.8 Tableau 3.9 et le Tableau 3.10) tout en tenant compte du type et des contraintes de
leurs champs.

40
Champs Types Contraintes
TA_CODE VARCHAR(20) PRIMARY KEY
TA_LIBELLE VARCHAR(20) ---
TA_IMP VARCHAR(20) ---
Tableau 3.7 : Table «Type_Article»
CAT_CODE VARCHAR(20) PRIMARY KEY
CAT_LIBELLE VARCHAR(20) ---
Tableau 3.8 : Table «Catégorie»
SCAT_CODE VARCHAR(20) PRIMARY KEY
CAT_CODE VARCHAR(20) PRIMARY KEY
SCAT_LIBELLE VARCHAR(20) NOT NULL
Tableau 3.9 : Table «Sous_Catégorie»
FAM_CODE VARCHAR(20) PRIMARY KEY
FAM_LIBELLE VARCHAR(20) ---
Tableau 3.10 : Table «Famille»

41
I.4. Test :
Les activités de test constituent un axe très important dans le cycle de développement d’un
logiciel. Ils permettent de détecter les erreurs afin de les corriger et d’assurer la qualité du
logiciel fourni.
Contrairement aux cycles de développement séquentiel, avec la méthodologie agile, le test
n’est pas une phase qui se déroule après la fin de développement. En effet, les tests seront
intégrés dès le début du premier sprint jusqu’à la livraison du produit final. En outre, la qualité du
logiciel n’est pas négligeable, c’est dans ce cadre que Scrum doit être complété par les bonnes
pratiques d’ingénierie techniques du logiciel. Parmi ces pratiques, les tests unitaires.
1.4.1. Les tests unitaires
Le principe de cette pratique est d’écrire les tests avant même d’écrire le code et de profiter par
la suite de l’existence des tests automatiques pour l’amélioration et le remaniement du code.
Cette technique permet aux programmeurs de rester simples au niveau du code et de s’assurer
de son bon fonctionnement après des changements.
Dans ce paragraphe, nous avons choisi de tester deux histoires utilisateurs qui sont: l’ajout
d’une catégorie et la suppression d’une famille. Pour la création des tests unitaires de ces
histoires, nous avons eu recours à la bibliothèque JUnit.
 Test unitaire pour l’histoire «supprimer une famille»
Pour tester la suppression d’une famille, nous avons choisi de suivre la démarche suivante :
1. Compter le nombre de familles existantes et vérifier que c’est égal à 3
2. Supprimer une famille
3. Compter de nouveau le nombre de famille et vérifier que c’est égal à 2
La première capture écran (Figure 3.6) illustre le code de la classe de test.

42
Figure 3.6 : Code source de la classe de test pour l’histoire «supprimer une famille»
La deuxième capture écran (Figure 3.7) illustre le cas de succès de notre test. Cette figure nous
montre que notre méthode est bien fonctionnelle.
Figure 3.7 : Cas de succès pour la suppression d’une famille

43
La dernière capture écran (Figure 3.8) illustre le cas d’échec. Dans cette figure l’oracle13
était 2
lors que la méthode nous renvoie 3.
Figure 3.8 : Cas d’échec pour la suppression d’une famille
II. Le deuxième sprint
En partant sur le même principe que le sprint précédent, nous commençons par définir le but de
notre second sprint. Suite à une conversation entre le Product Owner et l’équipe Scrum, nous
avons décidé le but suivant: « terminer la partie qui concerne la gestion des articles de point de
vente ». Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles
histoires inclure dans ce dernier.
Le Tableau 3.11 résume donc le backlog de notre second sprint :

44
Tableau 3.11 : Backlog de second sprint (release 1)
Dans le Tableau 3.11, nous pouvons constater que les histoires utilisateur «lister les couleur »,
«ajouter un couleur» et « modifier une marque » ne figurent pas dans le backlog de produit. En
effet, notre backlog de produit initial ne couvre pas toutes les fonctionnalités requises et c’est
pour cette raison que nous aurons des nouvelles fonctionnalités au fur et mesure de notre
avancement. En plus, nous pouvons constater que les vélocités de nos histoires ont changé par
rapport à l’estimation initiale tout en gardant la même durée que le sprint précédent.
II.1. Spécification fonctionnelle :
Pour la spécification fonctionnelle de ce sprint, nous commençons par le diagramme des cas
d’utilisation.
II.1.1. Diagramme des cas d’utilisation
Dans la Figure 3.9 nous illustrons le diagramme des cas d’utilisation global pour ce second
sprint. En respectant toujours le même principe que le sprint précédent, nous avons découpé
certaines histoires utilisateurs en un ensemble de tâches.
Lister les articles 1
Ajouter un article 2
Modifier un article 1
Lister les couleurs 1
Ajouter un couleur 1
Modifier un couleur 2
Lister les marques 1
Ajouter une marque 2
Modifier une marque 2
Lister les tailles 2
Ajouter une taille 2
Modifier une taille 3

45
Figure 3.9 : Diagramme des cas d’utilisation du second sprint (release 1)
II.1.2. Description textuelle des cas d’utilisation
Nous allons maintenant décrire chacun des cas d’utilisation énuméré dans le paragraphe
précédent en identifiants les acteurs et les différents scénarios possible.
A. Cas d’utilisation : Gestion des articles
 Description textuelle du cas d’utilisation« Ajouter un article » (voir Tableau 3.12)
Tableau 3.12 : Description textuelle du cas d’utilisation «ajouter un article»
Cas d’utilisation Ajouter un article
Post-condition La liste des articles est affichée sur l’écran
d’ajout

46
4-le système enregistre le nouvel article et
manquantes
nominal
4-b-l’article existe déjà
nominal
B. Cas d’utilisation : Gestion des Tailles
 Description textuelle du cas d’utilisation «supprimer une taille » (voir Tableau 3.13)
Tableau 3.13 : Description textuelle du cas d’utilisation «supprimer une taille»
Cas d’utilisation Supprimer une taille
La taille existant
Post - condition La liste des tailles est affichée sur l’écran
Scénario nominal 1-l’administrateur choisi la taille à supprimer

47
confirmation
4-le système supprime la taille
C. Cas d’utilisation : Gestion des marques
 Description textuelle du cas d’utilisation «modifier une marque» (voir le
Tableau 3.14)
Tableau 3.14 : Description textuelle du cas d’utilisation «modifier une marque»
Cas d’utilisation Modifier une marque
La marque existant
Post-condition Les informations ont bien été mises à jour
Scénario nominal 1-l’administrateur choisi la marque à modifier
2-le système affiche le formulaire de
modification
3-l’administrateur modifie les informations et
valide
4-le système vérifie les données saisies
5-le système enregistre les données et affiche
un message de succès
manquantes
4-a-1-le système affiche un message
d’erreur
nominal

48
4-b- le libellé d’une marque existe déjà
4-b-1-le système demande à
l’administrateur de modifier les données
saisies
nominal
C. Cas d’utilisation : Gestion des Couleurs
 Description textuelle du cas d’utilisation «chercher un couleur » (voir Tableau 3.15)
Tableau 3.15 : Description textuelle du cas d’utilisation «chercher un couleur»
Cas d’utilisation Chercher un couleur
Post-condition La liste des couleurs est affichée sur l’écran
Scénario nominal 1-l’acteur saisi les critères de recherche
2-le système cherche les couleurs répondants
aux critères mentionnés
3-le système affiche la liste des couleurs
2-a-1- le système affiche un message de
type « aucun résultat correspondant à vos
critères, essayer de nouveau »
nominal
II.2. Conception
A ce niveau, nous commençons par le diagramme de séquence système des différents cas
d’utilisation déjà détaillés dans la section précédente.

49
II.2.1. Diagramme de séquence système
constater que certains cas d’utilisations sont similaires à l’instar de la consultation des couleurs,
la consultation des taille, etc. c’est pour cette raison que nous avons choisir de sélectionner
quelques exemples.
A. Diagramme de séquence système du cas d’utilisation «consulter la liste des
articles»
Le cas d’utilisation consulter la liste des articles (voir figure 3.10) est similaire au cas
d’utilisation suivant: consulter la liste des couleurs, consulter la liste des taille, consulter la liste
des marques.
Figure 3.10 : Diagramme de séquence système du cas d’utilisation «consulter la liste des articles»
B. Diagramme de séquence système du cas d’utilisation « ajouter un article» :
L’ajout d’un article (voir Figure 3.11) est similaire au cas d’utilisation suivant: ajouter un
couleur, ajouter une marque et ajouter une taille.

50
Figure 3.11 : Diagramme de séquence système du cas d’utilisation «ajouter un article»

51
II.2.2. Diagramme des classes
Après tout le travail de spécification et de conception, nous pouvons maintenant construire le
nouvel incrément de notre diagramme des classes en ajoutant les différents éléments (classes,
associations, attributs, etc.) déduits à partir des activités précédentes (voir figure 3.12)
Figure 3.12 : Diagramme des classe du second sprint (release 1)
II.3.Codage
Après avoir construit le nouveau diagramme de classe pour ce sprint et en appliquant les règles
de passage vers le schéma logique de l’application, nous obtenons le schéma de la base de
données illustré par les Tableaux (Tableau 3.16, Tableau 3.17, Tableau 3.18, Tableau 3.19)

52
ART_CODE VARCHAR(20) PRIMARY KEY
ART_LIBELLE VARCHAR(20) ---
ART_BARRE VARCHAR(20) ---
CAT_CODE VARCHAR(20) NOT NUL
SCAT_CODE VARCHAR(20) FOREIGN KEY
FAM_CODE VARCHAR(20) FOREIGN KEY
TAILLE_CODE VARCHAR(20) FOREIGN KEY
MARQ_CODE VARCHAR(20) FOREIGN KEY
STK_ALRT NUMBER(10) ---
Tableau 3.16 : Table «Article»
TA_CODE VARCHAR(20) PRIMARY KEY
Tableau 3.17 : Table «Taille»
COU_CODE VARCHAR(20) PRIMARY KEY
COU_LIBELLE VARCHAR(20) UNIQUE
Tableau 3.18 : Table «Couleur»
MRQ_CODE VARCHAR(20) PRIMARY KEY
MRQ_LIBELLE VARCHAR(20) UNIQUE
Tableau 3.19 : Table «Marque»

53
II.4. Test :
En partant toujours du même principe que le sprint précédent, et en appliquant les bonnes
pratiques d'ingénierie logicielle inspirée de la méthodologie extrême programming (XP), nous
commençons par les tests unitaires de l'histoire utilisateur « ajouter un article »
II.4.1. Tests unitaires :
Dans ce paragraphe, nous testons toujours nos histoires utilisateur en utilisant la bibliothèque
JUnit.
 Test unitaire pur l’histoire « ajouter un article»
Pour tester l’ajout d’un article, nous avons choisi de respecter la démarche suivante :
1. Ajouter un article
2. Récupérer le dernier article ajouté
3. Comparer les attributs de l’article ajouté et celles de l’article récupéré.
La première capture écran (Figure 3.13) illustre le code source de la classe de test.
Figure 3.13 : Code source de la classe de test pour l’histoire «ajouter un article»

54
La figure 3.14 illustre le cas de succès pour l’ajout d’un nouvel article .Cette figure nous montre
que notre méthode est bien fonctionnelle.
Figure 3.14 : Cas du succès de la classe de test pour l’histoire «ajouter un article»
Conclusion
Le résultat d’un release est un produit livrable au client contrairement au résultat d’un sprint qui
est un produit potentiellement livrable.
A la fin de ce chapitre, nous avons réussi à produire un incrément ayant suffisamment de valeur
pour le client et pourra être utilisé dans un environnement de production.
Dans le chapitre qui suit, notre effort sera consacré pour produire un nouveau release
couvrant les fonctionnalités de gestion de magasin et de faire des traitements .

55
Chapitre 4. Release 2 -
Gestion de magasin
&
Faire des traitements
Introduction
Après avoir entamé le premier release de notre système informatique, nous pouvons
maintenant nous lancer dans les travaux nécessaires pour produire le second release. En effet
les méthodologies agiles, et Scrum en particulier, sont caractérisées par un rythme régulier.
Tout au long de chapitre nous aurons deux sprints ayant la même vélocité que les sprints
précédents, et nous allons traiter les histoires utilisateurs de ces derniers pour avoir à la fin de ce
release une partie de logiciel, livrable et fonctionnel.
En partant sur le même principe que les sprints précédents, nous commençons par définir le but
de notre premier sprint pour ce release. Suite à une conversation entre le Product Owner et
l’équipe Scrum, nous avons décidé le but suivant: « terminer la partie qui concerne la gestion de
magasin. Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles
histoires inclure dans ce dernier.
Le Tableau 4.1 résume donc le backlog de notre second sprint:
Tableau 4.1 : Backlog du premier sprint (release 2)
Lister les vendeurs 1
Ajouter un vendeur 2
Modifier un vendeur 3

56
Lister les caisses 2
Ajouter une caisse 2
Modifier une caisse 3
Lister les clients 2
Ajouter un client 3
Modifier un client 2
Dans le Tableau 4.1, nous pouvons constater que les histoires utilisateur «supprimer un
vendeur», «chercher une caisse» et « modifier un client » ne figurent pas dans le backlog de
produit. En effet, notre backlog de produit initial ne couvre pas toutes les fonctionnalités
requises et c’est pour cette raison que nous aurons des nouvelles fonctionnalités au fur et
mesure de notre avancement. En plus, nous pouvons constater que les vélocités de nos histoires
ont changé par rapport à l’estimation initiale tout en gardant la même durée que le sprint
précédent.
I.1.1. Diagramme des cas d’utilisation

57
Figure 4.1 : Diagramme des cas d’utilisation du premier sprint (release 2)
Pour rendre notre diagramme des cas d’utilisation plus lisible et afin de décrire le
comportement de notre système, nous présentons la description textuelle des principaux cas
d’utilisation.
A. Cas d’utilisation : Gestion des vendeurs
 Description textuelle du cas d’utilisation « consulter la liste des vendeurs»
(voir tableau 4.2)

58
Tableau 4.2 : Description textuelle du cas d’utilisation «consulter la liste des vendeurs»
Cas d’utilisation Consulter la liste des vendeurs
Post - condition La liste des vendeurs est affichée sur l’écran
vendeurs
2-le système affiche la liste des vendeurs
B. Cas d’utilisation : Gestion des Caisses
 Description textuelle du cas d’utilisation « supprimer une caisse » (voir
Tableau 4.3)
Tableau 4.3 : Description textuelle du cas d’utilisation «supprimer une caisse»
Cas d’utilisation Supprimer une caisse
La caisse existant
Post - condition La liste des caisse est affichée sur l’écran
Scénario nominal 1-l’administrateur choisi la caisse à supprimer
confirmation
4-le système supprime la caisse

59
C. Cas d’utilisation : Gestion des Clients
 Description textuelle du cas d’utilisation « ajouter un client»(voir Tableau 4.4)
Tableau 4.4 : Description textuelle du cas d’utilisation «ajouter un client»
Cas d’utilisation Ajouter un client
Post-condition La liste des clients est affichée sur l’écran
d’ajout
4-le système enregistre le nouveau client et
manquantes
nominal
4-b- le client existe déjà
nominal

60
I.2. Conception :
Dans cette section nous commençons par le diagramme de séquence système des différents cas
I.2.1. Diagramme de séquence système
constater que certains cas d’utilisations sont similaires à l’instar de la consultation des
vendeurs, la consultation des caisses, etc. c’est pour cette raison que nous avons choisir de
sélectionner quelques exemples.
A. Diagramme de séquence système du cas d’utilisation « supprimer une
caisse»
Le cas d’utilisation supprimer une caisse est similaire au cas d’utilisation supprimer un vendeur.
(Voir Figure 4.2)
Figure 4.2 : Diagramme de séquence «supprimer une caisse»

61
B. Diagramme de séquence système du cas d’utilisation « chercher un client»
Pour chercher un client, l’administrateur doit s’authentifier dans un premier lieu en utilisant son
login et son mot de passe. Par la suite, il choisit les critères de recherche correspondant à ces
besoins (voir figure 4.3).
Figure 4.3 : Diagramme de séquence «chercher un client»
I.2.2. Le diagramme des classes :
Après tous le travail de spécification et de conception, nous pouvons maintenant construire le
associations, attributs, etc.) déduits à partir des activités précédente. (voir Figure 4.4).

62
Figure 4.4 : Diagramme de classe du premier sprint (release 2)
I.3. Codage :
données suivant (voir Tableau 4.5, Tableau 4.6, Tableau 4.7).

63
VND_CODE VARCHAR(20) PRIMARY KEY
VND_NAME VARCHAR(20) ---
VND_QUALITE VARCHAR(20) ---
CODE_CLES VARCHAR(20) FOREIGN KEY
VND_EMAIL VARCHAR(20) UNIQUE
VND_CIN VARCHAR(20) NOT NULL
Tableau 4.5 : Table «Vendeur»
CA_CODE VARCHAR(20) PRIMARY KEY
CA_PRIX NUMBER(10) NOT_NULL
CA_TVA NUMBER(10)
Tableau 4.6 : Table «Caisse»
CLT_CODE VARCHAR(20) PRIMARY KEY
CLT_NAME VARCHAR(20) NOT NULL
CLT_EMAIL VARCHAR(20) UNIQUE
CLT_CIN NOT NULL
Tableau 4.7 : Table «Client»

64
I.4. Test :
En partant toujours du même principe que les sprints précédents, et en appliquant les bonnes
pratiques d’ingénierie logicielle inspirée de la méthodologie extrême programming (XP), nous
commençons par les tests unitaires de l‘histoire utilisateur «modifier une caisse»
I.4.1. Test unitaire
JUnit.
 Test unitaire pour l’histoire «modifier un vendeur»
Pour tester la modification d’une caisse, nous avons choisi de respecter la démarche suivante:
1. Modifier le vendeur
2. Récupérer le vendeur modifié
3. Vérifier que les champs ont bien été changés
La capture d’écran (Figure 4.5) suivante illustre le code source de notre classe de test
Figure 4.5 : Code source de la classe de test pour l’histoire «modifier un vendeur»

65
La capture écran suivante illustre le cas de succès pour la modification d’une caisse. La figure
(4.6) nous montre que notre méthode est bien fonctionnelle.
Figure 4.6 : Cas de succès pour la modification d’un vendeur
II. Le deuxième sprint :
de notre second sprint. Suite à une conversation entre le Product Owner et l’équipe Scrum, nous
avons décidé le but suivant: « terminer la partie qui concerne Faire traitement ». Une fois, nous
avons défini le but de notre sprint, il est temps de décider quelles histoires inclure dans ce
dernier.

66
Tableau 4.8 : Backlog de second sprint (release 2)
d’utilisation.
Lister les services 1
Modifier un service 2
Clôturer un service 2
Chercher un service 2
Lister les ticket 2
Modifier un ticket 3
Chercher un ticket 2
Annuler un ticket 3
Consulter état stock 2

67
A. Cas d’utilisation : Gestion des Tickets
 Description textuelle du cas d’utilisation« Annuler un ticket » (voir Tableau 4.9)
Tableau 4.9 : Description textuelle du cas d’utilisation «Annuler un ticket»
Cas d’utilisation Annuler un ticket
Post-condition La liste des tickets est affichée sur l’écran
Scénario nominal 1-l’administrateur demande d’annuler un ou
plusieurs tickets(s).
2-le système affiche la liste complète de ticket
(par défaut de jour actuelle)
3-l’administrateur sélectionne les tickets et
valider.
4 – Le système annule les tickets et affiche un
message de réussite.
manquantes
nominal

68
B. Cas d’utilisation : Clôturer un service
 Description textuelle du cas d’utilisation« clôturer un service » (voir Tableau 4.10)
Tableau 4.10 : Description textuelle du cas d’utilisation «Clôturer un service»
Cas d’utilisation Clôturer un service
Post-condition La liste des services est affichée sur l’écran
Scénario nominal 1-l’administrateur demande de fermer un ou
plusieurs service(s).
2-le système affiche la liste complète de service
actif.
3-l’administrateur sélectionne les services et
valider.
4 – Le système ferme les services et affiche un
message de réussite.
manquantes
nominal

69
II.2. Conception :
d’utilisation déjà détaillé dans la section précédente.
II.2.1. Diagramme de séquence système :
diagrammes de séquences systèmes adéquats
A. Diagramme de séquence système du cas d’utilisation «Annuler ticket»
Nous illustrons le diagramme de séquence du cas d’utilisation «Annuler ticket» système par la
figure 4.8
Figure 4.8 : Diagramme de séquence système du cas d’utilisation «Annuler ticket»
B. Diagramme de séquence système du cas d’utilisation « Clôturer service» :
La clôture de service est illustrée par la figure 4.9.

70
Figure 4.9 : Diagramme de séquence système du cas d’utilisation «Clôturer service»
II.2.2. Le diagramme des classes :
nouvel incrément (Voir figure 4.10) de notre diagramme des classes en ajoutant les différents
éléments (classes, associations, attributs, etc.) déduits à partir des activités précédente.

71
Figure 4.10 : Diagramme des classes du second sprint (release 2)
II.3. Codage
données qui est présenté par Tableau 4.11, Tableau 4.12 et Tableau 4.13.

72
SRV_CODE VARCHAR(20) PRIMARY KEY
SRV_DATEO TIMESTAMP ---
SRV_DATEF TIMESTAMP ---
CA_CODE VARCHAR(20) FOREIGN KEY
Tableau 4.11 : Table «Service»
NUM_TCK VARCHAR(20) PRIMARY KEY
DATE_TCK TIMESTAMP ---
SRV_NUM VARCHAR(20) FOREIGN KEY
CLT_CODE VARCHAR(20)
TOTAL_TTC NUMBER(10) NOT NULL
Tableau 4.12 : Table «Ticket»
II.4. Test :
commençons par les tests unitaires de l’histoire utilisateur « supprimer un service»
II.4.1. Tests unitaires :
JUnit.
Pour tester la suppression d’un service, nous avons choisi de suivre la démarche suivante :
1. Compter le nombre des services existants et vérifier que c’est égal à 3
2. Supprimer un service
3. Compter de nouveau le nombre de service et vérifier que c’est égal à 2

73
La première capture écran (Figure 4.11) illustre le code de la classe de test.
Figure 4.11 : Code source de la classe de test pour l’histoire «supprimer un service»
Figure 4.12 : Cas de succès pour la suppression d’un service

74
Conclusion :
Le résultat d’un release est un produit livrable au client contrairement au résultat d’un sprint qui
est un produit potentiellement livrable. A la fin de ce chapitre, nous avons réussi à produire un
incrément ayant suffisamment de valeur pour le client et pourra être utilisé dans un
environnement de production. Dans le chapitre qui suit, notre effort sera consacré pour
produire un nouveau release couvrant les fonctionnalités d’administrations

75
Chapitre 5. Release 3 - Administration
Introduction
Après avoir entamé les deux releases de notre système informatique, nous pouvons
maintenant nous lancer dans les travaux nécessaires pour produire le troisième release. En
effet les méthodologies agiles, et Scrum en particulier, sont caractérisées par un rythme
régulier. Tout au long de chapitre nous aurons deux sprints ayant la même vélocité que les
sprints précédents, et nous allons traiter les histoires utilisateurs de ces derniers pour avoir à la
fin de ce release le logiciel complet, livrable et fonctionnel.
de notre premier sprint pour ce release. Suite à une conversation entre le Product Owner et
l’équipe Scrum, nous avons décidé le but suivant: « terminer la partie qui concerne
l’administration coté utilisateur. Une fois, nous avons défini le but de notre sprint, il est temps
de décider quelles histoires inclure dans ce dernier.
Le Tableau 5.1 résume donc le backlog de notre premier sprint :
Tableau 5.1 : Backlog du premier sprint (release3)
Lister les utilisateurs 2
Ajouter un utilisateur 2
Modifier un utilisateur 3
Lister les groupes 1
Ajouter un groupe 2
Modifier un groupe 2
Lister les fonctions 3
Ajouter une fonction 2
Modifier une fonction 3

76
I.1.1. Diagramme des cas d’utilisation
Dans la Figure 5.1 nous illustrons le diagramme des cas d’utilisation global pour ce premier
Figure 5.1 : Diagramme des cas d’utilisation du premier sprint (release 3)

77
A. Cas d’utilisation : Gestion des utilisateurs
 Description textuelle du cas d’utilisation« consulter la liste des utilisateur » (Voir
tableau 5.2)
Tableau 5.2 : Description textuelle du cas d’utilisation «consulter la liste des utilisateurs»
Cas d’utilisation Consulter la liste des utilisateurs
Post - condition La liste des utilisateurs est affichée sur l’écran
utilisateurs
2-le système affiche la liste des utilisateurs
 Description textuelle du cas d’utilisation« ajouter un utilisateur » (Voir tableau 5.3)
Tableau 5.3 : Description textuelle du cas d’utilisation «ajouter un utilisateur»
Cas d’utilisation Ajouter un utilisateur
Post-condition La liste des utilisateur est affichée sur l’écran
d’ajout

78
4-le système enregistre le nouveau utilisateur
et affiche un message de succès
manquantes
nominal
4-b-l’utilisateur existe déjà
nominal
I.2. Conception :
d’utilisation déjà détaillé dans la section précédente.
I.2.1. Diagramme de séquence système :
constater que certains cas d’utilisations sont similaires à l’instar de la consultation des tickets et
la consultation des services.
A .Diagramme de séquence système du cas d’utilisation « modifier un
utilisateur»
Le cas d’utilisation modifier un utilisateur est similaire au cas d’utilisation suivant : modifier une
fonction, modifier un groupe.
La figure 5.2 illustre le diagramme de séquence «modifier un utilisateur»

79
Figure 5.2 : Diagramme de séquence «modifier un utilisateur»
B. Diagramme de séquence système du cas d’utilisation « supprimer une
fonction»
Pour supprimer une fonction, l’administrateur doit s’authentifier dans un premier lieu en
utilisant son login et son mot de passe. Par la suite, il sélectionne la fonction à supprimer (voir
figure 5.3).

80
Figure 5.3 : Diagramme de séquence «supprimer une fonction»
I.2.2. Le diagramme des classes
associations, attributs, etc.) déduits à partir des activités précédente. (Voir figure 5.4)

81
Figure 5.4 : Diagramme de classe du premier sprint (release3)
I.3. Codage
données qui est présenté par Tableau 5.4, Tableau 5.5, Tableau 5.6 et Tableau 5.7.

82
USER_CODE VARCHAR(20) PRIMARY KEY
USER_NAME VARCHAR(20) NOT NULL
GRP_CODE VARCHAR(20) FOREIGN KEY
ADDRESSE VARCHAR(20) NOT NULL
EMAIL VARCHAR(20) UNIQUE
DATE_LAST_LOGIN TIMESTAMP ---
Tableau 5.4 : Table «Utilisateur»
GRP_CODE VARCHAR(20) PRIMARY KEY
CAT_LIBELLE VARCHAR(20) ---
Tableau 5.5 : Table «Groupe»
FNX_CODE VARCHAR(20) PRIMARY KEY
FNX_LIBELLE VARCHAR(20) NOT NULL
Tableau 5.6 : Table «Fonction»
FNX_CODE VARCHAR(20) PRIMARY KEY
GRP_CODE VARCHAR(20) PRIMARY KEY
Tableau 5.7 : Table «Privilège»

83
I.4. Test :
commençons par les tests unitaires de l’histoire utilisateur « ajouter un utilisateur»
I.4.1. Tests unitaires :
JUnit.
 Test unitaire pur l’histoire « ajouter un utilisateur»
Pour tester l’ajout d’un niveau, nous avons choisi de respecter la démarche suivante :
1. Ajouter un niveau utilisateur
2. Récupérer le dernier niveau utilisateur ajouté
3. Comparer les attributs du niveau utilisateur ajouté et celles d’utilisateur
récupéré.
La Figure 5.5 illustre le code source de la classe de test.
Figure 5.5 : Code source de la classe de test pour l’histoire «ajouter un utilisateur»

84
Figure 5.6 : Cas de succès pour l’ajout d’un utilisateur
II. Le deuxième sprint :
de notre second sprint. Suite à une conversation entre le Product Owner et l’équipe Scrum, nous
avons décidé le but suivant: « terminer la partie qui concerne l’administration coté statistique et
états ».
Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires
inclure dans ce dernier.

85
Tableau 5.8 : Backlog de second sprint (release3)
d’utilisation.
sprint
Authentification 3
Consulter le journal des tickets annulés 4
Consulter cumule de vente par article 4
Consulter recap de vente 4
Consulter tableau de bord 7

86
A. Cas d’utilisation : Authentification
 Description textuelle du cas d’utilisation «Authentification» (voir Tableau 5.9)
Tableau 5.9 : Description textuelle du cas d’utilisation «Authentification»
Cas d’utilisation Authentification
Acteurs Administrateur, Agent comptable , vendeur
Pré-condition Néant
Post-condition L’acteur accède à son espace privé
Scénario nominal 1- l’administrateur introduit son login et son
mot de passe
2-le système vérifier les données saisies
3-le système redirige l’administrateur vers son
espace privé
manquantes
2-a-1 le système affiche un message
d’erreur
2-a-2 reprises de l’étape 1 du scénario
nominal
2-b- les données saisies sont invalides
2-b-1- le système affiche un message d’erreur
de type «les données saisies sont invalides»
2-b-2- reprise de l’étape 1 du scénario
nominal

87
II.2. Conception
A ce niveau, nous commençons par le diagramme de séquence système des différents cas
II.2.1. Diagramme de séquence système
diagrammes de séquences systèmes adéquats.
A. Diagramme de séquence système du cas d’utilisation «Consulter tableau
de bord»
Ce diagramme est illustré par la figure 5.8.
Figure 5.8 : Diagramme de séquence système du cas d’utilisation «consulter tableau de bord»

88
B. Diagramme de séquence système du cas d’utilisation « Authentification» :
Ce diagramme est illustré par la figure 5.9.
Figure 5.9 : Diagramme de séquence système du cas d’utilisation «Authentification»
II.2.2. Le diagramme des classes
associations, attributs, etc.) déduits à partir des activités précédente. (Voir figure 5.10)

89
Figure 5.10 : Diagramme de classe du premier sprint (release3)
Conclusion :
A ce stade, nous avons réussir donc à développer le dernier release de notre application pour
arriver à un produit complet et fonctionnel. Il nous reste seulement une dernière étape et qui
consiste à implémenter l’application auprès du client final.

90
Chapitre 6. La phase closure
Introduction
La phase closure ou de fermeture est la dernière phase dans le cycle de développement d’un
logiciel avec Scrum. Cette phase est souvent appelé sprint de stabilisation [6]. Les tâches
effectuées pendant cette phase ne sont pas claires, et ils dépendent fortement du type de
déploiement du logiciel (mise en production à chaud, packaging du produit, mise à disposition
par téléchargement en ligne ...).
Pour notre projet, ce chapitre sera consacré pour la présentation des langages et outils de
programmation utilisés pour la réalisation de notre application, le déploiement de notre
application. Nous finissons pour quelques interfaces graphiques du logiciel fourni.
I. Environnement de développement :
L’environnement de développement est un terme qui désigne l’ensemble d’outils et de langage
utilisé pour l’implémentation d’une solution informatique.
Nous commençons par L’environnement matériel.
I.1. Environnement matériel :
Pour le développement de notre application, nous avons passé par trois environnements
différents
I.1.1. Environnement de développement :
 Ordinateur: HP Pavillon
 Processeur: Intel 15
 Mémoire vive: 4GO
 Disque dur : 500GO

91
 Version apache Tomcat : 7.0
 Système d’exploitation: Windows 7
Remarque :
Pour exécuter notre application, ne besoin pas de ces performances citée au-dessus, Just
nécessite un ordinateur connecter aux réseaux internet ou intranet et peut accéder au serveur
sur laquelle placée notre application.
I.1.2. Environnement de test :
 Serveur: serveur mutualisé cPanel
 Espace de stockage FTP : 1 GO
 Espace de stockage MySQL : 5MO
 Version apache Tomcat: 7.0
 Système d'exploitation: linux
I.1.3. Environnement de production :
 Serveur: serveur mutualisé OVH
 Espace de stockage FTP : 100GO
 Espace de stockage MySQL : 400MO
 Version Apache Tomcat: 7.0
I.2. Environnement logiciel :
Les logiciels utilisés pour l’implémentation de notre solution sont les suivants :
I.2.1. Eclipse :
Figure 6.1 : Eclipse

92
Eclipse est un projet open source à l'origine développé par IBM pour ces futurs outils de
développement. Le but est de fournir un outil modulaire capable non seulement de faire du
développement en java mais aussi dans d'autres langages et d'autres activités. Cette
polyvalence est liée au développement de modules réalisés par la communauté ou des entités
commerciales.
Dans un esprit de défi, et vouloir mettre en œuvre les connaissances qu'on a acquis durant
notre formation, on a opté Eclipse Kepler pour le développement de notre application. Ce
logiciel ne cesse pas à prouver sa fiabilité et sa robustesse ce qui le rend au top de classement
des EDIs les plus utilisés. De plus Eclipse offre un nombre très importants des plugins et des
librairies disponible sur le net qui sont des modules complémentaires et efficaces (exemple
la librairie Jdom, Jdbc Oracle, Javax faces, Jasper, primefaces…).
I.2.2. Sybase POWER AMC :
Figure 6.2 : Power AMC
Power AMC est une solution de modélisation et de gestion de métadonnées à la pointe
de l’innovation, destinée aux architectures de données, aux architectures d’informations
et aux architectures d’entreprise. PowerAMC est l’édition française de PowerDesigner.
I.2.3. Oracle Database 10g :
Figure 6.3 : Oracle Data Base

93
Oracle est un système de gestion de base de données relationnel (SGBDR) qui depuis
l'introduction du support du modèle objet dans sa version 8 peut être aussi qualifiée
de système de gestion de base de données relationnel-objet (SGBDRO). Fourni par Oracle
Corporation, il a été développé par Larry Ellison, accompagné d'autres personnes telles
que Bob Miner et Ed Oates.
Avantage :
 Gestion centralisée de plusieurs instances
 Concept unique de retour arrière (Flashback)
 Réglages fins : dans la mesure où l'on connait suffisamment le moteur,
presque TOUT est paramétrable.
 Accès aux données système via des vues, bien plus aisément manipulable
que des procédures stockées.
 Services Web
 Support XML
 Ordonnanceur intégré
Inconvénients
 Prix exorbitant, tant au point de vue des licences que des composants
matériels (RAM, CPU) à fournir pour de bonnes performances.
 Porosité entre les schémas = difficile de faire cohabiter de nombreuses
applications sans devoir créer plusieurs.
I.3. Langage de programmation :
I.3.1. JAVA EE :
Figure 6.4 : java EE

94
Java EE : Java Enterprise Edition, ou Java EE (anciennement J2EE), est
une spécification pour la technique Java de Oracle plus particulièrement destinée aux
applications d’entreprise. Ces applications sont considérées dans une
approche multi-niveaux. Dans ce but, toute implémentation de cette spécification contient
un ensemble d’extensions au framework Java standard (JSE, Java Standard Edition) afin de
faciliter notamment la création d’applications réparties.
I.3.2. UML :
Figure 6.5 : UML
Le but d’UML est de réduire la complexité du développement et d’avoir une vision de
différents angles des vues du system d’information. Pour ce projet, on opte pour la notation
UML2 (Unified Modeling Language : langage graphique de modélisation des données et
des traitements). Ce dernier propose un langage et une notation graphique standard pour la
création des diagrammes UML permettent de représenter un système selon différentes vues
complémentaires.
I.3.3. Le langage SQL :
Figure 6.6 : Langage SQL
Le langage sql est un langage informatique normalisé qui sert à effectuer des opérations sur
des bases de données. La partie langage de manipulation de données de SQL permet de
rechercher, d'ajouter, de modifier ou de supprimer des données dans les bases de
données.

95
I.4. Les Framework :
I.4.1. JSF2.0 :
Figure 6.7 : JSF
Java Server Faces est un Framework Java, pour le développement d'applications Web. À
l'inverse des autres Framework MVC traditionnels à base d'actions, JSF est basé sur la
notion de composants, comparable à celle de Swing ou SWT, où l'état d'un composant est
enregistré lors du rendu de la page, pour être ensuite restauré au retour de la requête. JSF est
agnostique à la technologie de présentation. Il utilise Facelets par défaut depuis la version
2.0, mais peut être utilisé avec d'autres technologies, comme JSP (qui était utilisé jusqu'à la
version 1.2) ou XUL.
I.4.2. Spring :
Figure 6.8 : Spring
SPRING est un conteneur dit « léger », c'est-à-dire une infrastructure similaire à un serveur
d'application J2EE. Il prend donc en charge la création d'objets et la mise en relation d'objets
par l'intermédiaire d'un fichier de configuration qui décrit les objets à fabriquer et les
relations de dépendances entre ces objets.

96
I.4.3. Hibernate :
Figure 6.9 : Hibernate
Hibernate est une solution open source de type ORM (Object Relational Mapping) qui
permet de faciliter le développement de la couche persistance d'une application. Hibernate
permet donc de représenter une base de données en objets Java et vice versa.
II. Déploiement :
A ce niveau, notre application est finie, il est temps de réfléchir à la déployer. Nous
commençons par le diagramme de déploiement de notre application
II.1. Diagramme de déploiement
Le diagramme de déploiement permet de représenter la répartition géographique des composants
matériels de notre système sous forme de nœuds. (Voir Figure 6.10, Figure 6.11)

97
Figure 6.10 : Diagramme de déploiement de FrontOffice
Figure 6.11 : Diagramme de déploiement BackOffice

98
II.2. Les interfaces de l’application
Dans ce paragraphe, nous présentons quelques interfaces de l’application réalisée.
Figure 6.12 : Page d’authentification (BackOffice)
Figure 6.13 : Tableau de Bord (BackOffice)

99
Figure 6.14 : Gestion Des Vendeurs (BackOffice)
Figure 6.15 : Fenêtre d’accueil (FrontOffice)

100
Figure 6.16 : Fenêtre Principale (FrontOffice)
Figure 6.17 : Fenêtre d’ajout d’article (FrontOffice)

101
Conclusion :
Tout au long de ce chapitre nous avons essayé de présenter les différents travaux qui se déroulent à
la fin du cycle de développement Scrum. Nous avons présenté les interfaces de notre application
ainsi l’environnement matérielle et logiciel de développement.

102
Conclusion et perspectives
Dans le cadre de notre projet de fin d’étude, nous avons conçu et développé une application de
gestion des points de la vente pour la société Horizon Informatique.
Le présent manuscrit détaille toutes les étapes par lesquelles nous sommes passées pour arriver
au résultat attendu. Nous avons essayé tout au long de notre travail de construire notre
application incrément par incrément en utilisant la méthodologie Scrum.
Nous avons commencé dans un premier lieu par comprendre le contexte général de notre
application et identifier les différentes exigences de notre futur système. Nous avons préparé
par la suite notre planning de travail en respectant les priorités de nos besoins suite à une
discussion entre l’équipe du développement et le directeur du produit.
Tout au long de notre cycle de développement nous avons couplé la méthodologie Scrum par
une autre méthodologie agile; l’extrême programming (XP) afin de profiter des bonnes
pratiques d’ingénierie logicielle proposées par cette dernière.
Malgré toutes les difficultés rencontrées au niveau du processus métier de magasin et les
contraintes de temps, nous avons réussi à réaliser la totalité de notre application tout en
respectant l’aspect sécuritaire et en préparant la documentation nécessaire.
Ce travail était très intéressant puisqu’il nous a permis de découvrir un nouveau domaine de
travail et de s’éloigner des projets traditionnels de type site web E - commerce. Il nous a permis
d’approfondir nos connaissances dans les bonnes pratiques de programmation notamment la
sécurisation des données et la documentation des codes sources, etc.
Finalement, notre travail ne s’arrête pas à ce niveau, en effet plusieurs fonctionnalités peuvent
être ajoutées à notre application notamment un système pour la gestion des commandes et qui se
base principalement sur la gestion des articles et des clients qui sont déjà déployés dans notre
application.

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

104
Figure A.2 : Règle 2 du passage du modèle conceptuel vers le modèle logique
II.2. Les associations plusieurs à plusieurs :
L’association (ou la classe classe-association) devient une relation dont la clé primaire est
composée par la concaténation des identifiants des classes connectés à l’association. Chaque
attribut devient clé étrangère si classe connectée dont il provient devient une relation en vertu
de la règle RI.
Les attributs de l’association (ou la classe-association) doivent être ajoutés à la nouvelle relation.
Ces attributs ne sont ni clé primaire, ni clé étrangère.
Figure A.3 : Règle 3 du passage du modèle conceptuel vers le modèle logique (premier cas)

105
II.3. Association un à un :
Il faut ajouter un attribut clé étrangère dans la relation dérivée de la classe ayant la multiplicité
minimale égale à un. L’attribut porte le nom de la clé primaire de la relation dérivée de l’entité
(classe) connectée à l’association.
Si les deux cardinalités (multiplicités) minimales sont à zéro, le choix est donné entre les deux
relations dérivées de la règle RI. Si les deux cardinalités minimales sont à un, il est sans doute
préférable de fusionner les deux entités (classes) en une seule.
Figure A.4 : Règle 3 du passage du modèle conceptuel vers le modèle logique (deuxième cas)
II.4. Transformation de l’héritage:
S’il existe une contrainte de totalité ou de partition sur l’association, il est possible de ne pas
traduire la relation issue de la surclasse. Il faut alors faire migrer tous ses attributs dans la(les)
relation(s) issue(s) de la (des) sous-classe(s).
Dans le cas contraire, il faut faire migrer tous ses attributs dans la ou les relation(s) issue(s) de la
(des) sous classe(s) dans la (les) relation(s) issue(s) de la (des) sous-classe(s).

106
Figure A.5: Règle 3 du passage du modèle conceptuel vers le modèle logique (troisième cas)
II.5. Transformation de la composition :
La clé primaire des relations déduites des classes composantes doit contenir l’identifiant de la
classe composite (quelles que soient les multiplicités).
Figure A.6: Règle 3 du passage du modèle conceptuel vers le modèle logique (quatrième cas)

107
Bibliographie
[1] F.V.Pascal Roques, UML2 en action de l’analye des besoins à la conception , edition
Eyrolles , 2007
[2] C.Aubry, SCRUM le guide pratique de la méthode agile la plus populaire , Dunod , 2010
[3] C.Soutou, UML2 pour les bases de données, edition Eyrolles

Front office back office caisse

Contenu connexe

Tendances (20)

En vedette (6)

Similaire à Front office back office caisse (20)

Dernier (7)

Front office back office caisse