Vous êtes sur la page 1sur 59

Ministère des Enseignements Burkina Faso

Secondaire et Supérieur Unité-Progrès-Justice


---------- ----------
Université de Ouagadougou GENERALE D’ENTREPRISE DE
REALISATION DE BATIMENTS ET
---------- TRAVAUX PUBLICS
Institut Burkinabé des Arts et Métiers ----------
(IBAM)

03 BP 7021 Ouagadougou 03 01 BP 6527 Ouagadougou 01


Tel. :( +226) 50 35 67 31/62 Tel. :( +226) 50 39 02 01
Site web: ibam.univ-ouaga.bf Site web: www.gerbatpsarl.com

Mémoire de fin de cycle pour l'obtention du diplôme de Maitrise en Sciences


Techniques option Méthodes Informatiques Appliquées à la Gestion
(MST/MIAGE)

Thème :

CONCEPTION ET REALISATION D’UNE APPLICATION POUR


LA GESTION DES FOURNISSEURS DE GERBATP SARL

Période : 05 octobre 2011 au 05 janvier 2012

Directeur de Mémoire : Maître de stage :


Monsieur MALO Sadouanouan Monsieur DEN Bia yacouba
Enseignant à l’IBAM Informaticien à GERBATP SARL

ANNÉE ACADÉMIQUE 2010-2011


Gestion des fournisseurs de la GERBATP sarl

DEDICACE

A mes très chers parents

Pour tout l'amour que vous m'avez donné, pour


tout ce que vous avez fait pour moi.
Je ferai de mon mieux pour rester un sujet de
fierté à vos yeux avec l'espoir de ne jamais vous
décevoir.
Que ce modeste travail, soit l'exaucement de vos
veux tant formulés et de Vos prières quotidiennes.

A mes très chers frères et sœurs


Vous occupez une place particulière dans mon
cœur. Je vous dédie ce
travail en vous souhaitant un avenir radieux,
plein de bonheur et de succès.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

2
Gestion des fournisseurs de la GERBATP sarl

REMERCIEMENTS

La réalisation de ce mémoire est le fruit de notre


travail. Il n’en demeure pas moins que certaines
personnes y ont contribué de près ou de loin.
Aussi nous remercions très sincèrement :

 Monsieur Dominique KABORE,


Directeur Général de la GERBATP Sarl,
pour nous avoir acceptés au sein de sa
structure ;
 Monsieur Benoit YE, Directeur
Administratif et Financier pour ses
orientations et son accompagnement tout au
long de ce stage ;
 Monsieur Yacouba DEN, le maître de
stage pour son assistance et sa disponibilité
pendant le travail, qu’il trouve ici
l’expression de notre gratitude ;
 Monsieur Sadouanouan MALO, notre
Directeur de mémoire pour le suivi
académique, son aide et ces précieux
conseils;
 Le corps administratif et professoral de
l’IBAM et particulièrement les enseignants
qui ont fortement contribué à notre
formation ;
 Enfin, Nous remercions aussi tous nos amis
et collègues qui nous ont soutenu et tous ceux
qui ont contribué de près ou de loin à la
réalisation de ce travail.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

3
Gestion des fournisseurs de la GERBATP sarl

TABLE DES MATIERES

DEDICACE .......................................................................................................... 2

REMERCIEMENTS .............................................................................................. 3

LISTE DES SIGLES ET ABREVIATIONS ............................................................ 8

TABLE DES ILLUSTRATIONS ............................................................................ 9

AVANT PROPOS ...............................................................................................10

INTRODUCTION GENERALE .............................................................................11

CHAPITRE I : INTRODUCTION ..............................................................................12

INTRODUCTION .............................................................................................12

I .PRESENTATION DE LA STRUCTURE D’ACCUEIL ...................................12

1. Situation géographique ..................................................................... 12

2. Objectifs ........................................................................................ 12

3. Organisation de la GERBATP sarl ...................................................... 12

II. PRESENTATION DU PROBLEME ..............................................................14

1. Présentation du thème ...................................................................... 14

2. Problématique ................................................................................ 14

3. Résultats attendus ............................................................................ 14

4. Les acteurs du projet ........................................................................ 15

III. PRESENTATION DU CONTEXTE .............................................................15

1. Objectifs ........................................................................................ 15

2. Méthode d’analyse ........................................................................... 16

3. Le processus unifié .......................................................................... 16

Institut Burkinabé des Arts et Métiers GERBATP Sarl

4
Gestion des fournisseurs de la GERBATP sarl

4. Planning du travail .......................................................................... 18

5. Analyse des écarts entre le planning prévisionnel et le planning réel .......... 19

CONCLUSION .................................................................................................19

CHAPITRE II : ETUDE FONCTIONNELLE ..........................................................20

INTRODUCTION .............................................................................................20

I. ANALYSE .....................................................................................................20

1. Capture des besoins fonctionnels ........................................................ 20

2. Identification des acteurs .................................................................. 22

3. Identification des messages ................................................................ 23

4. Modélisation du contexte................................................................... 23

II. DIAGRAMME DES CAS D’UTILISATION .................................................25

1. Identification des cas d'utilisations .................................................. 25

2. Représentation du diagramme des cas d’utilisation .......................... 27

III. LE DIAGRAMME D’ACTIVITE .................................................................27

1. Représentations du diagramme d’activités ............................................ 28

IV. LE DIAGRAMME DE CLASSE ..................................................................30

1. Quelques règles de gestions ............................................................... 30

2. Représentation du diagramme de classe ............................................... 31

V. LE DECOUPAGE EN CATEGORIE .............................................................31

VI.DIAGRAMME DE PACKAGE D’ANALYSE ..............................................32

CONCLUSION .................................................................................................33

CHAPITRE III : ETUDE TECHNIQUE .................................................................34

INTRODUCTION .............................................................................................34

Institut Burkinabé des Arts et Métiers GERBATP Sarl

5
Gestion des fournisseurs de la GERBATP sarl

I. CONCEPTION ...............................................................................................34

1. Diagramme de séquences ................................................................. 34

2. Le diagramme de composants ............................................................ 36

3. L’application « Gestionfrs »(Gestion des Fournisseurs) .......................... 37

II .ARCHITECTURE LOGICIELLE .................................................................41

III. METHODE DE CALCUL DU COUT DE DEVELOPPEMENT....................41

CONCLUSION .................................................................................................43

CHAPITRE IV : REALISATION .............................................................................44

INTRODUCTION .............................................................................................44

I. IMPLEMENTATION .....................................................................................44

1. Outils de modélisation ...................................................................... 44

2. Outils de développement ................................................................... 44

3. Implémentation de la base de données .................................................. 45

II.TESTS ...........................................................................................................45

1. Quelques test de cas d’utilisations ....................................................... 46

III. PROCEDURE DE SECOURS ET SECURITE ..............................................47

1. Procédure de secours ................................................................... 47

2. Politique de sécurité..................................................................... 47

CONCLUSION .................................................................................................48

CONCLUSION GENERALE .............................................................................49

ANNEXES : ......................................................................................................50

I .LE LANGAGE UML......................................................................................50

1. Présentation et Historique ................................................................. 50

Institut Burkinabé des Arts et Métiers GERBATP Sarl

6
Gestion des fournisseurs de la GERBATP sarl

II. LE DIAGRAMME DE CAS D’UTILISATION ..............................................52

III. LE DIAGRAMME DE CLASSE ..................................................................53

IV. LE DIAGRAMME D’ACTIVITE.................................................................56

V. LE DIAGRAMME DE SEQUENCE..............................................................57

VI. ORGANIGRAMME de la GERBATP ..........................................................58

REFERENCES ET BIBLIOGRAPHIE ..........................................................59

VII.BIBLIOGRAPHIE ....................................................................................59

VIII. SITES ......................................................................................................59

Institut Burkinabé des Arts et Métiers GERBATP Sarl

7
Gestion des fournisseurs de la GERBATP sarl

LISTE DES SIGLES ET ABREVIATIONS


Abbreviation Signification
BD Base de Données
BC Bon de Commande
BL Bon de Livraison
COCOMO COnstructive COst Model
DA Demande d’Achat
DAF Direction Administrative et Financière
DESS Diplôme d’Etudes Supérieures Spécialisées
DAO Data Access Object
GERBATP Générale d’Entreprise de Réalisation de BAtiments et
de Travaux Publics
IBAM Institut Burkinabé des Arts et Métiers
KILS KILomètre par Seconde
MST/MIAGE Maitrise en Sciences Technique/Méthodes
Informatiques Appliquées à la Gestion
OOSE Object Oriented Software Engineering
OOD Object Oriented Development
OMT Object Modeling Technique
FP Facture Pro forma
RUP Rational Unified Process
SARL Société Anonyme à Responsabilité Limitée
SGBD Système de Gestion des Bases de Données
SQL Structured query language
2TUP 2Track Unified Process
UML Unified Modeling Language
UP Unified Process
UC Cas d’Utilisation (Use Case)

Institut Burkinabé des Arts et Métiers GERBATP Sarl

8
Gestion des fournisseurs de la GERBATP sarl

TABLE DES ILLUSTRATIONS


Figure Intitulé pages
N°1 Cycle de vie du Processus Unifié 17
N°2 Diagramme de contexte 24
N°3 Diagramme de cas d’utilisation du système 27
N°4 Diagramme d’activité du UC Authentification 28
N°5 Diagramme d’activité du UC enregistrement 28
N°6 Diagramme d’activité du UC consultation 29
N°7 Diagramme d’activité du UC Lister 30
N°8 Diagramme de classes 31
N°9 Découpage en catégories 32
N°10 Diagramme de package d’analyse 32
N°11 Diagramme de séquence de l'authentification 35
N°12 Diagramme de séquence de traitement des commandes 35
N°13 Diagramme de séquence de gestion des factures 36
N°14 Diagramme de composants du système 37
N°15 Code source de la classe demande achat 38
N°16 Code source de la classe demandeur 38
N°17 Fenêtre principale 39
N°18 Fenêtre d’authentification 39
N°19 Fenêtre d demande d’achat 40
N°20 Fenêtre de bon de commande 40
N°21 Architecture client/serveur 41
N°22 Base de Données du système 45
N°23 Evolution des versions d'UML 51
N°24 Formaliste du diagramme de classe 56

Institut Burkinabé des Arts et Métiers 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 :

 DUT option Gestion Commercial (GC) ;


 DUT option Banque ;
 Licence professionnel en Finance et Audit Comptable (LPFAC) ;
 Licence Professionnelle en Marketing et Gestion ;
 Licence professionnel en Banque ;
 Maîtrise en Sciences Techniques option Méthodes Informatiques Appliquées à la
Gestion des Entreprises (MST/MIAGE) ;
 Diplôme d’Etudes Supérieures Spécialisées en Ingénierie Informatique et
Technologies de l’Information et de la Communication (DESS/2ITIC).
 Diplôme d’Etudes Supérieures Spécialisées en Ingénierie Informatique et
Organisation et Protection des Systèmes d'Information.

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 ».

Institut Burkinabé des Arts et Métiers 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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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.

I .PRESENTATION DE LA STRUCTURE D’ACCUEIL

1. Situation géographique

La Générale d’Entreprise de Réalisation de Bâtiments et de Travaux Publics, en abrégé


GERBATP Sarl dont le siège est à Saaba Nioko 1, parcelle 01, lot 27, section AN une
commune rurale de la province du Kadiogo, est une Société A Responsabilité Limitée.
2. Objectifs
A l’instar des autres entreprises du Burkina Faso, la GERBATP Sarl a pour vocation
d’accroître sa part du marché. A ce titre elle a mis en place des stratégies visant une
croissance régulière et soutenue de ses activités.
Sa détermination, son engagement dans l’attachement du service de personnel qualifié
et de matériel à la pointe de la technologie témoignent de sa politique en vue de
satisfaire les besoins et les attentes de sa clientèle. Pour y parvenir et soutenir ses
ambitions, elle utilise des ressources appropriées.
La société dispose de plusieurs ressources parmi lesquelles nous avons :

• les ressources humaines ;


• les ressources matérielles ;
• les ressources financières.
3. Organisation de la GERBATP sarl
Plusieurs organes assurent le fonctionnement de la GERBATP Sarl Il s’agit :
• de l’Administration Générale (AG)
• du centre de profit GERBATP BTP
• du centre de profit GERBATP logistique.
L’organigramme de la GERBATP Sarl montre l’organisation structurelle ainsi que les
relations ou liens existant entre les différentes directions et services.
Confère annexe VI.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

12
Gestion des fournisseurs de la GERBATP sarl

3.1. L’Administration Générale


Conduite par L’Administrateur Général, elle est la plus haute instance de la société.
Elle a aussi pour rôle d’appuyer et de coordonner l’ensemble des activités techniques
et financières de la société et d’en assurer le contrôle.
L’Administration Générale comporte des services qui lui sont directement rattachés. Il
s’agit :
• du Secrétariat de Direction,
• du Directeur Administratif et Financier,
• du Service Informatique,
• du Service "Reporting",
• du Service des Ressources Humaines.
• du Service Achat

3.1.1. Le service informatique

Placé sous la responsabilité de la Direction Administrative et Financière, le service


informatique est chargé de la mise en œuvre du suivi des programmes existants et ou à
venir, et la gestion du parc informatique. Il a aussi à sa charge :

 Le bon fonctionnement des programmes déjà installés sur les ordinateurs ;


 L’entretien du matériel informatique ;
 L’installation de tout nouveau matériel informatique ;
 La conception, la proposition de programmes adaptés aux besoins des utilisateurs ;
 L’acquisition du nouveau matériel informatique ;
 La formation du personnel en informatique.

3.1.2. Le service achat

Ce service a pour tâche :


 L’élaboration, et le dépôt des dossiers de soumission aux appels d’offre ;
 La demande des factures pro forma chez les différents fournisseurs et l’achat des
matières premières;
 La sélection des fournisseurs les moins disant avec l’accord du gérant sur des
critères bien déterminés;
 L’établissement des bons de commande;
 La réception du matériel;
 La signature des bordereaux de livraison;
 La réception des factures;

Institut Burkinabé des Arts et Métiers GERBATP Sarl

13
Gestion des fournisseurs de la GERBATP sarl

II. PRESENTATION DU PROBLEME

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 :

• Risque de perte d'informations;


• L’oubli de passer une commande à un fournisseur ;
• la lenteur dans l'accès aux données.
Compte tenu de ces différentes difficultés, il s’avère indispensable d’informatiser la
gestion des fournisseurs pour plus d’efficacité.

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 :

 Créer, enregistrer et éditer des demandes d’achat;


 Créer, enregistrer et éditer des bons de commande;
 Créer, enregistrer et examiner des factures d'achats;

En plus des fonctions sus citées au dessus, nous avons des fonctionnalités globales
attendu du système ; notamment :

 La mise en place d’une Base de Données fiable ;


 La sécurité et confidentialité des données ;
 Facilités la gestion et la maintenance par l’enregistrement, la
modification, la recherche, l’impression, le listage et suppression des
données.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

14
Gestion des fournisseurs de la GERBATP sarl

4. Les acteurs du projet

4.1. Groupe de pilotage

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).

4.2. Groupe de projet

Le groupe de projet est chargé d’analyser le projet, de proposer une solution


informatique viable et éventuellement de réaliser le projet. Il travaille en collaboration
avec le groupe de pilotage. Il produit également les documents destinés au groupe de
pilotage. Il s’agit de :

 M. Cheick Mohamed GANAME ;


 M.Yacouba DEN.

4.3. Groupe des utilisateurs

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 :

 M.Seydou KERE (Comptable fournisseur),


 Mme Yé Abzéta(Secrétariat),
 M. Martin KAGAMBEGA (Responsable Service Achat).

III. PRESENTATION DU CONTEXTE

1. Objectifs

Ce projet a pour objectif principal de proposer une solution à un problème concret, et


ceci en partant d’une définition des besoins. Nous espérons à travers celui-ci,
démontrer l’importance de l’application d’une méthodologie de développement, et
aussi permettre par la suite que ce produit puisse être évolutif et facilement
maintenable par des intervenants tiers.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

15
Gestion des fournisseurs de la GERBATP sarl

2. Méthode d’analyse

La programmation d’une application informatique suppose au préalable une analyse


conceptuelle. Cette analyse impose le choix d’un langage de modélisation et d’une
méthode d’analyse. Pour ce faire, nous utiliserons le langage UML (Unified Modeling
Language) pour modéliser, documenter et décrire notre système logiciel. La méthode
UP (Unified Process) pour l’analyse.UML est un langage qui permet de représenter
des modèles, mais il ne définit pas le processus d'élaboration des modèles. Son
indépendance par rapport aux langages de programmation, aux domaines d'application
et aux processus, en fait un langage universel de modélisation objet. D’autre part, les
auteurs d'UML préconisent dans le cadre de la modélisation d'une application
informatique, d'utiliser une démarche itérative et incrémentale, guidée par les besoins
des utilisateurs du système, et centrée sur l'architecture logicielle. D'après les auteurs
d'UML, un processus de développement qui possède ces qualités devrait favoriser la
réussite d'un projet.

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 :

Processus : Suite continue d'opérations constituant la manière de fabriquer. En


d'autres termes, c'est une succession de tâches dans le but d'accomplir un travail, un
projet.
Unifié : Participe passé du verbe unifier, être amené à l'unité, se fondre en un tout. En
fait, les méthodes d'analyse et de conception orientées objet, étaient variées jusqu'à ce
que Rambaugh, Jacobson et Booch eurent l'idée de les unifier.
3.2. Les principes du processus unifié

Le processus unifié s'appuie sur les principes suivants :

 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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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. Les phases du processus unifié(UP)

Le processus unifié se déroule en quatre phases, incubation, élaboration, construction


et transition. Chaque phase répète un nombre de fois une série d'itérations. Et chaque
itération est composée de cinq activités : capture des besoins, analyse, conception,
implémentation et test.

Figure1 : cycle de vie du processus unifié

3.3.1. Inception (Incubation):

C'est la première phase du processus unifié. Il s'agit de délimiter la portée du système,


c'est-à-dire tracer ce qui doit figurer à l'intérieur du système et ce qui doit rester à
l'extérieur, identifier les acteurs, lever les ambiguïtés sur les besoins et les exigences
nécessaires dans cette phase. Il s'agit aussi d'établir une architecture candidate, c'est-à-
dire que pour une première phase, on doit essayer de construire une architecture
capable de fonctionner. Dans cette phase, il faut identifier les risques critiques
susceptibles de faire obstacle au bon déroulement du projet.

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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

Le bon fonctionnement d’un travail de conduite de projet requiert une organisation et


un suivi des délais. Ainsi pour mener à bien notre travail d’analyse et de réalisation nous
avons adopté les prévisions suivantes :

 Du 05 octobre au 19 Octobre 2011(15jours)


Etude préliminaire
Etude de l'environnement de travail
Etude des documents mis à notre disposition.
 Du 20 Octobre au 03 Novembre 2011(15jours)
Capture des besoins et analyse du système à travers les entretiens que nous
aurons à faire avec le personnel de notre domaine d'étude.

 Du 04 Novembre au 18 Novembre 2011(15jours)


Conception du système.

 Du 19 Novembre au 31 Décembre 2011(43jours)


Implémentation du système.

 Du 01 Janvier au 05 Janvier 2011(5jours)


Test du futur système.
Ainsi afin de bien percevoir l’exécution des différentes tâches, nous
Représenterons le planning par un tableau qui prend en compte les jours
non ouvrables.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

18
Gestion des fournisseurs de la GERBATP sarl

Périodes Octobre Novembre Décembre Janvier


Taches 05- 20- 01- 04-18 19-30 01-31 01-05
19 31 03
Etude
préliminaire
Capture des
besoins
fonctionnels
Conception
Implémentation
Test

Tableau de planning prévisionnel

4.2. Planning réel

Périodes Octobre Novembre Décembre Janvier


Taches 10-31 01-20 21-30 01-10 11-31 01-25 25-30
Etude
préliminaire
Capture des
besoins
fonctionnels
Conception
Implémentation
Test
Tableau de planning réel

5. Analyse des écarts entre le planning prévisionnel et le planning réel


Pour ce qui est de notre projet, nous pouvons dire que le planning réel correspond à
environ 80% du planning prévisionnel, ceci s'explique du fait de notre participation à
la gestion du parc informatique au compte de la GERBATP. Ainsi, il était question
pour nous d’assurer la maintenance et le réseau au sein de la GERBATP.

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

19
Gestion des fournisseurs de la GERBATP sarl

CHAPITRE II : ETUDE FONCTIONNELLE

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

1. Capture des besoins fonctionnels


Nous avons effectué plusieurs recherches pour identifier au mieux les besoins de
l’application, et ceci afin de répondre aux attentes des utilisateurs.
Nous sommes allés chercher les informations au sein des différents services. Cette
phase correspond à une recherche sur le terrain pour bien définir le cadre de notre
système.
Nous nous sommes aussi procurés du document de projet du manuel de la procédure
GERBATP sarl, qui explique le mode de fonctionnement de la société en général mais
de la gestion des fournisseurs en particulier, et cela nous a permis d’établir le compte
rendu des interviews:

Etat des besoins ou demande d’achat(DA)

Intervenant : M. Martin KAGAMBEGA


Service : Service Achat
Date : 30/10/11

Les états de besoins/Demande d’Achat(DA) émis par les demandeurs sont


présentés au DG/DAF qui en fonction des nécessités, des possibilités et des
liquidités donne instruction au service achat.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

20
Gestion des fournisseurs de la GERBATP sarl

Etablissement du bon de commande

Intervenant : M. Martin KAGAMBEGA


Service : Service Achat
Date : 02/11/11

Le service achat établit un bon de commande selon la pro format du fournisseur


retenu par DG/DAF après études des différents pro formats (3max).Le dossier
d’achat(DA ou état de besoin) est ensuite présenté au DG/DAF pour contrôle et
validation.
Toute commande fait l’objet d’un BC valorisé et établit en 04 exemplaires.
Chaque commande est suivie par le responsable des achats pour le respect des
dates de livraison prévu.

Livraison

Intervenant : M. Felix KABORE


Service : Service Achat
Date : 02/11/11

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

21
Gestion des fournisseurs de la GERBATP sarl

Règlement des factures

Intervenant : M. Seydou KERE


Service : service comptable
Date : 05/11/11

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.

2. Identification des acteurs


Nous allons maintenant énumérer les acteurs susceptibles d’interagir avec le système,
mais d’abord nous donnons une définition de ce que c’est qu’un acteur.

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é.

Les acteurs du système identifiés sont :

• Fournisseur : le fournisseur propose la facture pro forma et délivre les


matériels.

• Responsable achat : le responsable achat gère les commandes et établit


les bons de commande et suit leur évolution.
• Demandeur : le demandeur établit les demandes d’achat.

• Comptable : le comptable s’occupe de l’état des fournisseurs et du


règlement.

• Administrateur : crée les profils utilisateurs et attribue les droits d’accès.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

22
Gestion des fournisseurs de la GERBATP sarl

3. Identification des messages

On va détailler les différents messages échangés entre le système et l’extérieur.


Définition : Un message est une information envoyée par un émetteur dont le but est
de déclencher une activité chez le récepteur.
Voici la liste de quelques messages échangés entre l'application et ses acteurs :

Messages envoyés acteur système Messages réponses système acteur


M1 : Authentification M2 : Interface d'authentification.
M3 : Consultation de l'état des factures M4 : Interface de consultation adéquate.
M5 : Gérer les bons de commandes. M6 : Interface gérer les bons de
commandes.
M7 : Editer un bon de commande. M8 : Interface éditer un bon de commande.
M9 : Mettre à jour des matériels M10 : Interface de mise à jour adéquate
M11 : Mettre à jour les fournisseurs M12 : Interface de mise à jour adéquate
M13:Situation des commandes. M14 : Interface de mise à jour adéquate

Tableau des messages en interaction

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 :

Institut Burkinabé des Arts et Métiers GERBATP Sarl

23
Gestion des fournisseurs de la GERBATP sarl

Utilisateurs finaux Description des besoins fonctionnels

L’application doit permettre au responsable service de :


• S’authentifier
• Etablir/éditer des BC.
Responsable service • Enregistrer fournisseurs, Pro Forma, Bon de
achat Livraison

L’application doit permettre au comptable de :


• S’authentifier
Comptable • Etablir /éditer des factures
• Suivre l’état des règlements

L’application doit permettre au demandeur de :


Demandeur • S’authentifier
• Etablir/éditer des DA.
• Identifier les matériels
L’application doit permettre à l’administrateur de :
• S’authentifier
Administrateur • Créer les profils utilisateurs
• Donner des droits d’accès

Etat des fournisseurs


Consultation de l’état des
Factures et règlements

COMPTABLE
FOURNISSEUR

SYSTEME

Situation des commandes ADMINISTRATEUR


RESPONSABLE ACHAT
Gérer les profils des
Figure 2 : Diagramme de contexte du futur système utilisateurs

Institut Burkinabé des Arts et Métiers GERBATP Sarl

24
Gestion des fournisseurs de la GERBATP sarl

II. DIAGRAMME DES CAS D’UTILISATION

Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au
système.

1. Identification des cas d'utilisations

Définition : un cas d’utilisation 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.
Un cas d’utilisation modélise un service rendu par le système. Il exprime les
interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur
concerné.
L’identification des cas d’utilisation une première fois, nous donne un aperçu des
fonctionnalités futures que doit implémenter le système.
Cependant, il nous faut plusieurs itérations pour ainsi arriver à constituer des cas
d’utilisation complets.
Pour constituer les cas d’utilisation, il faut considérer l'intention fonctionnelle de
l'acteur par rapport au système dans le cadre de l'émission ou de la réception de chaque
message. En regroupant les intentions fonctionnelles en unités cohérentes, on obtient
les cas d'utilisations.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

25
Gestion des fournisseurs de la GERBATP sarl

Messages émis/reçus par les


Cas d’utilisation Acteur principal, acteurs
acteurs secondaires
Emet :
enregistrer/modifier/supprimer une
commande.
Suivre les commandes Responsable achat Reçoit : liste des commandes.

Responsable achat Emet :


Gérer les fournisseurs enregistrer/modifier/supprimer un
fournisseur.
Reçoit : consulter/lister les
fournisseurs

Traiter les factures Comptable Emet :


enregistrer/modifier/supprimer une
facture.
Reçoit : consulter/lister une facture.
Emet : enregistrer/éditer/modifier un
états des règlements comptable règlement
Reçoit : consulter ou lister les
règlements.
Emet : Création, modification,
Gérer les profils Administrateur suppression de profils.

Remarque : Ce tableau n'est pas définitif, un processus de développement avec UML


est itératif, il se peut qu'il change au fur et à mesure de l'avancement du projet.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

26
Gestion des fournisseurs de la GERBATP sarl

2. Représentation du diagramme des cas d’utilisation

Figure 3 : Diagramme des cas d’utilisation du système

III. LE DIAGRAMME D’ACTIVITE


Ce diagramme donne une vision des enchaînements des activités propres à une
opération ou à un cas d'utilisation. Il permet aussi de représenter les flots de contrôle et
les flots de données.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

27
Gestion des fournisseurs de la GERBATP sarl

1. Représentations du diagramme d’activités

Utilisateur Systeme

Connexion Vérification d'authentification

<Non OK>
Decision_1

<OK>

Affichage de la page d'acceuil

Figure 4: diagramme d’activité du UC Authentification

Utilisateur Systeme

<Authentification réussie>
Affichage page d'accueil

Choix du menu de gestion

Affichage du formulaire

Choix du menu enregistrement

Affichage du formulaie d'enregistrement

Saisie des infos. d'enregistrement

Vérification des champs

Enregistrement Prévisualisation

Decision_2

Confirmation succès Confirmation échec

Figure 5 : diagramme d’activité du UC Enregistrer

Institut Burkinabé des Arts et Métiers GERBATP Sarl

28
Gestion des fournisseurs de la GERBATP sarl

Utilisateur Systeme

<Authentification réussie>
Affichage page d'accueil

Choix de l'élément à consulter

Affichage de la page

Saisie des infos. à consulter

Affichage des infos.

Contacter consulter à nouveau

<OK> <OK>
Decision_2

<NON OK>

Figure 6 : diagramme d’activité du UC Consultation

Institut Burkinabé des Arts et Métiers GERBATP Sarl

29
Gestion des fournisseurs de la GERBATP sarl

Utilisateur Systeme

<Authentification réussie>
Affichage page d'accueil

Choisir menu de gestion liste

Affichage formulaire

Saisir type de liste

Vérifier disponibilité

<NON OK> <OK>


Decision_2

Afficher message d'erreur Etablir liste

Afficher liste

Imprimer

Figure 7: diagramme d’activité du UC Lister

IV. LE DIAGRAMME DE CLASSE

Le diagramme de classes est le point central dans un développement orienté objet. En


analyse, il a pour objectif de décrire la structure des entités manipulées par les
utilisateurs. En conception, le diagramme de classes représente la structure d'un code
orienté.
1. Quelques règles de gestions

 Un bon de commande provient d’un et un seul pro forma.


 Un bon de commande concerne une ou plusieurs facture(s)
 Un bon de commande contient un ou plusieurs produits.
 Une demande d’achat peut contenir un ou plusieurs matériel(s).
 Un fournisseur peut établir une ou plusieurs factures, comme il peut ne pas
l’établir.
 Une facture provient d'un et un seul fournisseur.
 La facture peut ne pas être payée ou être payée par plusieurs règlements

Institut Burkinabé des Arts et Métiers GERBATP Sarl

30
Gestion des fournisseurs de la GERBATP sarl

 Une facture est associée à un et un seul bon de commande.


 Une commande est lancée par un et un seul demandeur.
 Un demandeur peut ne pas lancer ou lancer plusieurs commandes.
 Un fournisseur peut ne pas livrer ou livrer plusieurs bons de livraison.
 Un fournisseur peut ne pas proposer ou proposer plusieurs pro forma.
 Un règlement dépend d’un ou de plusieurs proposition(s).

2. Représentation du diagramme de classe

Bon_Livraison Pro_Forma Materiel Service


- num_bl : int - num_pf : int - num_mat : int
- date_bl : Date - num_srvce : int 1..1
- date_pf : Date - libelle_mat : String
- etat_bl : String - nom_srvce : String
- totalht_pf : float - poids_mat : String
+ enregistrer () : void - tva_pf : int - unite_mat : String + enregistrer () : void
+ lister () : void 0..* - acompte_bic : int - qte_mat : double + lister () : void
+ rechercher () : void - pu_mat : float + supprimer () : void
+ enregistrer () : void ...
+ supprimer () : void + lister () : void - remise_mat : int
... + rechercher () : void + enregistrer () : int
+ modifier () : void + lister () : int Commande
0..*
+ supprimer () : void + supprimer () : int - num_cmde : int
<proposer> ... ... - date_cmde : Date
1..*
- etat_cmde : String <est_situé>
1..*
+ enregistrer () : void
<livrer> <provenir> + lister () : void 0..*
+ rechercher () : void
1..1 <contenir> + supprimer () : void
1..1 + modiffier () : void
Bon_Commande
<Faire Objet> 1..1 ...
Fournisseur 1..1 1..*
- num_bc : int
1..* 1..1
- num_frs : int - date_bc : Date
- nom_frs : String + enregistrer () : void Demande_Achat
<affecter>
- tel_frs : String 1..1 + lister () : void - num_achat : int
<adresser> 1..* <lancer>
- adr_frs : String + rechercher () : void - date_achat : Date 0..*
+ enregistrer () : void + modifier () : void - Motif_achat : String
1..1
+ lister () : void + supprimer () : void + enregistrer () : void
+ rechercher () : void ... + lister () : void Chantier
1..1 1..1
+ supprimer () : void + rechercher () : void - num_chantier : int
... + modiffier () : void - nom_chantier : String
<concerner> + supprimer () : void - lieu_chantier : String
...
1..* + enregistrer () : void
<rattacher> + lister () : void
<etablir>
+ supprimer () : void
Facture ...
- num_fact : int
- date_fact : Date Demandeur
- totalht_fact : float 1..1
0..* Reglement - num_dmdeur : int
- tva_fact : int
1..1 - nom_dmdeur : String
- bic_fact : int - num_rglmt : int 1..1
Proposition - prenom_dmdeur : String
- remise_fact : int - date_rglmt : Date
- num_pro : int <payer> - tel_dmdeur : String 0..*
- mode_rglmt : String
- date_pro : Date + enregistrer () : void
- montant_rglmt : float + enregistrer () : void
- montant_pro : float + lister () : void
- retenu_rglmt : float + lister () : void
+ rechercher () : void
+ enregistrer () : void + enregistrer () : void + supprimer () : void
+ modifier () : void
+ lister () : void ...
+ supprimer () : void + lister () : void
+ rechercher () : void 0..*
... + rechercher () : void
+ modiffier () : void + modifier () : void
+ supprimer () : void + supprimer () : void
... 0..* 1..1
<dependre> ...

Figure 8:Diagramme de classes

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 :

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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

Figure 9:Découpage en catégories

VI.DIAGRAMME DE PACKAGE D’ANALYSE

Ce diagramme va représenter les différentes dépendances entre les packages


d’analyse :

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

Figure 10 : Diagramme de packages d’analyse

Remarque : ce diagramme a été obtenu après plusieurs itérations.


Remarque : cette phase peut être utilisée par un chef de projet pour constituer les
équipes. Chaque équipe pourra se concentrer sur le développement d’une seule
catégorie/package.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

33
Gestion des fournisseurs de la GERBATP sarl

CHAPITRE III : ETUDE TECHNIQUE

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

34
Gestion des fournisseurs de la GERBATP sarl

1.1. Représentation du diagramme de séquence


DiagrammeSequence_1

Système

Acteur

Lancement du systeme

Affichage Ecran de Connexion

Saisie du login et du Mot de Passe

Verification
opt [Si corrects]
Affichage du Menu de l'utilisateur

Figure 11: Diagramme de séquence de l'authentification

DiagrammeSequence_2

système

Service achat
Authentification

Affiche formulaire

Recherche des commandes

Affiche resultat

Saisie des références du frs Si commande


disponible
Enregistrement
Affiche resultat

Figure 12: Diagramme de séquence de traitement des commandes

Institut Burkinabé des Arts et Métiers GERBATP Sarl

35
Gestion des fournisseurs de la GERBATP sarl

DiagrammeSequence 3

système2

Comptable
Authentification

Affiche menu facturation

Saisie les informations

Affiche resultat Vérifie et enregistrer infos

Editer facture

facture

Figure 13: Diagramme de séquence de gestion des factures

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

36
Gestion des fournisseurs de la GERBATP sarl

Couche de
présentation

Couche Métier
Interface utilisateur

Module Expression Module Etat Module Module Facture


besoins des bons Commande

Base de
Données

Figure 14 : diagramme de composants du Système

3. L’application « Gestionfrs »(Gestion des Fournisseurs)


L’application est découpée en 3 couches distinctes, Présentation, Métier et
DAO.
• La couche « Présentation » est chargée de tout ce qui est affichage.
• La couche « Métier » est la logique métier de l’application, elle est le
cœur et c’est elle qui définit toutes les règles régissantes au
fonctionnement de l’application.
• La couche « DAO » est l’intermédiaire entre les autres couches et la Base
de données.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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 :

Figure 15 : code source classe demande achat

Figure 16 :code source classe demandeur

Institut Burkinabé des Arts et Métiers GERBATP Sarl

38
Gestion des fournisseurs de la GERBATP sarl

La couche Présentation :
Voici quelques figures représentants l’interface du logiciel :

Figure 17 : fenêtre principale

Figure 18 : fenêtre d’authentification

Institut Burkinabé des Arts et Métiers GERBATP Sarl

39
Gestion des fournisseurs de la GERBATP sarl

Figure 19 : fenêtre de demande d’achat

Figure 20:fenêtre de bon de commande

Institut Burkinabé des Arts et Métiers 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 :

Figure 21: architecture client/serveur

 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 .

Institut Burkinabé des Arts et Métiers GERBATP Sarl

41
Gestion des fournisseurs de la GERBATP sarl

Les paramètres A et b dépendent de la classe d’application et des caractéristiques


propres à l’entreprise.
On distingue trois classes :
1ère classe ou projets de mode organique: ces projets sont réalisés par une équipe de
taille réduite avec une connaissance parfaite de l’environnement et du domaine
d’application.
2ème classe ou projets de mode semi-détaché: ce mode représente un intermédiaire
entre le mode organique et le mode embarqué décrit ci-dessous. Pour des projets de
mode semi-détaché,l'équipe de projet est composé de personnes expérimentées et non
expérimentées.Les membres de l’équipe ont une connaissance moyenne de
l’environnement de développement et du domaine.
3ème classe ou projets de mode embarqué: l’équipe n’a pas de connaissance sur
l’environnement de développement et du domaine d’application. Le système à
développer est une partie d'un système complexe et fortement connecté de matériels et
de logiciels, de normes et de procédures opérationnelles. Du fait de la nature même de
ces projets, il est inhabituel de disposer d'ingénieurs logiciels expérimentés dans le
domaine d'application.
Les formules permettant de calculer le coût, ou plus exactement l'effort requis pour
le développement du logiciel sont les suivantes:
1ère classe: HM = 2.4 (KLSL) 1.05
2ème classe: HM = 3 (KLSL) 1.12
3ème classe: HM = 3.6 (KLSL) 1.20
Où HM est l’effort ou le nombre d'homme-mois nécessaire à la réalisation du projet,
KLSL est le nombre de Kilo-Lignes-Sources Livrées.
Le modèle COCOMO simple permet également d'estimer la durée du projet de
développement (TDEV). Les équations pour les différentes classes sont les suivantes:
1ère classe TDEV = 2.5 (HM) 0.38
2ème classe TDEV = 2.5 (HM) 0.35
3ème classe TDEV = 2.5 (HM) 0.32
Le nombre de personnes requises pour réaliser le projet dans cet intervalle de temps
est:N = HM/TDEV.
Le coût total de réalisation dans notre cas sera estimé à HM*ValeurHM où
ValeurHM représentant le salaire moyen d’un informaticien au Burkina Faso. Nous
estimons ce salaire à 200.000 FCFA.
Si nous estimons le nombre de lignes de notre application à 15 000, alors les différents
calculs nous conduisent au tableau suivant :

Intitulé Mode de calcul Résultat


KLSL (en kilo-ligne) 15 000 / 1000
HM (en homme/mois) 3 (15000/1 000) 1.12 62.28
TDEV (en mois) 2.5 (62.28) 0.35 10.62
N (en personne) 62.28/10.62 5.866
Coût de développement (en 62.28*200 0000 12 456 000
FCFA)
Tableau d’évaluation du coût de développement

Institut Burkinabé des Arts et Métiers 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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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

Un Environnement de Développement Intégré est un ensemble d'outils, qui vient


aider les programmeurs. Notre choix s’est porté sur l’environnement NetBeans. En
effet Netbeans est spécialisé dans le domaine Java. En plus de Java, NetBeans
permet également de supporter différents autres langages et comprend
toutes les caractéristiques d'un IDE moderne (éditeur en couleur, projets
multi-langage, refactoring, éditeur graphique d'interfaces et de pages web).
2.2. MySQL
MySQL est un système de gestion de base de données (SGBD). Selon le type
d'application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion
de base de données les plus utilisés au monde, autant par le grand public (applications

Institut Burkinabé des Arts et Métiers GERBATP Sarl

44
Gestion des fournisseurs de la GERBATP sarl

web principalement) que par des professionnels, en concurrence avec Oracle et


Microsoft SQL Server.
MySQL est un serveur de bases de données relationnelles SQL développé dans un
souci de performances élevées en lecture, ce qui signifie qu'il est davantage orienté
vers le service de données déjà en place que vers celui de mises à jour fréquentes et
fortement sécurisées. Il est multi-thread et multi-utilisateur.
3. Implémentation de la base de données

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 :

Figure 22: Base de données du système

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

45
Gestion des fournisseurs de la GERBATP sarl

1. Quelques test de cas d’utilisations

1.1. Test du cas d’utilisation «authentification»

Chaque utilisateur possède son propre "login" et mot de passe "password".


Pour tester ce cas d'utilisation, nous avons rempli les champs spécifiques pour le login
et le mot de passe avec un nom d'utilisateur existant déjà dans la base de données et
après la validation, la session est ouverte.
Par la suite, nous avons tenté d'accéder à la même session mais avec un mot de passe
différent, l'accès à la session est rejeté (idem pour un login inexistant dans la base de
données). Donc le test a réussi.
1.2. Test du cas d’utilisation «établir une demande d’achat»

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»

Sur la même demande d’achat nous avons essayé de l'imprimer. En validant


l'impression, l'opération est lancée.
1.4. Test du cas d’utilisation « supprimer demande d’achat »
Nous avons testé ce cas d'utilisation pour la demande d’achat ayant le numéro 1, qui a
été établi et enregistré dans la base de données.
Apres avoir vérifié la base de données, nous avons remarqué l'inexistence de la
demande, donc le test est réussi.
1.5. Test du cas d’utilisation « Modifier 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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

46
Gestion des fournisseurs de la GERBATP sarl

III. PROCEDURE DE SECOURS ET SECURITE

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.

 Panne d’un poste de travail :

Lorsqu’un poste de travail tombe en panne l’utilisateur devra recourir au travail


manuel pendant la durée de la panne.

 Indisponibilité générale du système :

Une panne du serveur d'application est synonyme d'indisponibilité totale ou partielle


du système. Dans ce cas, le fonctionnement manuel jusqu'à la résolution du problème
est préconisé.
2. Politique de sécurité
La sécurité est une stratégie préventive qui n’est jamais acquise définitivement. Elle
vise à minimiser les risques de panne, d’éviter que la base de données soit dans un état
d’incohérence, d’éviter les accès non autorisés à la base et d’éviter la présence de
programmes indésirables dans le réseau.
 Protection contre les catastrophes :

Le local technique doit être un lieu sécurisé et équipé d’extincteurs et de


Parafoudres. Cela permettra d’éviter les principales catastrophes comme l’inondation
et la foudre susceptibles d’endommager le système.

 Protection contre les incidents d’exploitation :

Si l’incident est lié à l’application, faire recours aux programmeurs.

 Protection contre les virus informatiques :

Pour la protection contre ses infections virales, nous proposons, l’interdiction de


l’utilisation de tout support (disquettes, CD ROM ou cartouches, etc.) provenant de
l’extérieur ou d’origines douteuses, l’installation d’un antivirus à jour et performant
sur tous les postes de travail du réseau et sur le serveur. Cet antivirus devrait permettre

Institut Burkinabé des Arts et Métiers GERBATP Sarl

47
Gestion des fournisseurs de la GERBATP sarl

la désinfection rapide de la machine infectée et sensibiliser les utilisateurs sur la notion


de la sécurité informatique.

 Politique de sauvegarde

La politique de sauvegarde à pour but de préserver l’intégrité des données en cas de


disfonctionnement du système. Une sauvegarde externe sera utilisée de façon
mensuelle.
Les différentes sauvegardes doivent être conservées dans un coffre ininflammable.

 Protection logicielle contre les accès malveillants :

La définition d’un profil utilisateur à travers l’utilisation de mot de passe et de nom


d’utilisateur permettra d’assurer la confidentialité des données. Pour plus de sécurité,
les mots de passe pourront être régulièrement modifiés. Un utilisateur n’aura accès
qu’aux données auxquelles il a droit et n’effectuera des traitements que lorsqu’il à
l’autorisation.

 Protection physique contre les accès malveillants :

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

49
Gestion des fournisseurs de la GERBATP sarl

ANNEXES :

I .LE LANGAGE UML

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.

 Le diagramme de cas d’utilisation

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

Le diagramme de classes est le point central dans un développement orienté objet. En


analyse, il a pour objectif de décrire la structure des entités manipulées par les
utilisateurs. En conception, le diagramme de classes représente la structure d'un code
orienté. En pratique, l’intérêt majeur du diagramme de classe est de modéliser les
entités du système d’information ;

Institut Burkinabé des Arts et Métiers GERBATP Sarl

50
Gestion des fournisseurs de la GERBATP sarl

 Le diagramme de séquence

Ce diagramme permet de décrire les scénarios de chaque cas d'utilisation en mettant


l'accent sur la chronologie des opérations en interaction avec les objets.

 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.

Annexe Figure 23: Evolution des versions d'UML

Institut Burkinabé des Arts et Métiers GERBATP Sarl

51
Gestion des fournisseurs de la GERBATP sarl

II. LE DIAGRAMME DE CAS D’UTILISATION

• 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

Un cas d’utilisation "Représente un ensemble de séquences d’actions qui sont réalisées


par le système et qui produisent un résultat observable intéressant pour un acteur
particulier" (UML de Pascal Roques, paru en 11/2005).

CU Un cas d’utilisation

Relation entre les cas d’utilisation

• Relation d’inclusion (include)

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

Institut Burkinabé des Arts et Métiers GERBATP Sarl

52
Gestion des fournisseurs de la GERBATP sarl

• Relation d’extension (extend)

La relation d’extension d’un « cas d’utilisation B » à un « cas d’utilisation C »


indique qu’une instance du « cas d’utilisation C » peut être augmentée par le
comportement du « cas d’utilisation B ».

«Extend»
CUC CUB

Formalisme du diagramme des cas d’utilisation

Domaine d’étude

<< Actor>>
Cas d’utilisation A

<<Include>>

Cas d’utilisation B

<<Extend>>

Acteur interne
Cas d’utilisation C

III. LE DIAGRAMME DE CLASSE

Définition d’une classe

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.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

53
Gestion des fournisseurs de la GERBATP sarl

Représentation d’une classe

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.

Multiplicité des associations :

P1..P2 Q1..Q2

Classe A Classe B

Pour une instance de Classe A, il y a au minimum Q1 instance(s) de Classe B


et au maximum Q2. De la même façon, pour une instance de Classe B, il y a au
minimum P1 instances de Classe A et au maximum P2.
Les associations : Une association représente une relation structurelle entre classes
d’objets. On représente une association en traçant une ligne entre les classes
associées.
Agrégation : Une association particulière non symétrique. Il s'agit d'une relation entre
deux classes, spécifiant que les objets d'une classe (classe agrégat) sont des
composants de l'autre classe (classe agrégée).

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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.

Classe Classe Agrégée


min..max
1
Généralisation : UML emploie le terme de généralisation pour désigner la relation de
classification entre un élément plus général et un élément plus spécifique. La relation de
généralisation signifie « est un » ou « est une sorte de ».
La classe générique porte les attributs communs à toutes les classes spécifiques.
Mais une classe spécifique ne porte que les attributs spécifiques à son type de classe.

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

Institut Burkinabé des Arts et Métiers GERBATP Sarl

55
Gestion des fournisseurs de la GERBATP sarl

Formalisme utilisé

Classe générique Nom association 1


Attributs communs : String Classe agrégat
min1..max1 min2..max2
Méthodes communes ()

Classe

Classe spécialisée Nom association


Classe agrégée
Attributs spécifiques : real min3..max3 min4..max4
Méthodes spécifiques ()

Classe association

Attributs : integer

Annexe, Figure 24: Formalisme du diagramme de classe

IV. LE DIAGRAMME D’ACTIVITE

Principaux éléments de notation

Activité Transition Marqueur Marqueur Barre de Point de


d’état initial d’état final synchronisation décision

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).

Institut Burkinabé des Arts et Métiers GERBATP Sarl

56
Gestion des fournisseurs de la GERBATP sarl

Synchronisation : Il est possible de synchroniser les transitions à l'aide des "barres de


synchronisation" (comme dans les diagrammes d'état transitions). Une barre de
synchronisation permet d'ouvrir et de fermer des branches parallèles au sein d'un flot
d'exécution transitions qui s'y rattachent.
Activité : Une activité définit un comportement décrit par une séquence organisé
d’unités dont les éléments simples sont les actions.
Deux pseudo-d’états :

• État initial: la création de l’instance (indispensable) ;


• État final: destruction de l’instance (optionnel).
Formalisme de description du diagramme d’activité

Etat initial

Activité 1 Point de décision


Synchronisation

[Non ok] [Ok]


Activité 2
Activité 3

Activité 4 Activité 5

Etat final

Formalisme du diagramme de cas d’utilisation

V. LE DIAGRAMME DE SEQUENCE

• Les diagrammes de séquences permettent de représenter des collaborations


entre objets selon un point de vue temporel, on y met l'accent sur la
chronologie des envois de messages.

Institut Burkinabé des Arts et Métiers GERBATP Sarl

57
Gestion des fournisseurs de la GERBATP sarl

• Contrairement au diagramme de collaboration, on n'y décrit pas le contexte


ou l'état des objets, la représentation se concentre sur l'expression des
interactions.

• Les diagrammes de séquences peuvent servir à illustrer un cas d'utilisation.

• 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.

• Les diagrammes de séquences et les diagrammes d'état-transitions sont les


vues dynamiques les plus importantes d'UML.

VI. ORGANIGRAMME de la GERBATP

Institut Burkinabé des Arts et Métiers GERBATP Sarl

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.

«En essayant continuellement, on finit par réussir, donc : plus on rate,


plus on a de chance que ça marche.»

Institut Burkinabé des Arts et Métiers GERBATP Sarl

59

Vous aimerez peut-être aussi