CINEMATIQUE DE FICHIERS

Transcription

1 ANDRE ANTHONY BRUNEAU Vincent JOUANNIN ROMAIN MAZEAUD MARINE RIOCHET Tony Groupe 609 CINEMATIQUE DE FICHIERS Mini-projet: Gestion de Ventes d'articles Enseignant: MONCEAUX Laura Année 2011 / 2012

2 TABLE DES MATIÈRES 1. SUJET ORGANISATION DU PROJET Équipe Site de travail collaboratif Planning Outils de réalisation MÉTHODE DE CONCEPTION Cycle de développement Principes véhiculés Quelques pratiques Rôle de chaque membre de l'équipe FONCTIONNALITÉS PROPOSÉES ET RÉPARTITION DU TRAVAIL Anthony ANDRE chargé de la fonction «Gestion des Articles à vendre» : Marine MAZEAUD chargée de la fonction «Gestion des Clients» : Vincent BRUNEAU chargé de la fonction «Gestion des Ventes» : Romain JOUANNIN chargé de la fonction «Statistiques» : STRUCTURE ET DONNÉES SAUVEGARDÉES Fichier des Articles Fichier des Clients Fichier des Ventes TESTS Diagramme de séquence du cas d'utilisation «Gestion des Articles à vendre» Diagramme de séquence du cas d'utilisation «Gestion des Clients» Diagramme de séquence du cas d'utilisation «Gestion des Ventes» Diagramme de séquence du cas d'utilisation «Statistiques» INTERFACE POINT À MI-PARCOURS / 19

3 1. SUJET Le but de ce projet est de réaliser un mini-logiciel de gestion de vente d'articles en COBOL. Pour cela, un groupe de travail a été formé composé de cinq personnes dont quatre analystes développeurs et un chef de projet. Nous avons décidé de proposer un logiciel générique c'est à dire pouvant s'adapter à plusieurs corps de métier sans modifications du code. Néanmoins, pour les besoins de la future soutenance ainsi que pour certaines explication, un magasin semblable à la FNAC a été choisi comme environnement. Ce rapport à mi-parcours traite de toute la phase d'analyse et de pré-conception en détaillant les diverses fonctionnalités, structures et données. Dans un premier temps, nous allons nous intéresser à l'organisation du projet en présentant l'équipe et le Support de développement puis en détaillant le planning à respecter ainsi que les divers outils qui nous ont été nécessaires. 2. ORGANISATION DU PROJET 2.1 Équipe Comme expliqué précédemment, notre groupe de travail est donc composé de cinq personnes établi selon l'ordre suivant: Tony RIOCHET [Chef de Projet] - tony.riochet@gmail.com Anthony ANDRE [Analyste/Développeur/Testeur] - anthony.andre.44@gmail.com Vincent BRUNEAU [Analyste/Développeur/Testeur] vinbruneau@gmail.com Romaine JOUANNIN [Analyste/Développeur/Testeur] jouannin.romain@gmail.com Marine MAZEAUD [Analyste/Développeuse/Testeuse] marine.mazeaud@gmail.com 2.2 Site de travail collaboratif Dans un soucis de simplicité à communiquer, échanger des informations et données ainsi que centraliser notre travail, nous avons pensé à créer un site internet. Notre choix s'est donc orienté vers «Google Sites» proposant un service gratuit et très facile à mettre à place et à administrer dont voici l'adresse: Planning Le diagramme de Gantt suivant (cf Figure 1) définit le planning à respecter avec les dates limites à chaque partie, l'avancement des tâches, l'ensemble montrant ainsi la progression de l'équipe dans le projet: 3 / 19

4 Figure 1 - Diagramme de Gantt du projet 4 / 19

5 2.4 Outils de réalisation Durant cette phase d'analyse, nous avons utilisé plusieurs logiciels qui sont vite apparus comme nécessaires pour notre projet: ArgouUML : Outil de modélisation UML (cas d'utilisation, scénario, diagramme de classe...) réalisé en Java TortoiseSVN : Outil de développement collaboratif (centralisation, échange et révisions de fichiers) GanttProject : Outil de réalisation de Diagramme de Gantt (Planning) pour la gestion de projet Maintenant que toute la partie concernant l'organisation a été traitée, nous allons nous intéresser à la méthode de conception adoptée pour ce projet en présentant le principe général, la répartition prévue ainsi que les raisons qui nous on poussé à faire ce choix. 3. MÉTHODE DE CONCEPTION Pour ce projet, nous avons donc décidé d'adopter la méthode agile du «Extreme Programming» (XP), adaptée aux équipes réduites avec des besoins changeants. Celle-ci consiste à prendre les pratiques les plus simples et les pousser à l'extrême. 3.1 Cycle de développement Figure 2 schéma du cycle de développement du «Extreme Programming» Comme vous pouvez le voir sur la figure précédente (cf Figure 2), le XP repose sur des cycles rapides de développement avec des itérations de seulement quelques semaines: Une phase d'exploration (détermination de scénarios clients qui permettent d'obtenir une vision globale sur les différentes fonctions à implémenter et qui serviront de base de tests). Transformation des scénarios précédents en diverses tâches à réaliser ainsi qu'en tests fonctionnels. Répartition et attribution des dîtes tâches à chaque développeur qui les réalisera avec un binôme(principe du couple «Driver/Partner»). Livraison du produit lorsque tous les tests fonctionnels établis dans la seconde phase passent et valident ainsi la production. Ce cycle de développement rapide et simple à la fois est donc un avantage non négligeable au point de vue de notre projet. Au delà de cet atout, ce sont surtout les principes véhiculés par le «Extreme Programming» qui nous ont séduits. 5 / 19

6 3.2 Principes véhiculés Voici une liste non exhaustive des principes du «Extreme Programming» qui font la force de cette méthode: Puisque la revue de code est une bonne pratique, elle sera faite en permanence par le binôme «Driver/Partner» tournant afin que chaque personne du groupe puisse apporter son avis et ses idées. Puisque les tests sont utiles, ils seront faits systématiquement avant chaque implantation permettant une validation de la production au fur et à mesure. Puisque la conception est importante, elle sera faite tout au long du projet. En effet, on n'hésitera pas à user du refactoring («réusinage») pour optimiser sans cesse le code produit. Puisque la simplicité permet d'avancer plus vite, nous choisirons toujours dans un premier temps la solution la plus simple. Ce principe évite également de bloquer les autres développements dans le cas où la fonction est utilisée dans d'autres cas. Puisque la compréhension est importante, nous définirons et ferons évoluer l'ensemble des métaphores ainsi que les règles définies. On note également que commenter la production est très importante pour la revue et l'optimisation. Puisque l'intégration des modifications est cruciale, nous l'effectuerons plusieurs fois par jour via des révisions soigneusement décrites et commentées. Ces principes entraînent donc le développement de pratiques nécessaires pour un respect des «règles» définies précédemment. 3.3 Quelques pratiques Parmi toutes les pratiques du «Extreme Programming» nous en avons retenu quatre qui nous ont apparu comme les plus fondamentales et démonstratrices de cette méthode qui se développe de plus en plus en France: Le jeu du planning: Cette pratique consiste à créer avant toute chose des scénarios pour les fonctionnalités souhaitées. L'équipe évalue le temps nécessaire pour les implémenter et sélectionne ensuite les scénarios en fonction des priorités et du temps disponible. Les tests unitaires: Avant l'implémentation d'une fonctionnalité, on écrit un test, basé sur les scénarios précédemment réalisés, qui vérifiera que le programme se comporte comme prévu. Ce test sera conservé jusqu'à la fin du projet, tant que la fonctionnalité est requise. À chaque modification du code, on lance tous les tests écrits par tous les développeurs, et on sait immédiatement si quelque chose ne fonctionne plus. La convention de nommage: Ici, on cherche à établir certaines normes (nom des variables, structure du squelette...) de façon à ce que la production soit homogène ainsi que pour éviter des problèmes lors de l'intégration au sein du programme principal. L'utilisation de métaphores: On utilisera des métaphores et des analogies afin de décrire le système et son fonctionnement. Cette pratique nous est utile pour un passage simple du fonctionnel au technique. 6 / 19

7 3.4 Rôle de chaque membre de l'équipe Afin que chaque membre de l'équipe soit à l'aise avec l'ensemble du développement réalisé (qui nous a semblé utile mais surtout nécessaire vu notre environnement d'apprentissage), nous avons décidé d'effectuer un roulement suivant 3 postes : un «Driver», un «Partner» et un «Tester». Le «Driver» tient le clavier et écrit la portion de code alors que son «Partner» l'aide à résoudre les problèmes et lui suggère de nouvelles possibilités. Le «Tester» quand à lui reprend les scénarios réalisés au début de l'analyse et teste véritablement le programme. Le chef de projet quand à lui se charge du bon avancement des travaux, de respect des règles et codes mis en place ainsi que de la bonne communication au sein du groupe. Il aura également la tâche de regrouper au fur et à mesure la production de chacun et de l'intégrer au sein du programme principal. Dans un premier temps, on effectue un changement tous les deux à trois jours environ. La première répartition s'est effectuée ainsi (cf Figure 3) : Driver Partner Tester Anthony Vincent Romain Vincent Romain Marine Romain Marine Anthony Un changement tous les 2/3j environ Marine Anthony Vincent Figure 3 schéma représentant le roulement de l'équipe La colonne «Partner» et «Tester» sont mobiles, ce sont elles qui varient (glissement vers le haut). Ainsi, au bout d'une dizaine de jours tous les binômes auront tournés et chaque personne aura ainsi pu se confronter à l'intégralité de la production et pas seulement à sa partie attribuée. Maintenant que la méthode de conception a été définie, le cycle de développement débute. 4. FONCTIONNALITÉS PROPOSÉES ET RÉPARTITION DU TRAVAIL Comme expliqué dans la partie précédente, nous avons tout d'abord commencé par établir des scénarios clients afin de définir au mieux notre périmètre d'actions. Ceux-ci constituent nos points de références et de tests auxquels toute implémentation devra vérifier lors de la production. Grâce à cela nous avons donc pu dégager les fonctions principales de notre logiciel, dénommé CATALOGICIEL. Dans cette partie, nous allons donc traiter des différentes fonctionnalités qui nous sont apparu comme essentielles (fonctions principales) et que nous souhaitons incorporer en priorité dans notre mini-logiciel de gestion. Au vu donc de l'analyse du sujet et de nos scénarios réalisés, quatre fonctionnalités importantes sont ressorties : gestion des articles, gestion des clients, gestion des ventes et statistiques. Comme expliqué pendant la présentation du sujet, nous avons délibérément choisi de rester dans un contexte générique. Pour cela, nous avons mis en place une organisation et un système que nous pensons être général et correspondant au mieux à la plupart des magasins de ventes d'articles. 7 / 19

8 Étant donné notre nombre, chaque membre de l'équipe a reçu la responsabilité d'une fonction. Le chef de projet, quand à lui, a en charge la supervision globale du programme et donc l'intégration de ces fonctions. Afin de simplifier la compréhension, nous avons mis à contribution nos connaissance en UML et retranscrit tout cela sous forme de cas d'utilisation. Un cartouche a également ajouté dans la partie «statistiques» pour détailler au mieux cette fonctionnalité. 4.1 Anthony ANDRE chargé de la fonction «Gestion des Articles à vendre» : La gestion des articles constitue le premier point essentiel à notre logiciel. En effet, le catalogue des articles nous est nécessaire pour pouvoir établir une vente. Dans cette partie, un vendeur peut effectuer diverses opérations (cf Figure), la principale étant l'ajout d'articles au panel déjà existant. Il peut également supprimer un article s'il décide que celui-ci n'est plus à vendre, l'attribut booléen «envente» passe alors à la valeur fausse. L'article n'apparait plus comme disponible et ne fait plus partie du catalogue utilisé pour les ventes. Un article possède également un seuil d'alerte sur sa quantité disponible. Celui-ci est fixé objectivement à 5 mais sa valeur est modifiable par l'utilisateur afin de s'adapter à sa situation. Le vendeur peut passer une commande pour obtenir une livraison de cet article (symbolise donc la mise à jour du stock). Enfin, s'il le désire, le vendeur peut également modifier les informations d'un article renseignées lors de l'ajout telles que son prix ou sa description mais pas sa référence (attribut numéro de l'article). Figure 4 Cas d'utilisation «Gestion des Articles» 8 / 19

9 4.2 Marine MAZEAUD chargée de la fonction «Gestion des Clients» : La gestion des clients constitue la deuxième partie majeure de notre programme. Comme on peut le voir ci-dessous (cf Figure 5), deux actions majeures se dégagent: l'ajout de clients au fichier et la modification des informations d'un client. Un vendeur peut également supprimer un client, toutes les ventes associées à celui-ci sont alors transférées sur un compte client portant le numéro zéro. Ce compte est dit «global» et est utilisé pour des ventes dont les clients ne souhaitent pas s'enregistrer. Au final, il s'agit là d'une vente classique, dans le sens où un client ne laisse aucune information personnelle, réalisée dans la plupart des magasins. Enfin, il peut consulter toutes les informations disponibles sur le client pour par exemple des raisons administratives ou encore obtenir le détail de ses ventes. Figure 5 Cas d'utilisation «Gestion des Clients» 4.3 Vincent BRUNEAU chargé de la fonction «Gestion des Ventes» : La gestion des ventes est la fonction principale de notre logiciel, il s'agit en effet d'utiliser les données acquises sur les clients et les articles de façon à les faire interagir entre elles et créer un lien: la vente. Lorsqu un vendeur tente d enregistrer une vente, le système doit vérifier que l article concerné se trouve bien en stock et consulte alors le fichier des articles. Dans le cas ou celui-ci existe, il consulte le fichier client pour vérifier l existence du client concerné, sinon il enregistre un nouveau client. Dans le cas ou l article n est pas en stock le vendeur peut effectuer une réservation sinon il enregistre une vente. 9 / 19

10 Figure 6 Cas d'utilisation «Gestion des Ventes» 4.4 Romain JOUANNIN chargé de la fonction «Statistiques» : Lorsqu'un utilisateur demande d'établir une statistique au programme (cf Figure 7), celui va lui demander quel type de statistique l'utilisateur souhaite établir comme par exemple le chiffre d'affaires du jour ou le meilleur client sur une certaine durée. Cette fonction va donc utiliser tous les fichiers afin de trouver les informations nécessaires au calcul de la statistique. Le type de statistique à établir pourra concerner le total des soldes disponible des clients, ou bien déterminer le pourcentage du solde qu'un client possède dans le solde total disponible par exemple. La figure suivante (cf Figure 8) décrit concrètement quels sont les acteurs impliqués ainsi que les conditions postérieures à son utilisation. Figure 7 Cas d'utilisation «Statistiques» Figure 8 Cartouche du cas d'utilisation «Statistiques» 10 / 19

11 5. STRUCTURE ET DONNÉES SAUVEGARDÉES Au final, après avoir effectué une analyse détaillée sur ce que nous souhaitions implémenter, nous nous retrouvons avec trois grandes classe : la classe «Client», «Article» et «Vente». En voici la modélisation sous forme de diagrammes de classe qui permet de bien voir les données gérées ainsi que les relations entre les trois classes : Figure 9 Diagramme de classe du mini-logiciel de gestion L'énumération «EnumEtat» nous sert à dissocier s'il s'agit d'une vente ou d'une réservation (quantité demandée insuffisante). Dans notre situation, une réservation est donc considérée comme une vente spéciale puisque mis à part la modification de cet état tous les autres attributs sont identiques. Dans notre modèle, un «client» est une personne possédant un compte dans le magasin et il est nécessaire d'en disposer, par exemple, pour la réservation d'articles ou encore le paiement différé. Concernant les diverses opérations et méthodes, il ne s'agit là que d'une simple ébauche pour montrer quelques exemples. Nous allons maintenant passé à la structure concrète des fichiers qui nous serviront à stocker les articles, les clients et les ventes. On considère que pour une vente dont le client ne possède pas de compte et n'en désire pas, le numéro de client associée est alors le N 000. Il s'agit donc d'un compte commun pour tous les non-enregistrés. Ce modèle est amené à être modifié au fur et à mesure de l'avancement et de la précision du projet. Globalement, à chaque classe du diagramme présenté ci dessus (cf Figure 9) est associée un fichier organisé de façon séquentielle indexé et dont le mode d'accès est dynamique (fichier clientèle, fichier journal des ventes et fichier catalogue). Afin de faciliter nos futures fonctions (notamment la recherche par critère), nous avons opté pour que chaque attribut représenté ci-dessus constitue une clé du fichier, la clé primaire étant respectivement le numéro pour un client, une vente et un article. Les autres représentent donc les clés secondaires. 11 / 19

12 5.1 Fichier des Articles Le fichier des articles nommé «Fich_Articles.dat», qui nous servira donc de catalogue (tous les articles sont stockés ici), contient pour le moment 7 attributs: le numéro, le nom,le prix, la description, la quantité restante en stock, la catégorie et un booléen déterminant si l'article est toujours disponible à la vente ou non. Ici la clé primaire est le numéro de l'article. Comme expliqué précédemment le reste est défini en tant que clés secondaires avec possibilités de doublons pour faciliter les autres fonctions du programme. Figure 10 Structure du fichier des Articles 5.2 Fichier des Clients Dans ce second fichier intitulé «Fich_Clients.dat», nous nous retrouvons donc avec le même schéma de structure. Ce fichier gérant les Clients comporte 8 attributs: le nom, le prénom, l'adresse (décomposé en numéro/rue/ville/code postal), l'adresse mail, le numéro de téléphone, le montant de ses avoirs s'il en a ainsi que le montant de son solde s'il lui reste des choses à régler. Figure 11 Structure du fichier des Clients 12 / 19

13 5.3 Fichier des Ventes Enfin, le dernier fichier, «Fich_Ventes.dat», est celui gérant les différentes ventes. Là aussi, la structure est identique aux autres. Les attributs sont ici au nombre de 6: le numéro de la vente, le numéro du client (pour rappel N 000 si pas de compte), le numéro des articles, l'état de la vente (vente ou réservation) ainsi que le montant de la vente. Figure 12 Structure du fichier des Ventes 6. TESTS Suivant la méthode de conception adoptée, nous avons établi les tests unitaires et fonctionnels sous forme de scénarios et diagrammes de séquence. Ainsi à chaque implémentation, nous nous baserons sur ces scénarios pour tester la validité du programme. Nous nous baserons sur des scénarios simples où tout se passe bien et aucune anomalie venant entraver le bon fonctionnement du logiciel n'intervient. 6.1 Diagramme de séquence du cas d'utilisation «Gestion des Articles à vendre» Lorsqu'un Vendeur effectue une opération, il spécifie quel article est vendu et en quelle quantité, s'il y en a assez dans le stock, il est immédiatement vendu, sinon un affichage spécifiant que le seuil d'alerte du stock d'articles a lieu et le vendeur devra passer une commande auprès des fournisseurs. 13 / 19

14 Figure 13 Diagramme de séquence «Gestion des Articles» 14 / 19

15 6.2 Diagramme de séquence du cas d'utilisation «Gestion des Clients» Ici ce scénario (cf Figure 14) modélise la situation «ajouter un client au logiciel» et où tout se déroule bien (cf Figure). Lors de l'ajout d'un nouveau client, le vendeur commence par effectuer une recherche afin de déterminer si le client n'a pas déjà une existence dans le fichier, ceci dans le but d'éviter la redondance d'informations. S'il n'est pas déjà présent dans le fichier «Clients.dat», le vendeur renseigne alors toutes les données nécessaires pour l'y ajouter. Le système lui propose une validation finale permettant l'écriture physique dans le fichier. Figure 14 Scénario «Ajout d'un nouveau Client» 15 / 19

16 6.3 Diagramme de séquence du cas d'utilisation «Gestion des Ventes» Lorsqu'un client souhaite effectuer un achat, il en fait requête auprès du vendeur qui, lui, tente d enregistrer cette vente via notre logiciel. Catalogiciel vérifie alors dans un premier temps que le client existe dans le fichier Client sinon il propose au vendeur de le créer, ensuite il vérifie l existence de l article concerné, s il n existe pas il prévient le vendeur. Si le stock de l article est suffisant la vente est enregistrée, le vendeur est averti et il transmet l information au client. Dans le cas ou le stock n est pas suffisant il est possible pour le vendeur d effectuer une réservation que Catalogiciel va enregistrer dans le fichier vente mais avec un attribut qui la différencie d une vente habituelle, la réservation est alors effectuée, le vendeur averti et l information transmise au client par le vendeur. La figure ci-dessous (cf Figure 14) modélise ce scénario. Figure 15 Scénario «Ajouter une vente» 16 / 19

17 6.4 Diagramme de séquence du cas d'utilisation «Statistiques» Enfin, dans cette quatrième partie, le scénario (cf Figure 16) représente la situation «obtenir une statistique». Un vendeur demande à établir un type de statistique selon les choix proposés par le menu. Si le type est reconnu comme étant un choix possible, l'utilisateur aura à renseigner les paramètres nécessaires à l'obtention de la statistique demandée. Par la suite, le programme ira chercher les informations contenues dans les fichier client, article et vente selon le besoin et calculera la statistique puis l'affichera. Figure 16 Scénario «Demander une statistique» 17 / 19

18 7. INTERFACE RAPPORT COBOL MINI-PROJET GESTION VENTES D'ARTICLES Nous avons défini une charte graphique et ainsi maquetté une interface idéale souhaitée de façon à visualiser l'aspect futur de notre programme de gestion de vente d'articles : CATALOGICIEL. Figure 17 - Vue du menu principal Figure 18 - Vue du menu ajouter un article 18 / 19

19 8. POINT À MI-PARCOURS La partie d'analyse nous a permis de décomposer et de visualiser au mieux les futures fonctions de notre logiciel. Au vu du temps imparti, nous avons du poser un périmètre limitant les possibilités afin de respecter le délai et finaliser le programme tel que nous le prévoyons. De plus, cette phase d'analyse nous a permis de faire le lien avec une autre de nos matières : la modélisation UML.. Au final, nous avons bien structuré notre minilogiciel ainsi que son interface. La gestion des différents fichiers a également été prévue, de même pour les fonctionnalités. On rappelle que les scénarios présentés dans la partie 9 nous serviront de tests. La répartition du travail a également été explicitée. Grâce à cette phase d'analyse poussée, nous pouvons désormais attaquer tranquillement le développement. 19 / 19