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

3-l’administrateur valide son choix

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

3-l’administrateur valide son choix 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

Technology

Transcript of Front office back office caisse