Mémoire de Findecycle
Mémoire de Findecycle
Mémoire de Findecycle
Thème :
DEDICACE
2
Gestion des fournisseurs de la GERBATP sarl
REMERCIEMENTS
3
Gestion des fournisseurs de la GERBATP sarl
DEDICACE .......................................................................................................... 2
REMERCIEMENTS .............................................................................................. 3
INTRODUCTION .............................................................................................12
2. Objectifs ........................................................................................ 12
2. Problématique ................................................................................ 14
1. Objectifs ........................................................................................ 15
4
Gestion des fournisseurs de la GERBATP sarl
CONCLUSION .................................................................................................19
INTRODUCTION .............................................................................................20
I. ANALYSE .....................................................................................................20
4. Modélisation du contexte................................................................... 23
CONCLUSION .................................................................................................33
INTRODUCTION .............................................................................................34
5
Gestion des fournisseurs de la GERBATP sarl
I. CONCEPTION ...............................................................................................34
CONCLUSION .................................................................................................43
INTRODUCTION .............................................................................................44
I. IMPLEMENTATION .....................................................................................44
II.TESTS ...........................................................................................................45
2. Politique de sécurité..................................................................... 47
CONCLUSION .................................................................................................48
ANNEXES : ......................................................................................................50
6
Gestion des fournisseurs de la GERBATP sarl
V. LE DIAGRAMME DE SEQUENCE..............................................................57
VII.BIBLIOGRAPHIE ....................................................................................59
7
Gestion des fournisseurs de la GERBATP sarl
8
Gestion des fournisseurs de la GERBATP sarl
9
Gestion des fournisseurs de la GERBATP sarl
AVANT PROPOS
L’institut Burkinabé des Arts et Métiers (IBAM) est l’un des instituts de l’Université
de Ouagadougou (UO). Il s’insère dans le cadre des établissements d’enseignement
professionnel au Burkina Faso. Il a vu le jour en Janvier 2000 suite à la refondation de
l’Université de Ouagadougou dans son ensemble. L’IBAM s’est fixé comme objectifs
principale, la mise à la disposition des divers secteurs d’activité un potentiel humain de
techniciens supérieurs, cadres moyens et supérieurs.
A son ouverture, l’IBAM comptait deux (02) filières de formation qui sont :
DUT option Finance Comptabilité (FC) ;
DUT option Secrétariat de Direction/ Secrétariat Bilingue (SD/SB).
Et depuis 2006, il dispose en plus des deux filières ci-dessus, de sept (07) filières de
formations qui sont :
La filière MST/ MIAGE vise à répondre aux besoins croissants du marché de l’emploi
en mettant à sa disposition des cadres de bon niveau dans le domaine de la technologie
et des techniques informatique.
La formation MIAGE est ouverte aux détenteurs d’un DEUGII en Mathématique
Physique, Physique-Chimie, Science-Economie et Gestion ou d’un diplôme
équivalent.
L’IBAM prévoie pour les étudiants en fin de cycle en MST/MIAGE un stage pratique
dans une entreprise publique ou privée. Ce stage a une durée de trois à cinq mois et
vise à renforcer les compétences de l’étudiant dans la conception et la réalisation des
systèmes d’information ainsi que de faciliter son intégration rapide dans le milieu
professionnel. C’est dans ce cadre que s’inscrit ce présent mémoire sur le thème «
Conception et réalisation d’une application de gestion pour la GERBATP sarl ».
10
Gestion des fournisseurs de la GERBATP sarl
INTRODUCTION GENERALE
Durant ces dernières années l'informatique s'est imposée d'une manière très
impressionnante dans les entreprises.
L'informatique désigne l'automatisation du traitement de l'information par un système
concret «machine» ou abstrait. L’informatique est de plus en plus utilisée dans tous les
domaines d'activités dont la gestion des fournisseurs.
En effet, l'ensemble des traitements des fournisseurs au sein de la GERBATP se
faisait manuellement, c’est ce qui a conduit cette structure à solliciter une
application pour la gestion automatique des fournisseurs.
Pour la réalisation de cette tâche, notre choix s'est porté sur la méthode d’analyse
Unified Process(UP).En effet, le processus unifié est une solution de
développement logiciel piloté par les cas d’utilisation, centré sur l'architecture,
itératif et incrémental.Le langage de modélisation utilisé est UML (Unified
Modeling Language), pour modéliser, documenter et d’écrire notre système
logiciel. Pour l'implémentation, le choix du langage de programmation à été dicté
par le type de l'application qui devrait être portable. Ainsi, le choix s'est porté sur
le langage de programmation JAVA. La base de données est implémentée avec
MySQL qui est compatible avec JAVA.
Le document est organisé comme suite :
Dans le premier chapitre, nous présenterons l'organisme d'accueil, approfondir la
compréhension du contexte du système.
Puis, au deuxième chapitre, nous analyserons les principaux objectifs attendus du futur
système à concevoir, et qui seront décrits par le diagramme des cas d'utilisation.
Au niveau du troisième chapitre, nous Recenserons les choix orientant la conception
du système : outils et matériels sélectionnés, ainsi que les contraintes d’intégration
avec ce qui existe déjà.
Finalement dans le dernier chapitre, nous présenterons les outils de développement qui
nous ont servi pour le développement de l'application, et enfin l'activité test qui
consiste, justement, à la tester dans le but de s'assurer de son bon fonctionnement.
11
Gestion des fournisseurs de la GERBATP sarl
CHAPITRE I : INTRODUCTION
INTRODUCTION
La gestion des fournisseurs au sein de la GERBATP est une opération rigoureuse, qui
mérite d'être perfectionnée et analysée soigneusement ; mais avant d'essayer
d’apporter une solution informatique pour ce processus, la présentation de l'organisme
d'accueil en général et les services qui gèrent les mouvements des fournisseurs au
niveau de la GERBATP en particulier est nécessaire.
1. Situation géographique
12
Gestion des fournisseurs de la GERBATP sarl
13
Gestion des fournisseurs de la GERBATP sarl
1. Présentation du thème
Les logiciels de gestion des fournisseurs sont inadéquats le plus souvent aux besoins
spécifiques des entreprises. Par conséquent, la conception et le développement d’une
application de gestion en interne devient nécessaire pour une entreprise cherchant à
voir ses contraintes spécifiques prises en compte. C’est ce qui fait l’objet du présent
stage. L’application à développer doit être adaptée aux besoins particuliers du Service
Achat de la GERBATP.
2. Problématique
Le système actuel de gestion des fournisseurs au niveau des différents services est
manuel. Cette gestion handicape plus ou moins le fonctionnement des dits services. Au
nombre des difficultés, nous pouvons citer :
3. Résultats attendus
L’objectif principal de notre travail est de concevoir et réaliser une application de
gestion des fournisseurs. Ainsi, l’application à mettre en place doit répondre à
certaines fonctions telles que :
En plus des fonctions sus citées au dessus, nous avons des fonctionnalités globales
attendu du système ; notamment :
14
Gestion des fournisseurs de la GERBATP sarl
Le groupe de pilotage a pour rôle de fixer les orientations, de prendre les décisions
importantes concernant le projet et de valider les travaux. Il définit aussi les moyens à
mettre en place pour la réalisation du projet. Il s’agit de :
M. Benoit YE (DAF),
M. Martin KAGAMBEGA (Responsable Service Achat),
M. Sadouanouan MALO (Directeur de Mémoire).
Le groupe des utilisateurs joue un rôle consultatif. Il est chargé de fournir toutes les
Informations nécessaires à la bonne conduite du projet.
Il est composé de :
1. Objectifs
15
Gestion des fournisseurs de la GERBATP sarl
2. Méthode d’analyse
3. Le processus unifié
3.1. Définition
Pour définir le processus unifié, nous allons simplement définir les deux termes qui le
composent :
Piloté par les cas d'utilisation : Le processus suit une voie spécifique, en procédant
par une série d'enchaînement d'activités, dérivées d'un cas d'utilisation. Un cas
d'utilisation est analysé, conçu, implémenté et enfin testé.
Centré sur l'architecture : L'architecture logicielle représente les aspects statiques et
dynamiques du système. L'architecture émerge des besoins de l'entreprise, tels qu'ils
sont exprimés par les utilisateurs et reflétés par les cas d'utilisation. L'architecture
propose une vue d'ensemble de la conception faisant ressortir les caractéristiques
essentielles en laissant de côté les détails secondaires. Il faut noter que tout produit
est à la fois forme et fonction. L'une ou l'autre isolément ne saurait suffir. Les cas
d'utilisation et l'architecture doivent s'équilibrer pour créer un produit réussi.
16
Gestion des fournisseurs de la GERBATP sarl
Itératif et incrémental : Vu que les projets à réaliser sont de plus en plus complexes
et grands, l'idée est de découper le travail en mini projets. Chacun d'entre eux
représente une itération qui donne lieu à un incrément. Les itérations désignent des
étapes de l'enchaînement d'activités, tandis que les incréments correspondent à des
stades de développement du produit.
3.3.2. Elaboration :
C'est la deuxième phase du processus. Après avoir compris le système, dégagé les
fonctionnalités initiales, précisé les risques critiques, le travail à accomplir maintenant
consiste à stabiliser l'architecture du système. Il s'agit alors de raffiner le modèle initial
de cas d'utilisation, voir capturer de nouveaux besoins, analyser et concevoir la
majorité des cas d'utilisation formulés, et si possible implémenter et tester les cas
d'utilisation initiaux.
17
Gestion des fournisseurs de la GERBATP sarl
3.3.3. Construction :
Dans cette phase, il faut essayer de capturer tous les besoins restants car il n'est
pratiquement plus possible de le faire dans la prochaine phase. Ensuite, continuer
l'analyse, la conception et surtout l'implémentation de tous les cas d'utilisation. A la fin
de cette phase, les développeurs doivent fournir une version exécutable du système.
3.3.4. Transition :
C'est la phase qui finalise le produit. Il s'agit au cours de cette phase de vérifier si le
système offre véritablement les services exigés par les utilisateurs, détecter les
défaillances, combler les manques dans la documentation du logiciel et adapter le
produit à l'environnement (mise en place et installation).
4. Planning du travail
4.1. Planning prévisionnel
18
Gestion des fournisseurs de la GERBATP sarl
CONCLUSION
Cette première phase du Processus Unifié nous a permis non seulement d'avoir une
vue détaillée de l'état actuel de l'organisme d'accueil, mais aussi de nous familiariser
avec les différentes activités et traitements qui se font au sein du service achat. Il faut
noter que la présentation du contexte réalisé au niveau de cette étape nous a donné déjà
un premier aperçu sur l'application à concevoir, ouvrant ainsi la porte à la deuxième
étape du Processus Unifié intitulé «Analyse des besoins », que nous allons détailler
dans le prochain chapitre de notre mémoire.
19
Gestion des fournisseurs de la GERBATP sarl
INTRODUCTION
Dans le cadre de ce chapitre, nous allons définir les étapes concernant les besoins
fonctionnels de l’organisme pour la réalisation de notre projet. Nous allons définir
l’analyse du processus de développement du logiciel tout en montrant les besoins
fonctionnels, et enfin nous allons présenter les diagrammes de cas d’utilisation.
I. ANALYSE
20
Gestion des fournisseurs de la GERBATP sarl
Livraison
Le fournisseur livre les matériels demandés, ci-joint les factures, les DA, les Pro
Formats, les BC, les BL. le magasinier vérifie la conformité du bordereau de
livraison à la quantité et la qualité des matériels. Dans le cas Favorable, le
magasinier signe le bordereau de livraison.
Ces mêmes documents sont immédiatement transmis au secrétariat pour
enregistrement dans le cahier de suivi des factures reçues.
Une copie du bordereau de livraison reste avec le magasinier et l’original est
envoyé au fournisseur qui le joindra ultérieurement à sa facture pour règlement.
21
Gestion des fournisseurs de la GERBATP sarl
les factures sont comptabilisées dès leur réception par le service comptable après
vérification des conditions de prix et de règlement (crédit, espèce ou par chèque).
Le service comptable tient un journal d’achats qui permet d’enregistrer dans
l’ordre chronologique les factures classées par numéro.
Apres vérification de l’originale de la facture, de la Demande d’Achat, du Bon de
Livraison et du Bon de Commande (vérification des prix unitaires, des conditions
de règlement, des remises accordées), le comptable appose le timbre bon a payer.
Après délivrance du bon à payer, les factures sont transmises au comptable
fournisseur pour imputation dans le fichier fournisseur.
Définition : un acteur représente l'abstraction d'un rôle joué par des entités externes
(utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le
système étudié.
22
Gestion des fournisseurs de la GERBATP sarl
4. Modélisation du contexte
A partir des informations obtenues lors des étapes précédentes, nous allons modéliser
le contexte de notre application.
Ceci va nous permettre dans un premier temps, de définir le rôle de chaque acteur
dans le système :
23
Gestion des fournisseurs de la GERBATP sarl
COMPTABLE
FOURNISSEUR
SYSTEME
24
Gestion des fournisseurs de la GERBATP sarl
Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au
système.
25
Gestion des fournisseurs de la GERBATP sarl
26
Gestion des fournisseurs de la GERBATP sarl
27
Gestion des fournisseurs de la GERBATP sarl
Utilisateur Systeme
<Non OK>
Decision_1
<OK>
Utilisateur Systeme
<Authentification réussie>
Affichage page d'accueil
Affichage du formulaire
Enregistrement Prévisualisation
Decision_2
28
Gestion des fournisseurs de la GERBATP sarl
Utilisateur Systeme
<Authentification réussie>
Affichage page d'accueil
Affichage de la page
<OK> <OK>
Decision_2
<NON OK>
29
Gestion des fournisseurs de la GERBATP sarl
Utilisateur Systeme
<Authentification réussie>
Affichage page d'accueil
Affichage formulaire
Vérifier disponibilité
Afficher liste
Imprimer
30
Gestion des fournisseurs de la GERBATP sarl
V. LE DECOUPAGE EN CATEGORIE
Cette phase marque le démarrage de l’analyse objet du système à réaliser.
Elle utilise la notion de package pour définir des catégories de classes d’analyse et
découper le modèle UML en blocs logiques les plus indépendants possibles.
Le découpage en catégories constitue la première activité de l’étape d’analyse et elle
va s’affiner de manière itérative au cours du développement du projet.
Définition : une catégorie consiste en un regroupement logique de classes à
forte cohérence interne et faible couplage externe.
Le découpage en catégories de notre projet a donné le résultat suivant :
31
Gestion des fournisseurs de la GERBATP sarl
E x p r e s s io n d e s B e s o in s E ta t d e s B o n s
<< c a te g o r y > > < <c a te g o r y >>
+D em an de d'ac hat
+ M a t e r ie l +B on de co m m an de
+D em an de ur + P r o f o rm a
+ S e rv ic e + F o u r n i ss e u r
+ B o n d e liv r a is o n
F a c tu re
C om m an de < < c a te g o r y > >
< < c a te g o ry > >
+Fa cture
+ R e g le m e n t
+C o m m an de + P r o p o s iti o n
+ C h a n t ie r
E x p r e s s io n d e s B e s o i n s E t a t d e s b e s o in s
< < c a te g o r y > > < < c a te g o r y > >
+ D e m a n d e d 'a c h a t +B on de co m m an de
+ M a t e r ie l + P r o f o rm a
+ D em and eu r + F o u r n i ss e u r
+ S e r v ic e + B o n d e liv r a is o n
C o m m and e F a c tu r e
< < c a te g o r y > > < < c a te g o r y > >
+Fa cture
+C o m m an de + R e g le m e n t
+ C h a n t ie r + P r o p o s it io n
32
Gestion des fournisseurs de la GERBATP sarl
CONCLUSION
Cette étape du Processus UP nous a permis de nous familiariser avec les différentes
activités et traitements qui se font concernant la gestion des fournisseurs. Il faut noter
que les diagrammes réalisés au niveau de cette étape nous ont donné déjà un premier
aperçu sur l'application à concevoir, ouvrant ainsi la porte aux étapes suivantes du
Processus UP que nous allons détailler dans le prochain chapitre de notre mémoire.
33
Gestion des fournisseurs de la GERBATP sarl
INTRODUCTION
La capture des besoins techniques couvre, par complémentarité avec celle des besoins
fonctionnels, toutes les contraintes qui ne traitent ni de la description du métier des
utilisateurs, ni de la description applicative. La spécification technique est primordiale
pour la conception d’architecture.
I. CONCEPTION
La conception de logiciel est un art qui nécessite de l'expérience, et elle consiste à
traduire les besoins en spécifiant comment l'application pourra les satisfaire avant de
procéder à sa réalisation. En effet, dans ce chapitre nous essayons d'étendre la
représentation des diagrammes effectués au niveau de l'analyse en y intégrant les
aspects techniques plus proches des préoccupations physiques.
Les concepteurs dans cette phase construisent les classes, les vue d’IHM, les
interfaces, les tables et les méthodes qui vont donner une image « prête à coder » de la
solution.
1. Diagramme de séquences
Le diagramme de séquence montre les interactions entre les objets en mettant l’accent
sur l’aspect temporel (la chronologie des envois de messages). Le diagramme de
séquence montre les interactions entre les objets en mettant l’accent sur l’aspect
temporel (la chronologie des envois de messages). Il permet de mieux visualiser la
séquence des messages pour une lecture du haut vers le bas. L’axe vertical représente
le temps, l’axe horizontal représente les objets qui collaborent. Une ligne verticale en
pointillé est attachée à chaque objet et représente sa ligne de vie.
34
Gestion des fournisseurs de la GERBATP sarl
Système
Acteur
Lancement du systeme
Verification
opt [Si corrects]
Affichage du Menu de l'utilisateur
DiagrammeSequence_2
système
Service achat
Authentification
Affiche formulaire
Affiche resultat
35
Gestion des fournisseurs de la GERBATP sarl
DiagrammeSequence 3
système2
Comptable
Authentification
Editer facture
facture
2. Le diagramme de composants
Parmi tous les facteurs qui concourent à la qualité d’un logiciel, nous retrouvons la
notion de réutilisabilité comme étant l’aptitude d’un logiciel à être réutilisé, en entier
ou en partie, dans de nouvelles applications.
Ainsi pour faire face à cela, un concept plus générique et fédérateur : celui de
composant. Un composant doit fournir un service bien précis. Les fonctionnalités qu’il
encapsule doivent être cohérentes entre elles et génériques (par opposition à
spécialisées) puisque sa vocation est d’être réutilisable.
La relation de dépendance est utilisée dans les diagrammes de composants pour
indiquer qu’un élément de l’implémentation d’un composant fait appel aux services
offerts par les éléments d’implémentation d’un autre composant.
36
Gestion des fournisseurs de la GERBATP sarl
Couche de
présentation
Couche Métier
Interface utilisateur
Base de
Données
37
Gestion des fournisseurs de la GERBATP sarl
La couche Métier :
Voici quelques figures représentants un échantillon du code source de cette
couche :
38
Gestion des fournisseurs de la GERBATP sarl
La couche Présentation :
Voici quelques figures représentants l’interface du logiciel :
39
Gestion des fournisseurs de la GERBATP sarl
40
Gestion des fournisseurs de la GERBATP sarl
II .ARCHITECTURE LOGICIELLE
La technologie Objet est une architecture qui organise les interactions entre objets.
On a l'habitude de regrouper ces objets en classes, ces classes en domaines, et ces
domaines en couches.
Les couches permettent de présenter l'architecture de l'application. Aussi, si modéliser
est indispensable, construire une architecture à couche est un critère de qualité dans le
cadre d'un développement Objet. Reste à choisir le nombre de couches et à définir leur
contenu.
L’architecture client/serveur désigne un mode de communication entre plusieurs
Ordinateurs d'un réseau qui distingue un ou plusieurs postes clients du serveur :
chaque poste client peut envoyer des requêtes au serveur. En effet, elle permet la
centralisation des données au niveau du serveur, ce qui facilite le contrôle de sécurité
et la mise à jour des données. Cependant le cout de réalisation est élevé.
La figure suivante représente l’architecture adoptée. C’est une architecture client
serveur 2-tiers et le SGBD est MySQL :
Le client émet une requête vers le serveur grâce à son adresse et le port, qui
désigne un service particulier du serveur
Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client
et son port.
Pour avoir une architecture robuste, modulable et évolutive, il nous faut utiliser le
principe de « couche ».
Nous allons donc séparer en trois couches les différents types de traitement de
l’application (Dao, Métier, Présentation).
III. METHODE DE CALCUL DU COUT DE DEVELOPPEMENT
Une des méthodes d’évaluation des couts de développement la plus utilisée est
COCOMO. Le modèle COCOMO (acronyme pour COnstructive COst MOdel) ou
encore COCOMO simple, premier modèle datant de 1981, et développé par Dr. Barry
Boehm. Il permet d’estimer le coût, en nombre de mois-homme (l’effort à fournir dans
le développement logiciel), et le temps de développement d'un produit logiciel. Cette
méthode existe en trois versions: simple, intermédiaire et détaillée.
Nous allons présenter les grandes lignes de la méthode simplifiée car nous l’utiliserons
pour la prévision des coûts et des délais du projet.
Le modèle COCOMO simple permet une évaluation grossière de l’effort à consentir en
s’appuyant sur la formule générale : Effort = A (KILS)b .
41
Gestion des fournisseurs de la GERBATP sarl
42
Gestion des fournisseurs de la GERBATP sarl
CONCLUSION
A l'issue de cette étape nous avons pu exprimer clairement les objectifs attendus du
futur système à concevoir, ainsi que la conception associée et l’architecture adoptée,
sans s'attacher à aucun outil de développement.
43
Gestion des fournisseurs de la GERBATP sarl
CHAPITRE IV : REALISATION
INTRODUCTION
A ce stade du processus, les cas d'utilisation sont terminés, le problème a été analysé
en profondeur ; nous avons défini une conception mieux appropriée aux besoins de
l'application. Nous pouvons alors entreprendre la dernière activité du Processus Unifié
qui est de même composé de deux parties (implémentation et test), ayant comme
objectif d'aboutir à un produit final, exploitable par les utilisateurs. Dans cette phase
nous allons présenter les outils de modélisation et de développement que nous avons
utilisé, implémenter tout les cas d'utilisation, et enfin les tester.
I. IMPLEMENTATION
1. Outils de modélisation
La mise en place de notre architecture logicielle et la réalisation des fonctionnalités de
l’application nécessitent un certain nombre d’outils. Le choix de ces outils dépende du
type ou de la nature de l’application à réaliser. Pour ce qui nous concerne, nous
utiliserons :
Power AMC et PaceStar UML pour la représentation conceptuelle des diagrammes
utilisés.
Microsoft Visio 2003 pour le diagramme de réseau.
2. Outils de développement
Pour réaliser notre application, nous avons utilisé le langage de programmation JAVA
dédié à la création des applications orientée objet, celui-ci nous l'avons manipulé dans
un environnement de développement intitulé NetBeans.
2.1. NetBeans
44
Gestion des fournisseurs de la GERBATP sarl
Pour implémenter notre base des données nous avons utilisé l'environnement de
création de base des données PHPMyAdmin et le système de gestion de base des
donnés MySQL. Le tableau ci-dessous présente notre base de données :
II.TESTS
Cette activité consiste à tester les résultats de l'implémentation pour s'assurer du bon
déroulement des fonctionnalités du système. Lors de l'évaluation des tests effectués, si
nous détectons une anomalie quelconque, nous devrions la corriger.
45
Gestion des fournisseurs de la GERBATP sarl
Cette tâche consiste à établir une demande d’achat et de l'enregistrer dans la base de
données.
Nous avons créé une demande d’achat fictive et voici ses attributs montrés dans cette
capture d'écran de l'application :
Le formulaire vierge étant affiché, nous avons saisi les informations montrées dans la
capture ci-dessus. En validant, la demande d’achat doit figurer dans notre base de
données.
En effet, Nous avons vérifié l'existence de la demande d’achat dont le numéro est« 1 »
dans la base de données, la vérification est réussie.
1.3. Test du cas d’utilisation «imprimer une demande d’achat»
Toujours sur la même demande d’achat, nous avons effectué des modifications sur ses
informations. Et Apres avoir consulté la demande d’achat.
Nous avons constaté que les informations modifiées ont été prises en considération. Le
test de modification est réussi.
46
Gestion des fournisseurs de la GERBATP sarl
1. Procédure de secours
La procédure actuelle de secours de la GERBATP sera conservée. Néanmoins, nous
proposons les lignes suivantes :
Panne électrique :
Le serveur sera muni d'un onduleur afin de prévenir les pannes d'électricité. En cas de
panne électrique, chaque utilisateur de poste de travail devra d’abord enregistrer
l’ensemble des traitements pendant le temps d’autonomie des onduleurs.
47
Gestion des fournisseurs de la GERBATP sarl
Politique de sauvegarde
L’accès au local technique sera interdit à toute personne dont l’identité n’est pas bien
connue.
CONCLUSION
Dans ce chapitre, nous avons décrit brièvement le processus de réalisation de notre
application en spécifiant l'environnement de développement, l'implémentation de la
base des données. En effet, nous avons achevé l'implémentation et les tests de tous les
cas d'utilisation, tout en respectant la conception élaborée. Ainsi nous avons prévenu la
plate forme sous laquelle le système sera installé dans l'environnement des utilisateurs.
48
Gestion des fournisseurs de la GERBATP sarl
CONCLUSION GENERALE
Ce stage a été d’un grand apport pour nous. Il nous a permis de mettre en pratique nos
connaissances pratiques et théoriques acquises au cours de notre formation. Il nous a
permis également de prend goût des réalités de la vie professionnelle. Les chapitres
élaborés ont fait l’objet d’une étude préliminaire, conceptuelle et de la définition d’une
architecture logicielle. Ces études ont permis de connaître notre structure d’accueil, de
déceler le problème et de délimiter notre système par un diagramme de collaboration. Ils
ont fait également l’objet de proposition de définition des procédures de secours et de
sécurité nécessaire à l’utilisation de l’application.
Aussi, l’application que nous avons nommé « GestionFrs » à vu sa réalisation. Mais
les trois mois ont été insuffisants pour sa réalisation, cela est constaté par l’estimation du
temps par la méthode COCOMO.
Nous suggérons pour un travail d’une telle envergure, d’accorder un temps de
réalisation supérieur à trois mois.
49
Gestion des fournisseurs de la GERBATP sarl
ANNEXES :
1. Présentation et Historique
1.1. Présentation
UML est le langage de modélisation le plus utilisé de nos jours. Il est utilisé pour la
compréhension et la description des besoins des utilisateurs, la spécification et
l’établissement de l’architecture logicielle d’un système. Il est né de la fusion de trois
(03) méthodes de référence :
OMT (Object Modeling Technique) développée par James Rumbaugh dans le Centre
de Recherche et Développement de la société General Electric à la fin des années 80 ;
BOOCH (Méthode de Grady Booch) publié en 1981 dans le livre OOD (Object
Oriented Development) ;
OOSE (Object Oriented Software Engineering) développée par Ivar Jacobson.UML,
qui n’est ni une méthode ni un processus n’impose pas une démarche particulière pour
l’analyse d’un système.
UML 2.0 définit treize (13) diagrammes pour formaliser et décrire un système. Ces
diagrammes sont repartis en deux types de vues : une vue statique représentant le
système physiquement et une vue dynamique montrant le fonctionnement du système.
On compte six(06) diagrammes du point de vue statique (diagramme de classes,
diagramme d’objet, diagramme de composants, diagramme de paquetage, diagramme
de déploiement et le diagramme de structure composite) et sept (07) du point de vue
dynamique (diagramme de cas d’utilisation, diagramme de timing, diagramme de
collaboration, diagramme de séquence, diagramme état/transition, diagramme de
communication et le diagramme d’activité). Nous ne décrirons que les différents
diagrammes utilisés dans notre projet.
Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au
système. Il constitue un des diagrammes les plus structurants dans l'analyse d'un
système.
Le diagramme de classes
50
Gestion des fournisseurs de la GERBATP sarl
Le diagramme de séquence
Le diagramme d'activités
Il décrit les fonctionnalités d’un cas d’utilisation. Permet de bien comprendre les
différentes activités réalisées et leur enchaînement dans le temps ;
Le diagramme de collaboration
Ce diagramme décrit l'architecture technique d'un système avec une vue centrée sur la
répartition des composants dans la configuration d'exploitation.
1.2. Historique
Cette figure ci-dessous montre l'évolution des versions d'UML depuis sa genèse.
51
Gestion des fournisseurs de la GERBATP sarl
• Acteur
Un acteur est un utilisateur du système. Il peut être : soit un humain, soit un logiciel ou soit un
automate.
On distingue les acteurs physiques et les acteurs non physiques
Un acteur physique
<< Actor>>
Acteur non physique (Systèmes connexes)
Nom acteur
• Cas d’utilisation
CU Un cas d’utilisation
La relation d’inclusion sert à enrichir un cas d’utilisation par un autre cas d’utilisation.
Une relation d’inclusion d’un « cas d’utilisation B » vers un « cas d’utilisation A»
indique qu’une instance du « cas d’utilisation B » contient également le comportement
spécifié par le « cas d’utilisation A ».
« Include »
CUA CUB
52
Gestion des fournisseurs de la GERBATP sarl
«Extend»
CUC CUB
Domaine d’étude
<< Actor>>
Cas d’utilisation A
<<Include>>
Cas d’utilisation B
<<Extend>>
Acteur interne
Cas d’utilisation C
Une classe est la description abstraite d’un ensemble d’objets ayant les mêmes
caractéristiques (attributs), le même comportement et les mêmes relations sémantiques.
53
Gestion des fournisseurs de la GERBATP sarl
Portabilité/Visibilité
Nom de la classe
+ attribut1: type
- attribut2: type
- operation1 ()
+ opération2 (arg)
Définitions
Méthodes : une méthode ou opération est une fonctionnalité assurée par la classe.
Attributs : un attribut est une information élémentaire composant une classe.
Un attribut peut permettre d’identifier la classe. Il est typé (Integer, Real, String…).
Visibilités : UML définit trois niveaux de visibilité pour les attributs et les opérations :
Public (+) qui rend l’élément visible à tous les clients de la classe ;
• Protégé (#) qui rend l’élément visible aux sous classes de la classe ;
• Privé (-) qui rend l’élément visible à la classe seule.
P1..P2 Q1..Q2
Classe A Classe B
54
Gestion des fournisseurs de la GERBATP sarl
min..max min..max
Classe Agrégat Classe Agrégée
Composition : C’est une agrégation forte. Elle exprime une relation de contenance.
La suppression d’un objet agrégat entraîne la suppression des objets agrégés.
La valeur maximale de multiplicité du conteneur ne doit pas excéder 1.
S
Classe Générique p
G
é
é
n c
é i
r a
a l
l i
i Classe Spécialisée s
s a
a t
t
55
Gestion des fournisseurs de la GERBATP sarl
Formalisme utilisé
Classe
Classe association
Attributs : integer
Définition
Transition : Une transition matérialise le passage d’une activité vers une autre. Les transitions
sont déclenchées par la fin d’une activité et provoquent le début d’une autre
(elles sont automatiques).
56
Gestion des fournisseurs de la GERBATP sarl
Etat initial
Activité 4 Activité 5
Etat final
V. LE DIAGRAMME DE SEQUENCE
57
Gestion des fournisseurs de la GERBATP sarl
• L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical
du diagramme ; le temps s'écoule "de haut en bas" de cet axe.
• La disposition des objets sur l'axe horizontal n'a pas de conséquence pour la
sémantique du diagramme.
58
Gestion des fournisseurs de la GERBATP sarl
REFERENCES ET BIBLIOGRAPHIE :
VII.BIBLIOGRAPHIE
Informatique documentaire d’André DEWEZE Docteur de l’université Claude Bernard
(Lyon) sciences mathématiques ;
UML 2 par la pratique de Pascal Roques ;
Télé Enseignement - Cnam des Pays de Loire, Méthodologie B8 : Le Langage UML,
Présentation Générale de Claude Belleil - Université de Nantes ;
Mesure et estimation des coûts de développement de logiciels de Julien
Tessier,Ligeron SA ;
Projet de fin de cycle 2009-2010 sur le thème «GESTION DES COMMANDES
FOURNISSEURS SOUS MICROSOFT DYNAMICS NAV». présenté par
M.Souleymane SAVADOGO à l’Institut Burkinabé des Arts et Métiers.
Projet de fin de cycle 2008-2009 : sur le thème «Conception et réalisation d’une
application web d’aide à la gestion de la maintenance» présenté par
M. Aboudou TRAORE à l’Institut Burkinabé des Arts et Métiers.
VIII. SITES
www.uml.free.fr;
http://fr.wikipedia.org;
http://www.developper.com;
http://www.siteduzero.com.
59