Développement d'une application de suivi de distribution des produits pétroliers. Cas du service de distribution de la SEP-Congo

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 1

0.1. Etat de la question

Avec l'invention de l'ordinateur, le monde actuel connaît une avancée technologique considérable dans tous les secteurs d'activité. Actuellement les informations sont traités de façon automatique et rationnelle alors qu'avant l'invention de l'ordinateur l'enregistrement des informations se faisant manuellement sur des supports en papier ce qui engendrait beaucoup de problèmes tel que la perte du temps dans la recherche de ces informations, la dégradation de ces dernières, ou la perte de ces documents.

Jusqu'à présent l'ordinateur reste le moyen le plus sûr pour le traitement et la sauvegarde de l'information permettant d'informatiser les systèmes des données dans les entreprises.

Le domaine de la distribution des produits ou marchandises fait aussi partie intégrante des secteurs dans lesquels l'information apporte une contribution importante dans leur développement. Pour le moment, dans quelques firmes, les opérations sont faites manuellement d'où la difficulté de retrouver tel ou tel document ce qui engendre la lenteur dans le traitement des dossiers. En effet, le nombre croissant des activités et la gestion des produits surtout pétroliers nécessite la mise en place d'un système de gestion automatisée et rationnelle d'où l'objectif de notre projet de mémoire intitulé « Développement d'une application de suivi de distribution des produits pétroliers, cas du service de distribution de la SEP-CONGO ».

0.2. Problématique

Pour détecter les problèmes existant, nous avons interrogé les employés du SEP-CONGO et ils nous ont cité quelques problèmes. Mais pour localiser la source de ces problèmes, nous avons fait une descente sur terrain et après une observation directe, nous avons pu recenser les problèmes suivants :

- Volume important des activités de SEP-CONGO où la plupart des

données sont remplies manuellement ce qui engendre une perte de

temps dans la recherche et parfois même la perte de celles-ci. - Possibilité d'erreur dans le remplissage les documents ;

- Nombre important des clients qui engendre la difficulté de le servir dans le temps strictement prévu ;

- Possibilité d'erreur dans la production des statistiques ;

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 2

- Détérioration des archives à force de leur utilisation trop fréquente ; - Difficultés d'avoir une vision sur le nombre de clients ainsi que les quantités des produits distribués.

Nous avons besoins pour le cas de SEP-CONGO d'un système d'information informatique qui évolue dans les spécifications des utilisateurs.

En effet, un système de gestion informatisé qui permet d'automatiser des tâches réalisées, dans l'entreprise, manuellement ou sur un simple fichier Excel ou Word de Microsoft. L'ancien processus non automatisé comporte de nombreuses étapes, et bien souvent, les données sont enregistrées en retard.

0.3. Hypothèse du travail

Pour la réalisation de notre travail, nous nous sommes fixés comme hypothèses : l'application de gestion et de suivi de distribution de produits pétroliers permettant :

- de réduire le temps de traitement de données concernant les clients ;

- d'avoir une vision globale sur les quantités des produits pétroliers distribués ;

- d'avoir les données statistiques fiables sur les ventes des produits pétroliers et sur la distribution de ces derniers.

0.4. Intérêt du sujet

- Intérêt personnel : ce travail de recherche va nous permettre de nous familiariser à des recherches approfondies, ainsi nous imprégner dans le monde d'analyse, de conception et de développement des programmes.

- Intérêt pour l'université : le choix de ce sujet est de vouloir remplir les exigences académiques qui exigent à tout étudiant finaliste de faire un mémoire. Le document produit servira de référence aux autres chercheurs qui pourront orienter leurs travaux dans le même angle que nous ou à toute personne qui pourrait s'en servir comme source de documentation.

- Intérêt pour l'entreprise : une fois implanté, ce logiciel permettra d(e) :

o Eviter la perte du temps dans la recherche des fiches ;

o Avoir une idée sur la quantité des produits distribués à n'importe quelle période (par an, par mois, par jour) ;

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 3

o Savoir spécifiquement le nombre de clients servis (personnes morales, physiques) ;

o Produire des rapports journaliers, mensuels et/ou annuels plus complets et plus exacts.

0.5. Délimitation du sujet

Pour remédier aux différents problèmes énumérés ci-haut, nous suggérons une solution informatique. Notre travail se propose de développer une application de suivi de distribution de produits pétroliers.

Nos recherches se limitent dans le cadre spatial du service de distribution de SEP-CONGO et s'inscrit dans un espace temporel couvrant les années 2010-2011.

0.6. Méthodologie et techniques

Toute recherche scientifique nécessite au préalable l'utilisation des méthodes et techniques pour acquérir des informations nécessaires pouvant faciliter son développement.

0.6.1 Méthodes

- Méthodes historique : elle nous a permis de savoir l'origine de l'entreprise sous étude (SEP-CONGO), sa localisation, son but et ses objectifs;

- Méthode d'analytique : elle nous a permis de procéder à l'analyse des spécificités de SEP-CONGO ;

- Méthodes structuro-fonctionnelle : elle nous a permis de comprendre la structure et les fonctions au sein de SEP-CONGO, la manière dont les analystes opère pour arriver au résultat final ;

- Méthodes descriptives : elle nous a permis de mener les enquêtes sur le terrain afin de récolter les informations franches, nécessaires, concernant notre application ;

- Méthode clinique : elle nous a permis d'apporter des critiques et suggestions en vue de trouver une solution aux problèmes de SEP-CONGO ;

- La méthode UML : elle est une méthode de modélisation de système d'information qui nous a permis de mettre en place le système informatique ;

- La méthode perte : elle nous a permis d'évaluer le projet.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 4

0.6.2. Techniques

- Technique documentaire : elle permet de consulter un certain nombre d'ouvrage, syllabus, notes, travail de fin de cycle et mémoire relatif à notre projet;

- Technique d'interview : elle nous a aidé à faire une bonne récolte de données par des questions orales posées à des personnes mieux placées de l'entreprise ;

- Technique d'observation : elle nous a permis d'observer et de dégager les éléments nécessaires ayant trait à notre sujet de travail (¹).

0.7. Canevas du travail

Hormis l'introduction et la conclusion, ce travail comprend quatre chapitres. Le premier s'intitule notions préliminaires, passe en revue quelques concepts sur le système d'information, le système informatique et les bases des données ainsi que sur la méthode UML.

Le deuxième chapitre porte sur le planning prévisionnel. Il montre de quelle manière le projet compte se réaliser sur le plan matériel, temporel et financier.

Le troisième chapitre est axé sur la présentation du SEP-CONGO. Il fait le tour du fonctionnement, de la localisation, de son histoire et le statut juridique de l'entreprise sous étude.

Le quatrième chapitre est centré sur l'analyse de l'existant. Il fait l'analyse de l'entité de l'entreprise à informatiser.

Le cinquième chapitre est centré sur la modélisation de l'application. Ce chapitre se focalise sur la présentation des diagrammes à utilisés dans cette application.

Le sixième et dernier chapitre est essentiellement centré sur la réalisation du projet.

(¹) PITO et GRAWITZ, Méthode des sciences, Dollez, Paris 1971

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 5

I.1. SYSTEME

Il existe plusieurs définitions du mot système (²):

- Joël de ROSNAY définit le système comme étant un ensemble d'éléments en interaction, structuré, poursuivant un but commun.

- J.L. LEMOINE, quant à lui souligne que le système c'est quelque chose (n'importe quoi identifiable) qui fait quelque chose pour quelque chose et évolue dans le temps.

- M'VIBIDULU, définit le système comme un ensemble d'éléments en interaction, structuré, dynamique, poursuivant un but selon les objectifs prédéfinis.

I.2. SYSTEMES D'INFORMATION

A l'ère de l'information et des technologies de communication, consciemment ou inconsciemment, chacun de nous, est en contact quasi-permanent avec un ou plusieurs systèmes d'information. Les appréciations et les points de vue peuvent varier, mais l'impact des systèmes d'information sur la société, l'économie et la vie quotidienne de chacun de nous est incontestablement perceptible.

La définition usuelle d'un système d'information (SI) ressemblait à ceci : ? Le système d'information est l'ensemble des informations formalisables circulant dans l'entreprise et caractérisées par des liens de dépendance, ainsi que des procédures et des moyens nécessaires pour les définir, les rechercher, les formaliser, les conserver, les distribuer ".

Mais cette définition n'indique ni à quoi sert le SI, ni comment il est construit : elle ignore sa dynamique. Pour décrire celle-ci, il faut distinguer deux faces du SI: l'une orientée vers les moyens (système informatique), l'autre vers les besoins et usages (fonctions d'un SI), auxquels la réflexion sur le système d'information donne désormais une place croissante.

Historiquement, les SI ont débuté avec les outils de gestion. Il était alors question de ?robotiser, à l'aide de l'informatique, des tâches

(²) M'VIBIDULU, Cours d'informatique de gestion, inédit, ISP-BUKAVU, 2006-2007

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 6

difficiles et répétitives liées au traitement des données, afin de gagner en rapidité et fiabilité".

Cette informatisation a offert de nouvelles possibilités, et a induit une nécessaire réorganisation des tâches humaines ainsi qu'une organisation du processus informationnel. L'informatisation d'une activité humaine devenait donc plus qu'une simple robotisation ou automatisation d'une tâche ; elle faisait appel à une prise en compte globale de l'information, des traitements, de l'organisation et des aspects humains d'activité.

Afin de prendre en compte cette globalité, la notion de système d'information (SI) est apparue. Elle peut cependant fortement varier suivant les disciplines (informatique, organisation, management, etc.) qui la travaillent.

Un SI est une construction formée d'informations, de traitements, de règles d'organisation et de ressources humaines et techniques. Les ensembles d'informations sont des représentations partielles de faits qui intéressent l'institution, l'organisation ou l'entreprise. Les traitements constituent des procèdes d'acquisitions, de mémorisation, de transformation, de recherche, de présentation et de communication d'informations. Les règles d'organisation régissent l'exécution de traitements informationnels. Les ressources humaines et techniques sont ce qui est requis pour le fonctionnement du SI.

Les SI sont formés a partir de représentations partielles de la réalité (informations, traitements, règles) qui sont mises en oeuvre dans un espace informatique réalisé grâce a des ressources techniques (ordinateur, réseaux, etc.). Leur fonctionnement n'est cependant possible que grâce à des acteurs humains qui sont en interaction avec le SI.

I.2.1. Définition

Vu le rôle primordial que joue l'information dans cette nouvelle ère ( ère de l'information toute organisation quelle qu'elle soit, doit consacrer une partie de son effort et de son activité à récolter, traiter, stocker et diffuser l'information issue de son propre fonctionnement dans le cadre de ce qu'on appelle système d'information. C'est la tâche principale

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 7

du système d'information, qu'on va tenter de définir dans les pages qui suivent (³).

Pour introduire d'une manière un peu formelle le concept de système d'information, on va recourir à ce qu'on appelle la vision systémique d'une entreprise.

On distingue d'abord le système opérant où les produits finaux sont fabriqués à partir d'une certaine matière première. On réduit l'organisation à une sorte d'usine, qui travaille sur la matière première pour fournir un produit final.

Toute organisation est pilotée par une direction, une équipe dirigeante. Ce système de pilotage a pour mission de conduire l'organisation vers des objectifs qui lui sont fixés, et de vérifier que ces objectifs ont bien été atteints. Ce qui nécessite souvent un contrôle continu du fonctionnement du système opérant et d'éventuelles modifications (recrutement, investissement, nouveaux développements...) à apporter au système opérant.

Parallèlement donc au flux physique, il y a un flux de décision. Ce flux correspond aux décisions prises par la direction de l'organisation pour que celle-ci fonctionne dans les meilleures conditions et puisse atteindre ses objectifs. Et toute organisation est soumise à des contraintes extérieures et intérieures qui contraignent son action et l'empêche d'évoluer librement.

(³) M'VIBIDULU, Cours de questions approfondies d'informatique de gestion, inédit, L1 ISP/GOMBE, 2009- 2010

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 8

Et c'est dans ce contexte qu'apparaît le système d'information. Ce sous-système de l'organisation s'occupe de récolter l'information, de la stocker, de la traiter et de la diffuser dans le système opérant et dans le système de pilotage. Dans le système opérant, cette information va permettre à celui-ci de fonctionner. Car chaque individu et chaque tâche ont besoin d'être informés sur le flux physique qui la traverse.

En général, cette information est très détaillée, ne concerne qu'un petit élément de l'organisation, et elle est tournée vers le présent.

Dans le système de pilotage, l'information va permettre à celui-ci de prendre les bonnes décisions en étant constamment informé de ce qui se passe dans le système opérationnel.

Cette information a tendance à être très synthétique, elle concerne une grande partie de l'organisation (si ce n'est toute l'organisation, tel que le Chiffre d'Affaire annuel), et elle est tournée vers le passé et/ou le futur.

La tâche principal du SI est donc de fournir un flux d'information qui d'une part, reflète le plus fidèlement possible le flux physique, et d'autre part fournit au système opérationnel les éléments nécessaires pour son fonctionnement quotidien et au système de pilotage les éléments nécessaires à une prise correcte de décision.

Ainsi, le flux d'information est une image du flux physique. Il représente sous une forme plus ou moins réduite, tous les événements

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 9

survenus dans le système opérant ainsi que tous les éléments d'information qui permettent de traiter ces événements.

Cette image est forcément une réduction de la réalité, elle ne concerne que les aspects pertinents ayant une incidence et/ou un rôle dans le fonctionnement de l'organisation.

Plus précisément, on dit que dans le SI il y a des modèles de la réalité organisationnelle. Ces modèles ont été construits par ceux qui mettent en place le SI, on parle de la conception d'un SI.

La validité et la pertinence de ces modèles sont indispensables au fonctionnement du SI lui même, et elles garantissent la qualité de l'information fournie.

Lorsqu'on parle de la notion de système d'information une distinction doit être faite entre une information et une donnée.

- Information : Faits, connaissances, concepts qui ont un sens pour un être humain. Les informations sont déduites des données.

- Données : Ce sont des éléments manipulés par les technologies informatiques. Les données déduisent les informations.

- Système d'information : Ensemble de composants humains, techniques et organisationnels qui permet d'acquérir, mémoriser, traiter et communiquer l'information nécessaire au fonctionnement d'une organisation (⁴).

I.2.2. Composantes d'un SI (5)

- Les informations : Toutes les informations, quelle que soit leur forme, font partie du SI. Cependant, dans le domaine de la gestion, seules les informations formalisées (d'origine naturelle ou technique) sont véritablement opérationnelles. C'est à celles-là que l'on s'intéresse par la suite.

- Les moyens humains : Les moyens humains sont composés de l'ensemble des personnes qui reçoivent, manipulent et émettent de l'information. Exemple Toutes les personnes d'une entreprise : les utilisateurs, les décideurs, etc.

(4) GABAY J., MERISE et UML pour la modélisation des systèmes d'information, Paris, 2002, p.28.

(5) JOLIVET F. et REBOUL G., Informatique appliquée à la gestion, Tome 1, 2ème édition, Paris, 1996, p. 26.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 10

- Les moyens matériels : Les moyens matériels sont constitués de l'ensemble des machines, de degré de technicité plus ou moins poussé, permettant de recevoir, manipuler et émettre de l'information. (Exemple Machines à écrire, machines à calculer, photocopieurs, télécopieurs, ordinateurs, etc.). Les moyens matériels s'entendent avec leurs supports. Exemple : Supports papier, microfiches, supports magnétiques, supports optiques...

- Les méthodes : Les méthodes sont l'ensemble des outils de travail et des règles permettant de résoudre les problèmes de gestion.

On peut citer notamment :

- les modèles (mathématiques, de recherche opérationnelle, comptables, économiques, etc.),

- les algorithmes, les plans, les normes,

- les fiches d'instructions, les modes opératoires, les procédures administratives, les règlements, les logiciels d'ordinateurs, etc.

Exemples :

- Algorithmes de calcul de primes en fonction du chiffre d'affaires réalisé ;

- modèles mathématiques utilisés dans la fonction de simulation d'un tableur ;

- procédure administrative d'inscription des étudiants à l'université ;

- programme informatique assurant la conversion des dollars en francs burundais,...

I.2.3. Finalités du SI (6)

a)Le SI aide à la prise de décision

Le SI met à la disposition des décideurs les informations nécessaires à la prise de décision, permet d'étudier les conséquences prévisibles des décisions et permet d'automatiser certaines décisions. Pour atteindre cet objectif, le SI fournit aux décideurs des informations portant sur le futur. Exemple : Les prévisions de ventes et de CA pour les six mois à venir permettent d'apprécier les résultats attendus des décisions commerciales prises.

(⁶) MORLEY C., HUGUES J., et LEBLANC B., UML 2: Pour l'analyse d'un système d'information, 3ème

éd. Dunod, Paris, 2006.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 11

b) Le SI permet de contrôler l'évolution de l'organisation

Le SI permet de détecter les dysfonctionnements internes et les situations anormales. Pour atteindre cet objectif, le SI doit être la « mémoire collective » de l'organisation en gardant une trace des informations portant sur le passé. Exemple : Les documents produits par la comptabilité générale (bilan, compte de résultat, etc.) décrivent la situation de l'entreprise par rapport à son activité passée.

C) Le SI permet de coordonner l'activité des différentes composantes de l'entreprise

Pour atteindre cet objectif, le SI fournit des informations portant sur le présent. Exemple : Lors du traitement d'une commande, le SI permet de coordonner l'activité du service comptable, du service commercial, du service livraison, etc. par le biais des flux d'information internes (commande reçue, commande enregistrée, commande livrée, etc.).

I.2.4. Fonctions du système d'information

Un système d'information doit remplir les fonctions suivantes (⁷): le recueil de l'information, la mémorisation de l'information, l'exploitation de l'information et la diffusion de l'information.

a)Recueillir l'information

Le SI dispose de deux principales sources d'alimentation en informations : les sources externes et les sources internes. Face à ces sources d'information, le SI remplit des tâches d'écoute, d'analyse et de saisie.

1°Les sources externes

Les sources externes sont constituées de toutes les composantes de l'environnement générant de l'information. Ces sources peuvent être internationales, nationales, régionales ou locales. Il peut s'agir de partenaires, de concurrents, d'organismes publics et/ou privés, etc.

Aujourd'hui, l'environnement fournit une masse considérable d'informations que le SI ne peut s'approprier sans moyens humains, techniques et organisationnels adéquats : moyens téléinformatiques pour

(⁷) LEVI-MAZLOUM D, Gestion des absences d'une entreprise, Fribourg : Département d'Informatique de l'Université de Fribourg, 2009.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 12

accéder aux informations stockées dans des banques de données, moyens logiciels pour pratiquer la veille informationnelle, etc.

2°Les sources internes

Les sources internes sont toutes les composantes de l'entreprise générant de l'information. Le travail du SI consiste à capter tous les flux d'information internes circulant dans l'entreprise. Exemple : Documents comptables, documents commerciaux, archives statistiques, etc.

Si l'information formalisée est facilement recueillie, l'information informelle est beaucoup plus difficile à capturer mais qui est aussi importante. Pour limiter le risque de perte de ce type d'information, l'organisation peut mettre en place des moyens organisationnels de formalisation par exemple Rédaction systématique de comptes rendus après les réunions.

L'objectif est de structurer des informations d'origines et de formes diverses. Des moyens humains et techniques (notamment des matériels de saisie et des supports d'enregistrement) sont utilisés mais aussi des méthodes, notamment des méthodes de contrôle et de codification de l'information, afin de disposer d'informations fiables et facilement exploitables.

b) Mémoriser l'information

Une fois saisie, l'information doit être stockée de manière durable et stable. Le SI met en oeuvre des moyens techniques et organisationnels (méthodes d'archivage, de protection contre le piratage ou la destruction, etc.).

Aujourd'hui, la mémorisation des informations se fait au moyen deux techniques principales : les fichiers et les bases de données.

c) Exploiter l'information

Une fois mémorisée, on peut appliquer à l'information une série d'opérations. Ces opérations de traitement consistent à :

- Consulter les informations : les rechercher, les sélectionner...

- Organiser les informations : les trier, les fusionner, les partitionner...

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 13

- Mettre à jour les informations: les modifier (sur la forme et le contenu), les supprimer, etc.

- Produire de nouvelles informations: informations calculées (suite à des calculs arithmétiques ou des calculs logiques), cumuls, etc.

d) Diffuser l'information

La diffusion consiste à mettre à disposition de ceux qui en ont besoin, au moment où ils en ont besoin et sous une forme directement exploitable, l'ensemble des informations qui leur permettront d'assurer leurs activités. En ce sens, le système d'information assure la circulation des informations à destination du système de décision et du système opérant.

I.3. SYSTEME MANUEL

Un système manuel, certes plus facile à comprendre, est le moyen le plus sujet à erreur et le plus inefficace de stocker et d'extraire des données financières (⁸). Il se prête à des abus et à la fraude, à des erreurs mathématiques et à la perte d'informations du fait d'un mauvais stockage, et ne permet de produire de rapports qu'au bout d'un temps considérable et moyennant d'énormes ressources humaines.

Enfin, ce type de système ne permet pas facilement de procéder à une analyse statistique des tendances et de leurs causes. Et le plus important c'est qu'il offre une réduction très importante des coûts de gestion de l'information.

Pour une organisation ayant un fort volume d'activité, une base de données informatisée est de loin préférable. Beaucoup d'organisations, d'entreprises et d'établissement utilisent encore des systèmes manuels, mais la plupart d'entre elles informatiseraient immédiatement leur système si elles pouvaient assumer le coût de cette opération, avaient le personnel compétent requis et pouvaient se procurer des logiciels répondant à leurs besoins.

Au fur et à mesure que la technologie de l'information s'améliorera, que le coût de l'informatisation baissera, que le volume de leurs opérations augmentera et que la concurrence s'intensifiera et, partant, favorisera les organisations qui ont plus facilement et plus rapidement accès à l'information, elles éprouveront de plus en plus la nécessité de passer d'un système manuel à un système informatisé.

(⁸) http://solutionspme.lemondeinformatique.fr

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 14

Informatisé non systèmes d'information c'est utiliser les nouvelles technologies de l'information et de communication, c'est tirer profit du développement rapide des solutions informatiques et s'adapter au changement et à l'évolution pour pouvoir résister à la concurrence et garder vie et pourquoi pas être compétitif et se développer.

I.4. INFORMATISATION DE LA VIE D'UNE ORGANISATION

Quelque soit l'entreprise (petite, moyen ou grande) et quelque soit son domaine d'activité (production, service, commercialisation), il y a des fonctions communes (⁹):

- Les ressources humaines qu'il faut recruter, former, rémunérer, gérer ;

- La comptabilité et la finance pour calculer les dépenses, les recettes, la rentabilité, le taux d'endettement, etc.

- La production où les produits (voiture, aliments, services bancaires, cours de formation, etc.) sont «fabriqués» et où on doit planifier, organiser, gérer le stock des produits, les processus de fabrication, la livraison, etc.

- La vente et le marketing, où le contact avec le client a lieu pour le démarcher et lui vendre les produits; et où on doit gérer la relation avec le client et avoir une information précise sur les produits, les tarifs, les promotions, la marge de manoeuvre, etc.

- L'ingénierie, où les nouveaux produits sont imaginés, conçus, testés et évalués et où on se préoccupe des processus de fabrication et des méthodes de travail; on a besoin ici d'une information plus spécifique selon la nature du produit conçu On va donc regarder pour toutes ces fonctions de ce qu'apporte l'informatique et les spécificités des besoins en terme de système d'information.

I.5. SYSTEME D'INFORMATION INFORMATISE

Actuellement, les SI ont pris en compte dans leur conception une composante informatique à cause de l'émergence des systèmes de gestion de base de données et d'applications de gestion informatiques diversifiées qui évoluent de plus en plus. C'est ainsi qu'a été introduit la notion de SAI (Système Automatisé d'Information) (¹⁰).

(9) PASQUIER J. et MINH TUAN N, Introduction à l'Informatique de Gestion I, Université de Fribourg, 2009.

(10) MEIER A., Introduction pratique aux bases de données relationnelles, Springer, Paris, 2002.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 15

I.6. BASE DES DONNEES

I.6.1. Définition

Une Base des données (BD et Data Base « BD » en anglais) est une entité dans la quelle, il est possible de stocker des données de façon structurée et avec moins de redondance possible (¹¹). Ces données doivent pouvoir être utilisées par des programmes, par des utilisateurs différents.

Ainsi, la notion Base des données est généralement couplée à celle de réseau, en fin de pouvoir mettre en commun ces informations, d'où le nom Base. On parle généralement de système d'information pour désigner toute les structures regroupant les moyens mis en place pour pouvoir partager les données.

Une Base des données est avantageuse dans le sens qu'il permet de mettre les données à la disposition d'utilisateurs pour consultation, une saisie ou une mise à jour, tout en s'assurant de droit accorder à ces derniers. Et la majeur avantage de l'utilisation d'une Base des données est la possibilité de pouvoir y accédé par plusieurs utilisateurs simultanément.

I.6.2. Caractéristiques de la base des données

- Une base de données se présent sous la forme d'un ensemble de fichiers appelé tables ;

- Les tables peuvent être liées entre elles par des liens par des relations hiérarchiques, par des relations de dépendance ;

- Une base de données garantit l'intégrité des données ; - Une base de données garantit l'unicité des données ; - Un système de données comprend des index.

I.6.3. Les différents types de base de données (12)

Il existe plusieurs types de base de données parmi lesquelles

on peut citer :

- Gestion de fichiers ou de table ;

- Base de données en réseau ;

(11) LEON F., introduction à l'informatique, éd. Destinée au Canada, 1980

(12) CT. ILUNGA Placide, Cours de base de données, ISIPA, 2010-2011

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 16

- Base de données hiérarchique ; - Base de données relationnelles ; - Base de données objets ;

- Base de données XML ;

- Base de données déductives.

1- Les logiciels de gestion de fichiers ou de tables

Ne peuvent être considérés comme une vraie base de données. L'exemple le plus courant est l'utilisation d'un tableur, par exemple Excel de Microsoft Corp.

Certes un tableur permet d'organiser ses données, d'effectuer un certain nombre de requête, par exemple un tri, ou un cumul, ou une extraction des données. Les tables peuvent être liées entre elle grâce à des pointeurs qui pointent sur des index. Mais les limites sont très vite atteintes et l'utilisation de ce genre de base est à restreindre à quelques milliers d'enregistrements et à des opérations simples.

Néanmoins, dans le cadre d'une utilisation mono-utilisateur ou en partage avec quelques utilisateurs, par exemple la gestion de documents de travail ou sein d'une même équipe, un logiciel simple suffit.

2- Les bases de données en réseaux

C'est une base de données qui offre la possibilité d'établir une multiplicité de lien entre des groupes de données, organisées qui peuvent elles-mêmes être sur des serveurs physiques et distants.

Les bases de données en réseau sont limités car les liens entre les tables sont multiples et ne se prêtent pas facilement à une modélisation. Néanmoins elles permettent de mettre en relation de l'application distante. Elles s'appuient pour la plupart du temps sur des architectures de réseau réparties.

La base de données réseau présente comme inconvénient, les temps de réponses qui ne sont constants à cause des temps de transmissions de l'information dans les réseaux.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 17

Apparues dans le années 1970, elles évoluent encore notamment grâce à de nouveaux concepts de stockages de l'information en ligne.

3- Une base de données hiérarchique

Présente une structure en forme d'arborescence chaque niveau de l'arborescence est lui-même réparti en plusieurs autre sous niveau. Le modèle hiérarchique est composé de champs, qui constituent la plus petite données, de segments, qu'est une collection de champs. Enfin les segments sont organisés en arbre.

Ce genre de base se trouve fréquemment dans des applications vidéotex.

Leur flexibilité est limitées par ce que le chemin d'accès permet d'établir uniquement des liens entre les diverses catégories appartenant à la même hiérarchie. Elles sont apparues dans le milieu des années 1970. Elles sont parfaitement adaptées pour les applications vidéotex, pour le classement de données en nomenclatures, mais aussi pour tout type d'organisation hiérarchique comme les grandes entreprises ou administration.

4- Les bases de données relationnelles

Sont le plus répandues depuis les années 1990. Le concept a été introduit par E.F.codd, qui travaillait au centre de recherche d'IBM.

Le modèle relationnel est fondé sur la théorie mathématique des relations. Ce modèle a été normalisé en 1986. Les éléments fondamentaux sont les objets. Ils sont reliés entre eux par des relations ces relations peuvent avoir des valeurs multiples. Elles sont définies par les cardinalités.

Elles offrent le grand avantage de lire les tables entre elles par des relations. Elles ont bénéficiés de l'apport de la modélisation « Merise », méthode d'analyse informatique. Elles ont également bénéficié d'un langage de requête normalisé de 4éme génération, SQL (squery langage), largement utilisé par les plus informaticiens et pour les utilisateurs aguerris.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 18

Ce modèle a donné les bases de données le plus répandues telles qu'Oracle, Ingres DB2, Sybase.

5- Les bases de données objets

Sont les plus récentes et sont apparues depuis les années 1995. Elles offrent le grand avantage de s'appuyer sur la modélisation objet et depuis quelques années sur la modélisation « UML ». La modélisation objet apporte la notion de relation père-fils, la notion de polymorphisme et la notion de persistance.

L'élément de base est l'objet, défini dans une classe. Une classe peut avoir des sous-classe.les sous -classes héritent des propriétés de la classe. C'est la notion d'héritage. Le polymorphisme est la faculté pour une opération d'avoir différentes signatures avec un code spécifique attaché à chaque signature. Enfin un objet persistant doit pouvoir continuer à exister au-delà du programme qui le crée.

Les applications directes sont les jeux vidéo mais aussi toutes les transactions informatiques en mode déconnecté qui nécessite le maintien temporaire de la transaction. Elles offrent des caractéristiques semblables aux bases relationnelles, mais elles utilisent des structures plus complexes de données que l'on appelle des objets.

6- Les bases de données orientées XML

Sont les nouvelles bases de données émergentes. Complètement orientées Web, c'est-à-dire internet et intranet, elles ont les gros avantages d'être compatibles quels que soient les systèmes d'exploitation des utilisateurs, mais elles amènent également l'indépendance des données par rapport aux structure des données, ce qui permet entre autre à un contenu de page web de s'afficher avec des chartes graphiques différentes.

Pour l'instant encore à l'étude et en expérimentation, elles commencent à être utilisées. Elles s'appuient entièrement sur les langages, produits et logiciels spécifiques à l'internet, tels que : PHP, SPIPE, ZOP... pour l'instant elles sont réservées à des développeurs confirmés.

M F I T I G r a c e P a g e | 19

7- Les bases de données déductives

Sont une autre approche nouvelle pour les bases de données complètement orientées langages utilisateurs, elles ont comme principal avantage de s'appuyer sur des SGBD existants sur lequel on rajoute une couche de langage accessible par les utilisateurs. Ce langage permet aux utilisateurs une approche déductive tout en respectant les syntaxes et règles syntaxiques imposées par les SGBD sur lequel s'appuie le SGBD déductif.

I.7. SYSTEME DE GESTION DE BASE DES DONNEES (SGBD)

Un SGBD est un ensemble de programmes assurant la gestion et l'accès à une base des données. Un SGBD héberge généralement plusieurs base des données, qui sont destinées à des logiciels ou des thématiques différentes (¹³).

La SGBD est un ensemble de service (Applications logicielles) permettant de gérer la Base des données. C'est-à-dire :

- Permettre l'accès aux données de manière simple ;

- Autoriser un accès aux informations par multiples utilisateurs ;

- Manipuler les données présentes dans le Base des données (insertion, suppression, modification).

I.8. UML

I.8.1. Historique

L'histoire d'UML se compose de 5 périodes bien distinctes. On va passer en revue ces périodes pour comprendre pourquoi ce langage a émergé et comment il évolue aujourd'hui encore.

1- Première période (de 1975 à 1995) : la diversification

Les organismes commencèrent à saisir l'importance et la valeur des logiciels, mais ne disposaient que de fragments de techniques permettant de les concevoir, de les produire et de les maintenir.

Mémoire dirigé par Eric WANGI NGOY

(¹³) Http// www.Wikipedia.org(URL du 25 mars 2013)

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 20

Cependant sur la cinquantaine des méthodes d'analyse et de conception qui existaient alors, trois ont émergé du lot, à savoir :

- La méthode BOOCH de Grady Booch qui mettait l'accent sur le design et la construction des systèmes logiciels ;

- La méthode OMT (Objecting Modeling Technique) de James Rumbaugh qui insistait sur l'analyse des systèmes logiciels ;

- La méthode OOSE (Objectif Oriented software Engineering) de Ivar Jabcobxon qui était très pratique pour la formalisation des besoins.

Cependant, les adeptes d'une méthode comprenaient difficilement les interfaces produits par d'autres méthodes. De plus, les praticiens éprouvaient des difficultés pour passer d'une organisation à une autre car ils devaient nécessairement apprendre une nouvelle méthode. Par conséquent, l'apprentissage et l'usage d'une seule méthode ne présentaient qu'un intérêt limité.

2- Deuxième période (du milieu des années 90) : l'unification

Dans le cadre du rapprochement, Grady Booch, James Rumbaugh et Ivar Jabcobxon se sont retrouvés dans la société Rational Software Corporation avec comme objectif de fusionner leurs méthodes pour créer une méthode unique de modélisation objet : UML (Unified Modeling Langage) vit donc le jour, dans sa première version (UML 1.0.), durant la première moitié des années 90.

3- Troisième période (deuxième moitié des années 90) : la normalisation

En 1997, OMG (Object Management Group), instance de normalisation internationale du domaine de l'objet établit un standard définissant la signification des concepts orientés objet pour tous les outils prenant en charge l'analyse et le design orienté objet. UML s'y conforma dans sa nouvelle version UML 1.1. C'est ainsi que OMG l'adopta en 1997 et assuma la responsabilité du développement futur de ce standard.

4- Quatrième période (années 2000) : la révision

Prenant en compte les critiques constructives et commentaires des utilisateurs de cet outil, plusieurs versions se succédèrent après l'adoption par OLG de UML 1.1., afin d'apporter les corrections mineures aux versions antérieures. La version en cours est UML 1.4.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 21

Toutefois, OMG prépare la version UML 2.0, qui se veut une nouvelle génération de cet outil.

5- Cinquième période (deuxième moitié des années 90) : l'industrialisation

Parallèlement à cette période de révision, OMG soumet UML à une normalisation auprès de l'organisme ISO (International Organisation for Standardization).

I.8.2. Définition

UML est l'acronyme de « Unified Modeling Langage », en français « Langage de Modélisation Unifiée ».

Il s'agit d'un langage permettant de modéliser (représenter) un système de façon standard par des pictogrammes ou diagrammes. Il est apparu dans le monde du génie logiciel dans le cadre de la « conception orientée objet ».

De manière plus précise, UML est un langage visuel pour la modélisation des systèmes d'information :

- Permettant la spécification, la visualisation, la construction et la documentation des logiciels ;

- Facilitant la communication et le travail en équipe ;

- Ayant différents modèles pour différents points de vue ;

- Utilisant une approche orientée objet.

Chacun des mots constituant l'appellation UML (à savoir Langage, Modèle et Unifié) décrit un aspect important de cette méthode qu'il importe donc de préciser.

1- Langage

Un langage permet de communiquer à propos d'un sujet. Sans langage, il devient difficile pour les membres d'une équipe en charge de l'analyse d'un système d'information de communiquer et de collaborer au développement de ce système.

UML utilise donc à cet effet tout un ensemble de formalismes ou symboles standards (langage), ayant une signification précise et compréhensibles par tous, pour pouvoir représenter un système d'information.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 22

2- Modèle

Le modèle est une représentation d'un sujet par une combinaison harmonieuse et logique des formalismes ou symboles du langage. Dans le cas d'UML, cette représentation se matérialise par des diagrammes.

3- Unifié

Ce terme fait référence au fait que la méthode UML résulte d'une combinaison des meilleures pratiques en matière de conception des systèmes d'information en vigueur au moment de sa mise au point. Cette combinaison a été réalisée par le groupe OMG (Object Management Group), un organisme de renommé internationale en matière de normalisation dans le domaine de la modélisation orientée objet, et l'entreprise Rational Software Corporation.

I.8.3. Caractéristiques d'UML

UML est basé sur un méta modèle. Cela veut dire qu'UML appelle le programmeur à avoir un esprit ouvert pour mieux représenter la structure observée par des objets, sans se préoccuper de l'environnement programmable où il sera implémenté.

Dès lors UML à une sémantique globale servant de fondement pour les langages orientés objet, définit simplement la structure d'un programme expliquant les interactions entre objets.

La programmation orienté objet implique en premier lieu une conception abstraite d'un modèle objet, en deuxième lieu, l'implémentation à l'aide d'un langage orienté objet (C++, Java, ...).

I.8.4. Le paradigme orienté objet

L'approche « objet » occupe actuellement une place prépondérante dans le génie logiciel, à cause :

d'une utilisation plus large des langages orientés objet de référence comme C++ et Java. ;

de l'introduction des concepts objet dans d'autres langages, comme VB.NET, Perl, Cobol, etc..

le développement très important des applications liées à l'Internet

M F I T I G r a c e P a g e | 23

Eu égard à ce qui précède, il importe que les outils d'analyse et de modélisation des systèmes d'information s'adaptent aussi en conséquence à l'approche « orienté objet ». C'est, comme on l'a vu dans l'historique, le cas d'UML.

I.8.5. Modélisation du système d'information par la méthode UML

La modélisation du système d'information par UML se fait sous forme de diagrammes. Cette méthode propose 13 diagrammes au total dans sa version 2.x. Ces diagrammes sont dépendants hiérarchiquement et se complètent de façon à permettre la modélisation d'un projet tout au long de son cycle de vie. Enfin, ils peuvent être regroupés en deux catégories : diagrammes structurels ou statiques et diagrammes de comportement. Tous ces aspects sont résumés dans la figure et les lignes ci-dessous.

A- Diagrammes structurels

Ces diagrammes ont vocation de représenter l'aspect statique d'un système. Ils sont au nombre de 6, à savoir :

Diagramme de classes (class diagram)

Il représente les classes intervenant dans le système ainsi que les liens entre classes ; chaque classe intégrant la partie dédiée aux données et celle consacrée aux traitements. Il s'agit de la classe pivot de la modélisation du système.

Diagramme d'objets (object diagram)

Il sert à représenter les instances des classes (objets) utilisés dans le système ainsi que les liens entre instances.

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 24

Diagramme de composants (component diagram)

Il montre les différents constituants du logiciel au niveau de l'implémentation d'un système (fichiers, bases des données, modules exécutables, ...), ainsi que les liens entre ces constituants.

Diagramme de déploiement (deployment diagram)

Il sert à représenter les éléments matériels (ordinateurs, routeurs, serveurs, supports de stockage, etc...) formant l'architecture physique du système, les composants produits ou utilisés par chaque matériel, les relations entre éléments matériels, entre composants ainsi que entre composants et éléments matériels.

Diagramme de paquetages (package diagram)

Il donne une vue d'ensemble du système structuré en paquetages (ou package) ; chaque paquetage représentant un ensemble homogène d'éléments du système (classes, composants, ..).

Diagramme de structure composite (composite structure diagram) :

Ce diagramme permet de décrire la structure interne d'un ensemble complexe composé par exemple de classes et de composants techniques. Ce diagramme met l'accent sur les liens entre les sous-ensembles qui collaborent.

B- Diagrammes de comportement

Ces diagrammes représentent la partie dynamique d'un système réagissant aux événements et permettant de produire les résultats attendus par les utilisateurs. Ils sont au nombre de 7, à savoir :

Diagramme des cas d'utilisation (use-cases diagram)

Il représente les besoins des utilisateurs ou acteurs externes au système, c'est-à-dire toutes les fonctionnalités que doit fournir le système. Il constitue l'un des diagrammes les plus structurants dans l'analyse d'un système par l'approche UML.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 25

Diagramme d'états-transitions (state machine diagram)

Il montre les différents états des objets en réaction aux

événements.

Diagramme d'activités (activity diagram)

Il donne une vision des enchaînements des actions ou 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 des données.

Diagramme de séquences (sequence diagram)

C'est une représentation du déroulement séquentielle des traitements intervenant dans le cadre d'un cas d'utilisation en mettant l'accent sur la chronologie des opérations en interaction avec les objets.

Diagramme de communication (communication diagram)

C'est une représentation simplifiée d'un diagramme des séquences, se concentrant sur les échanges de messages entre objets.

Diagramme global d'interaction (interaction overview diagram)

Ce diagramme fournit une vue générale des interactions décrites dans le diagramme de séquence et de flots de contrôle décrits dans le diagramme d'activités.

Diagramme de temps (timing diagram)

Ce diagramme représente les états et les interactions d'objets dans un contexte où le temps a une forte influence sur le comportement du système à gérer.

Remarque :

Dans la modélisation d'un système, il n'est pas indispensable d'utiliser tous les 13 diagrammes proposés par la version 2.x. d'UML. Il appartient donc au développeur, dans la pratique, de choisir ceux qui lui paraissent pertinents pour la modélisation du système analysé.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 26

Toutefois, le diagramme de classes est généralement considéré comme l'élément central d'UML ; tandis que le diagramme des cas d'utilisation comme celui par lequel débute le plus souvent l'analyse du système.

Certains nouveaux diagrammes proposés dans la version 2.x d'UML ne sont que des structures détaillées ou globalisantes des diagrammes existant dans les versions précédentes. C'est le cas des 4 diagrammes suivants : diagramme de structure composite, diagramme de communication, diagramme global d'interaction et diagramme de temps. De sorte que dans les lignes qui suivent, on se limitera à décrire de manière détaillée les 9 autres diagrammes, considérés comme des diagrammes de base.

Pour le cas de notre étude, nous avons sélectionnés les diagrammes suivants : cas d'utilisation, séquences, classes, d'activités et déploiement.

1- Diagramme de classe

Cette vue montre la structure statique d'un système. Une

classe est dessinée à l'aide d'un rectangle solide à trois compartiments : En haut : le nom de la classe en gras ; il y a un stéréotype, c'est-à-dire la mention du genre de classe, il est placé ou dessus, centré, en police normale, noté entre « et » ;

Au milieu : la liste des attributs, avec en africain les types et valeur initiales, selon la syntaxe nom (paramètre : type = valeur par défunt....) : type résultat.

Dans une vue d'ensemble, le rectangle peut-être réduit au seul nom de la classe.

Classe

Attribut 1 : type
Attribut 2 : type

+ Méthode 1 () : type + Méthode 2 () : void

Notre représentation, nous montre directement qu'une classe a trois partis à savoir : le nom, les attributs et les méthodes (opérations) de la classe.

M F I T I G r a c e P a g e | 27

Tenant compte du principe d'encapsulation : UML définit trois niveaux cette visibilité pour les attributs et les opérations :

Public qui rend l'élément visible à tous les attributs de la classe (mot UML :+) ;

Partagé qui rend l'élément visible aux sans clases de la classe (mutation UML : #) ;

Privé qui rend l'élément visible à la classe seule (notation UML :-). A. Relation entre classe (¹⁴)

? Association

Une association est un lien qui unit deux classes.

A

B

Mémoire dirigé par Eric WANGI NGOY

? Multiplicité ou cardinalité

La multiplicité indique combien d'objets d'une classe peuvent être liés à d'autres classes dans une association. La multiplicité s'affiche sans la forme d'une séquence contenant les éléments suivants, séparés par des virgules :

- Exactement un : 1 ou 1.1 ;

- Plusieurs : * ou 0* ;

- Au moins un : 1* ;

- De un à six : 1-6.

La notation signale deux nombres entiers séparés par deux pains <..>. L'étoile, <*>, signifie que la borne supérieurs ne peut pas encore être déterminée.

(¹⁴) KUTANGILA MAYOYA et WANGI NGOY, Progiciel, G3 ISP/Gombe, Kinshasa, 2011-2012

M F I T I G r a c e P a g e | 28

? Classe d'association

La conception par l'existence d'une troisième classe, appelée classe d'association. Cette dernière permet de spécifier les fonctionnalités de la liaison.

Exemple : Client			Article

Mémoire dirigé par Eric WANGI NGOY

Acheter

? Héritage

L'héritage, ou la relation de génération est précisée par deux classes que l'une est une spécialisation de l'autre : elle possède l'ensemble des attributs et des méthodes de la première plus les siens propres.

Une classe mère, appelée aussi super clase est la qui léguera l'ensemble de ses propriétés par héritages. Une classe fille appelée aussi sous-classe, est une nouvelle classe ayant par définition de l'héritage, tous les attributs et toutes les méthodes de la classe mère.

Exemple :

Voiture

Voiture scolaire

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 29

? Agrégation et composition

Une composition est une agrégation plus forte impliquant

que :

- L'élément ne peut appartenir qu'à un seul agrégat composition (agrégation nom partagée) ;

- La destruction de l'agrégat composite entraine la description de tous ses éléments (le composite est responsable du cycle de vie des parties).

Agrégat		Elément
Composition		Elément

2- Le Diagramme des cas d'utilisation

Les cas d'utilisation (use cases) décrivent sous forme d'actions et de réactions, le comportement d'un système du point de vue d'un utilisateur. Avant UML, ils n'étaient pas formalisés par les autres méthodes objet telles que OMT.

Les cas d'utilisation sont utiles lors de l'élaboration du cahier des charges ou du document de spécifications des besoins du logiciel.

Le modèle des cas d'utilisation comprend les acteurs, le système et les cas d'utilisation. L'ensemble des fonctionnalités du système est déterminé en examinant les besoins de chaque acteur, exprimés sous forme de famille d'interactions dans les cas d'utilisation.

Les acteurs se représentent sous forme de petits personnages qui déclenchent les cas. Ces derniers se représentent par des ellipses contenues dans un rectangle représentant le système.

Acteur A

M F I T I G r a c e P a g e | 30

Cas X

Système

Acteur B

Cas Y

3- Diagramme de séquence

Mémoire dirigé par Eric WANGI NGOY

Pour commencer à décrire l'évolution d'un ensemble d'objets, il est possible de dessiner d'abord un diagramme de séquence.

Horizontalement, on place les instances concernées par un scénario et on relie les instances par des flèches indiquant le flux d'événements. Verticalement, le temps est représenté.

Ce type de diagramme donne une première idée des événements qui pourront être pertinents dans la modélisation. On répète ce diagramme autant de fois qu'il existe de scénarii d'événements possibles.

Exemple du téléphone: Dans le suivi d'événements ci-dessous, un utilisateur appelant décroche le téléphone qui envoie un signal sur la ligne téléphonique et la tonalité à l'utilisateur appelant :

UtilAppelant AppareilAppelant LigneTél AppAppelé UtilAppelé

« Décroche » ALTdécroche

« Tonalité »

Le schéma général ci-dessous donne une idée sur la représentation d'un diagramme de séquences correspondant à un cas d'utilisation donné.

M F I T I G r a c e P a g e | 31

Nom du diagramme

Objet 1

(message 3)

(message 1)

(message 4)

(message 2)

Objet 2

Objet 3

4- Diagramme d'activité

4-1- Rôle du diagramme d'activités

Le diagramme d'activités représente le déroulement séquentiel des actions à réaliser dans le cadre d'un cas d'utilisation. Le passage d'une activité à la suivante est matérialisé par une transition.

L'activité est une action ou un ensemble d'opérations liées dont l'exécution entraîne une modification de l'état du système.

En fait, le diagramme d'activités est une vue macroscopique du diagramme d'état-transition. En effet, alors que le diagramme d'état-transition décrit le comportement interne d'un objet qui, à la suite d'un événement, peut passer d'un état à un autre, le diagramme d'activités par contre décrit le comportement interne d'un cas d'utilisations dont les activités se succèdent de manière logique et séquentielle, formant une chaîne ou flot de contrôles. On constatera du reste quelques similitudes en ce qui concerne certains concepts et formalismes utilisés.

4-2- Eléments constitutifs du diagramme d'activités

Le diagramme d'activités est formé des éléments suivants : Activité ou action ;

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 32

Transition ; Noeud ;

Couloir d'activité.

M F I T I G r a c e P a g e | 33

4-3- Formalisme

CLIENT

AGENT GUICHET

RESPONS. STOCK

Début

Réceptionner

Analyser

Commander

un produit

commande

commande

stock non disponible

stock disponible

facture établie

commande établie

Préparer Facture

réceptionner produit

expédier le

produit

commande honorée

Envoyer produit

réceptionner

produit et

facture

et facture

recevoir

la facture payer

l'argent

Fin

facture payée

Mémoire dirigé par Eric WANGI NGOY

« artefact ))

BDDClients

Serveur Applications

«artefact ))

BDDStock

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 34

5- Diagramme de déploiement

5-1- Rôle du diagramme de déploiement

Le diagramme de déploiement représente l'architecture ou l'environnement physique supportant l'exploitation du système. Il est composé des ressources matérielles de traitement, appelées noeuds, et des composants logiciels utilisés ou produits par ces noeuds, appelés artefacts.

5-2- Eléments constitutifs du diagramme de déploiement

Le diagramme de déploiement comprend donc les éléments

suivants :

Noeuds ; Artefacts ;

Relation entre noeuds et entre artefacts ;

Spécification de déploiement.

5-3- Formalisme

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 35

L'élaboration de ce chapitre est d'une grande importance du fait que le planning prévisionnel de réalisation du projet nous aide à maitriser la durée et le coût du projet.

II.1. METHODE PERT

II.1.1. Définition

Le Pert (Program of Evaluation and Review Technique) est une méthode consistant à mettre en ordre sous forme de réseau plusieurs tâches qui, grâce à leur dépendance et à leur chronologie, concourent toutes à l'obtention d'un produit fini (¹⁵).

La méthode PERT est le plus souvent synonyme de gestion de projets importants et à long terme. C'est pourquoi, plusieurs actions sont nécessaires pour réussir sa mise en oeuvre.

II.1.2. Démarche

- Définir de manière très précise le projet ;

- Définir un responsable de projet, auquel on rendra compte et qui prendra les décisions importantes ;

- Analyser le projet par grand groupe de tâches, puis détailler certaines tâches si besoin est ;

- Définir très précisément les tâches et déterminer leur durée ;

- Rechercher les coûts correspondants (ce qui peut éventuellement remettre en cause certaines tâches) ;

- Effectuer des contrôles périodiques pour vérifier que le système ne dérive pas.

II.1.3. Formalisme

Le graphe Pert est composé d'étapes et de tâches :

? Exemple de représentation de la tâche A : Tâche A

? Exemple de représentation de l'étape 1 :

(¹⁵) http://www.transdata.fr/bois/Cours/PERT/PERT.htm

M F I T I G r a c e P a g e | 36

N° de l'étape

1

5

7

Délai au plutôt

Délai au plus tard

? Règles de représentation :

- Toute tâche a une étape de début et une tâche de fin

B

1 A

1 2 3

- Deux tâches simultanées :

C

2

1

D

3

- Deux étapes convergentes :

1

E

3 G 4

2

F

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 37

II.2. ORDONNANCEMENT II.2.1. Description des tâches

Cette étape permet de ressortir les différentes activités qui seront menées pour le projet soit fini. Par rapport à notre travail, les activités suivantes s'avèrent importantes pour sa réalisation :

- Récoltés des données ;

- Etude préalable ;

- Etude détaillée (conception) ;

- Etude technique (réalisation) ;

- Développement et test unitaire ;

- Test d'intégration ;

- Maintenance ;

- Formation des utilisateurs ;

- Acquisition des matériels ;

- Déplacement et livraison.

Il permet d'ordonner dans le temps un ensemble d'opérations contribuant à la réalisation d'un même projet. Le déroulement de ces diverses opérations (tâches) doit respecter certaines contraintes qui peuvent être :

- Soit des contraintes d'antériorité : avec la logique selon laquelle une tâche ne peut commencer que lorsque une tâche est terminée (contraintes de succession) ou celle selon laquelle une tâche ne peut commencer qu'un certain laps de temps après que la tâche ait

- commencé.

- Soit des contraintes de date : qui stipule qu'une tâche ne peut commencer avant une certaine date dans le but de minimiser la durée totale de la réalisation du projet.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 38

II.2.2. Tableau d'ordonnancement

Code d'activités	Activités	Activités antérieures	Durées	Coût en $ /jours	Coût total
A	Récoltes de données	-	03	50	150
B	Etude préalable	A	05	500	2500
C	Etude détaillée	B	07	500	3500
D	Etude technique	C	10	300	3000
E	Développement et test unitaire	D	45	100	4500
F	Test d'intégration	E	1	50	50
G	Maintenance	F	10	100	1000
H	Formation des utilisateurs	F	15	50	750
I	Acquisition des matériels	G, H	2	50	100
J	Déploiement et livraison	I	1	100	100

M F I T I G r a c e P a g e | 39

II.2.3. Elaboration du graphe PERT

Début

0 0

0 0

A

8 8

C

3

5

3

3

B

7

15 15

D

10 25

E

25

45

70 70

F

1

71 76

10

G

86 86

1

I

15

71 71

H

88 88

J

2

5

93 93

Fin

- Chemin A: A, B, C, D, E, F, G, I, J - Chemin B: A, C, D, E, F, H, I, J

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 40

II.4. CALCULS DES DATES FIN AU PLUS TOT

Ce sont des dates qui permettent de déterminer pour chaque étape, une date limité de réalisation de telle sorte que la date au plutôt de la fin des travaux ne soit pas retardée.

La formule qui nous permet de calculer la date au plus tôt est

la suivante : DFO (x) : max[ ( ) ( )]. Les calculs s'effectuent sur les
sommets.

DFO(1)=0

DFO (2) = DFO (1) + d(A) DFO (2) = 0 + 3 = 3

DFO (3) = DFO (2) + d(B) DFO (3) = 3 + 5 = 8

DFO (4) = DFO (3) + d(C) DFO (4) = 8 + 7 = 15

DFO (5) = DFO (4) + d(D) DFO (5) = 15 + 10 = 25 DFO (6) = DFO (5) + d(E) DFO (6) = 25 + 45= 70 DFO (7) = DFO (6) + d(F) DFO (7) = 70 + 1 = 71 DFO (8) = DFO (7) + d(H) DFO (8) = 71 +15 = 86 DFO (9) = DFO (8) + d(I) DFO (9) = 86 + 2 = 88 DFO (10) = DFO (9) + d(J) DFO (10) = 88 + 5 = 93

II.5. CALCULS DES DATES DE FIN AU PLUS TARD

Il permet de déterminer pour chaque tâche une date de début au plus tard de sorte que la date de fin des travaux ne soit pas retardée.

La formule qui nous permet de calculer la date au plus tard

est la suivante : DFA = min [ ( ) ( )] ou DFA représente la durée au

plus tard de l'activité suivante et d(i) la durée de l'activité.

DFA (10) = 93

DFA (9) = DFA (10) - d (J)

DFA (9) = 93 - 5 = 88

DFA (8) = DFA (9) - d (I)

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 41

DFA (8) = 88 - 2 = 86 DFA (7) = DFA (8) - d (H) DFA (7) = 86 - 15 = 71 DFA (6) = DFA (7) - d (F) DFA (6) = 71 - 1 = 70 DFA (5) = DFA (6) - d(E) DFA (5) = 70 -45 = 25 DFA (4) = DFA (5) - d(D) DFA (4) = 25 - 10= 15 DFA (3) = DFA (4) - d (C) DFA (3) = 15 - 7= 8

DFA (2) = DFA (3) - d (B) DFA (2) = 8 - 5 = 3

DFA (1) = DFA (2) - d (A) DFA (1) = 3- 3= 0

II.6. CALCULS DES MARGES II.6.1. Calculs des marges libres

La marge libre est le retard maximum que l'on peut apporter à la mise en route d'une tâche sans remettre en cause la date au plus tôt d'aucune tâche.

Sa formule est :

ML (1) = DFO (y) - DFO (x) - d(i)

ML (A) = 3 - 0 - 3 = 0

ML (B) = 8- 5 - 3 = 0

ML (C) = 15- 7- 8 = 0

ML (D) = 25- 15-10 = 0

ML (E) = 70- 25- 45 = 0

ML (F) = 71- 1- 70 = 0

ML (G) = 86- 15- 71 = 0

ML (H) = 88- 2 - 86 = 0

ML (I) = 93- 5 - 88 = 0

M F I T I G r a c e P a g e | 42

II.6.2. Calculs des marges totales

Il traduit le retard maximum que l'on peut prendre dans la mise en route d'une tâche, sans remettre en cause les dates au plus tard des tâches suivantes.

Sa formule est :

MT (i) = DFA (y) - DFO (x) - d (i)

MT (A) = 3 - 0 - 3 = 0

MT (B) = 8 - 3 - 5 = 0

MT (C) = 15 - 8 - 7 = 0

MT (D) = 25 - 10 - 15 = 0

MT (E) = 70 - 45 -25 = 0

MT (F) = 71 - 70 -1 = 0

MT (G) = 86 - 71 -15 =

MT (H) = 88 - 86 -2 = 0

MT (I) = 93 - 88 - 5 = 0

II.7. DETERMINATION DU CHEMIN CRITIQUE

Le chemin critique est: d(A), d(B), d(C), d(D), d(E), d(F), d(G), d(H), d(I) et d(J).

II.8. CALCUL DU COUT TOTAL DU PROJET

- Formule : ? ( )

- Calcul : 150 + 2500 + 3500 + 3000 + 4500 + 50 + 1000 + 750 + 100 + 100 = 15.650$

II.9. DETERMINATION DE LA DUREE DU PROJET

Mémoire dirigé par Eric WANGI NGOY

3 + 5 + 7 + 10 + 45 + 1 + 15 + 2 + 5 = 93 jours

M F I T I G r a c e P a g e | 43

II.10. REPRESENTATION DU CHEMIN CRITIQUE

0 0

0 0

3

3

3

5

8 8

7

15 15

10 25

25

45

70 70

Début

A

B

C

D

E

F

1

71 76

10

86 86

1

71 71

G

15

I

2

88 88

J

H

5

93 93

Fin

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 44

III.1. PRESNETATION DE L'ENTREPRISE

III.1.1. Historique de SEP-CONGO

La société SEP-CONGO a été fondée par la compagnie d'envers, le 30 décembre 1910, sous la dénomination « société anonyme de pétrole du Congo » en sigle, « Petro-Congo », en vue d'alimenter en gasoil le chemin de fer du Bas-Congo avec le siège à Bruxelles.

Dès 1924, Petro-Congo fut sous la direction technique et la gestion de « Petro-Fina » qui était la compagnie financière Belge de pétrole, fondée en 1910. Quelque temps plus tard, Petro-Fina changea d'appellation et devint la société économique Belge de pétrole, en abrégé « Petro-Com ».

Le 06 février 1962, Petro-Com créa une société filiale dénommée « société congolaise d'entreposage et de manutention », dont le siège fut transféré de Bruxelles à Kinshasa (Léopoldville).

En 1963, cette société prend la dénomination de société congolaise des produits de pétrole, en signe « SOCOPETROLE » qui fonctionna jusqu'en 1974. L'ordonnancement n°74/0012 du 10 janvier 1974 frappe toutes les sociétés pétrolières étrangères oeuvrant au Congo et crée alors la société « Petro-Congo » service intégrant en son sein une unité dénommée « Congo service » et toutes les attributions de l'ancienne société SOCOPETROLE lui sont confiées.

C'est ainsi que l'ordonnance n°78/038 du 20 janvier 1978, l'entité Congo service devint une société à responsabilité limitée avec une participation de l'Etat comme dans toutes les autres sociétés pétrolières. L'Assemblée Générale du 28 Juillet 1978 décida la dénomination « CONGO SERVICE DES ENTREPRISES PETROLIERES » en signe, « CONGO SEP », dont l'autorisation d'existence fut donnée par l'ordonnance présidentielle n°82/072 du 02 juin 1982, comme l'est pour toute société par action à responsabilité limitée (SARL).

III.1.2. Nature juridique

SEP-CONGO est une entreprise de droit privé. Son capital social est représenté par 120.000 actions des 7 actionnaires dont 36,6% sont détenus par un actionnaire public « COHYDRO », et 63,4% par les actionnaires privés

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 45

essentiellement ARISTEA, ENGEN, OVERSEAS, HOLDING Ltd, MOBIL PETROLEUM COMPANY et ELF OIL RDC dans la proportion suivante :

N°	NOMS D'ACTIONNAIRES	NOMBRE D'ACTIONS	POURCENTAGE D'ACTIONS
01	COHYDRO	43.920	36,60
02	ARISTEA (FINA et ENGEN)	43.918	36,58
03	SHEL OVERSAS HOLDIND Ltd	15.600	13,00
04	MOBIL PETROLEUM Cie	9.360	7,80
05	ELF OIL RDC	7.200	6,00
06	FINA MARINESA	01	0,01
07	ETMO FINA S.A	01	0,01
TOTAL		120.000	100,00

III.1.3. Objet social

Cet objet social est contenu dans les statuts qui créent la société et qui stipulent à l'article 2 que : « la société a pour objet, l'achat, l'importation, la revente des produits pétroliers, la réception, l'entreposage, la manutention, le transport des produits pétroliers sur toute l'étendue du territoire national.

A ce jour, bien que prévues dans ses statuts les activités principales de SEP-CONGO restent limitées à :

- La réception ;

- L'analyse des produits dans les laboratoires ;

- Le transport massif et la distribution des produits pétroliers sur toute l'étendue du territoire national dans le strict respect de normes d'hygiène de qualité, de sécurité et d'environnement ;

- Le dédouanement des produits pétroliers où la SEP jouit du monopole de fait.

Comme son nom l'indique, Congo service des entreprises pétrolières SEP-CONGO, ne commercialise pas les produits pétroliers, mais elle assure le service de mise en place des produits pétroliers, c'est-à-dire des opérations de réception, stockage, transport et livraison du carburant aux sociétés commerciales pétrolières installées dans le pays. Elle assure également la distribution directe des grands consommateurs.

III.1.4. Siège social

Le statut de la société prévoit à l'article 4 que : « la siège social de SEP-CONGO est situé à Kinshasa en RDC au n°1 de l'avenue des pétroles, dans la

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 46

commune de la GOMBE ». Elle est inscrite au n°2667, n°identification nationale (ID.NAT) JK 12209/F, n°CC A31, BP.2197 KINSHASA I.

Toutefois, en tout compte, par simple délibération du conseil d'administration, le siège social peut être déplacé en tout autre endroit de la RDC.

III.1.5. Missions de la SEP-CONGO

Etant partenaire de la politique économique du pays, SEP-CONGO est appelé à accomplir certaines missions qu'elle s'est donnée elle-même et celles qui lui ont confiées, à savoir :

- garantir le respect des normes de qualité, de sécurité et d'environnement ainsi que les étapes d'opérations de spécifications des produits pétroliers à toutes les phases de manipulation ;

- gérer physiquement et administrativement les stocks de produits pétroliers pour le compte des propriétaires et en assurer la disponibilité des produits sur toute l'étendue du pays ;

- minimiser les pertes et coulages dans tous les circuits opératoires ;

- assurer le transport des produits pétroliers vers tous les dépôts de l'intérieur par voie fluviale, ferroviaire et routière ;

- effectuer les livraisons de produits pétroliers dans les grandes agglomérations urbaines ;

- ravitailler les aéronefs nationaux ou étrangers (internationaux) dans les aéroports du pays ;

- gérer un système douanier permettant l'établissement des statistiques fiables des importations des produits pétroliers et les calculs de taxes à payer à l'Etat par les opérateurs du secteur.

III.1.6. Organigramme

Direction Générale

Direction Générale Adjoint

Direction juridique

Direction des

ressources humaines

Direction

administrative

Direction financière

Direction technique

Direction

d'exploitation

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 47

III.1.7. Description des tâches de l'organigramme de SEP-CONGO

a) la direction générale (DG)

Elle coordonne les activités de tous les départements. Elle veille à la bonne gestion de la société et rend compte aux actionnaires de sa gestion journalière en tant que premier responsable de l'Assemblée Générale des actionnaires. La direction générale a sous sa dépendance directe deux services de haute importance : le service d'audit interne et service d'achats.

b) La direction générale adjoint (DGA)

Elle a sous sa dépendance deux services : service planning et le service projet. Le directeur général adjoint assiste le directeur général dans ses lourdes tâches.

c) La direction d'exploitation (DE)

Elle s'occupe de la distribution des produits pétroliers sur toute l'étendue de la RDC pour le compte des sociétés commerciales. Elle gère ensuite tout les dépôts et bases de la société.

d) La direction technique (DT)

Elle s'occupe principalement du transport des produits pétroliers. Elle regroupe en son sein d'autres services tels que : le magasin, les ateliers, le transport et la maintenance. Cette direction travaille en étroite collaboration avec la direction d'exploitation.

e) La direction financière (DF)

Elle est la force motrice de la société, c'est elle qui gère et qui suit l'évolution de l'entreprise sur le plan financier, elle élabore le budget d'investissement et d'exploitation, établit les bilans de la société et organise les différentes services de comptabilité.

Son rôle principal est aussi de veiller à l'utilisation rationnelle des fonds de la société. Toute sortie des fonds engagent la société ne peut se faire sans l'examen et l'approbation de cette direction.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 48

f) La direction des ressources humaines (DRH)

Cette direction s'occupe tant de la gestion de l'ensemble du

personnel de la société que de la sécurité du patrimoine de la société ; la politique

du personnel de cette direction consiste en :

- L'embauche et l'effectif du personnel ;

- L'accueil et la formation des nouveaux engagés ;

- La formation et le perfectionnement du personnel à tous les niveaux

hiérarchiques ;

- La rémunération, la promotion et l'information ;

- Le maintien de la discipline, le respect des règlements de l'entreprise et les

sanctions ;

- La protection physique du personnel ;

- Les oeuvres sociales ;

- Les soins médicaux et pharmaceutiques ;

- Les problèmes juridiques du personnel.

Cette direction est subdivisée en services différents. Il s'agit

notamment :

- Du service administratif qui a pour charge la paie, le mouvement (recrutement et autre traitement des dossiers des agents) ;

- La garde industrielle ;

- Du service des soins médicaux.

g) La direction administrative (DA)

Cette direction gère pratiquement tous les problèmes d'ordre

administratif de la société, elle a pour mission :

- l'organisation ;

- La coordination ;

- La prévision ;

- Le contrôle des activités de SEP-CONGO.

III.2. PRESENTATION DU SERVICE DE DISTRIBUTION

III.2.1. Postes du service de distribution

Le service de distribution compte six postes de travail :

- Responsable de l'assurance du respect des procédures du service de distribution ;

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 49

- Responsable adjoint de l'assurance du respect des procédures du service de

distribution ;

- Le responsable du mouvement des produits ;

- Le chargé du dispatching commercial ;

- Le chargé de suivi de traitement des instructions ;

- Le chargé de l'élaboration des stocks dans les dépôts de l'intérieur.

III.2.2. Organigramme du service de distribution de SEP

Responsable de distribution

Responsable Adjoint de distribution

Dispatching		Stocks	Mouvements Produit	Suivi des instructions

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 50

L'étude du système existant fournit une base d'analyse pour identifier les éléments du problème.

IV.1. ANALYSE DE LA STRUCTURE EXISTANTE

La structure du service de distribution de SEP est la suivante :

- Responsable de l'assurance du respect des procédures du service de

distribution ;

- Responsable adjoint de l'assurance du respect des procédures du service de

distribution ;

- Le responsable du mouvement des produits ;

- Le chargé du dispatching commercial ;

- Le chargé de suivi de traitement des instructions ;

- Le chargé de l'élaboration des stocks dans les dépôts de l'intérieur.

IV.2. ANALYSE DE POSTE DE TRAVAIL

IV.2.1. Responsable de l'assurance du respect des procédures du service de distribution

- Il garanti le respect des procédures du service de distribution ;

- Il garanti la bonne marche des activités du service de distribution du SEP ;

- Il fait l'intérim des unités du mouvement de produit ;

- Il fait des différents rapports du département : entités extérieures et

intérieures ;

- Il organise et fait le suivi de l'approvisionnement de produit de tous les

dépôts de SEP du pays.

IV.2.2. Responsable adjoint de l'assurance du respect des procédures du service de distribution

Le Responsable adjoint de l'assurance du respect des procédures du service de distribution assure les responsabilités suivantes :

- il traite des vignettes, c'est-à-dire contrôler les factures de consommations des carburante par les entités de SEP ;

- il fait le suivi des sorties des clients de dépôts et de bases, c'est-à-dire il s'agit de toutes les sorties des produits pétroliers réaliser dans les dépôts pour le compte des sociétés commerciales ;

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 51

- il établi des commandes carburants pour le compte des entités, dépôts et bases de SEP ;

- il fait le suivi des consommations de dépôts, en d'autre terme c'est un travail qui est lié à l'établissement des commandes ;

- il fait la coordination ou la supervision des documents.

IV.2.3. Le responsable du mouvement des produits

- il fait le traitement des programmes et bons de livraison ;

- il fait l'assurance de l'expédition des produits pétroliers par l'unité ;

- il émet les bons et établi les programmes dans un système de gestion de base des données (SGBD) appelés SUN.

IV.2.4. Le chargé du dispatching commercial

- il fait le traitement des instructions commerciales, c'est-à-dire, il vérifie si tous les éléments importants y sont. Ces éléments sont :

o entête ;

o référence ;

o quantité ;

o nature du produit.

- il fait l'établissement du dispatching qui découle du traitement des instructions.

IV.2.5. Le chargé de suivi de traitement des instructions

Il fait le suivi des établissements du dispatching : transmission des établissements du dispatching à la radio, puis vérification de document s'il est arrivé à la destination attesté par un accusé de réception.

IV.2.6. Le chargé de l'élaboration des stocks dans les dépôts de l'intérieur

- il élabore des stocks par produit et par sociétés commerciales dans chaque province. Ces données sont générées par les messages ou les câbles de stock dans chaque dépôt et se trouve dans toutes les destinations concernées par les sociétés commerciales ;

- il fait la facturation des services demandés aux sociétés commerciales.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 52

IV.3. ETUDE DES DOCUMENTS DE GESTION UTILISE

IV.3.1. Document d'entrée d'information

Les documents d'entrée des informations « les intrants » sont des documents sur bases des quels on établit les documents des états des synthèses.

1. Programme de dépôt du produit (PDP): c'est un document qui étale la proportion des entrées de produits pétroliers dans les dépôts du service de distribution de SEP

2. Bons de commande (BC) : c'est bon de commande sont établi sur base de commande exprimé par les sociétés commerciales.

3. Instruction de commande (IC) : c'est un document qui intervient lorsqu'on la commande est déjà introduite au service de distribution de SEP.

4. Relevé des dispatchings commerciaux (RDC) : C'est un document qui intervient lorsque le processus de dispatching est effectué.

5. La fiche de stock(FC) : cette fiche reprend les produits qui sont entreposés dans les dépôts du service de distribution du SEP.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 53

IV.3.2. Document des sorties

Ces documents sont :

1. Bons de livraison (BL): c'est un document qui établis après avoir défini le client dont on doit livrer les produits pétroliers commandés.

2. Programme de livraison (PL) : c'est un tableau récapitulatif des livraisons que doivent faire le service de distributions de SEP.

3. Ordre de chargement (OC): c'est un document qui est établi pour l'organisation de chargement des produits pétroliers à travers le service de distribution.

4. Rapport de chargement (RC) : c'est un document qui reprend les différents chargements effectués par le service de distribution de SEP.

5. Le tableau récapitulatif des rapports (TRR) : c'est tableau reprend les sorties de client établi par le service de distribution.

6. Copie de chargement (CC) : c'est un document qui reprend les détails sur les produits chargés par les travailleurs du service de distribution.

7. La facturation (F) : c'est un document qui atteste le règlement par les sociétés commerciales de la créance de SEP.

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 54

IV.4. SCHEMA DE CIRCULATION DES INFORMATIONS

CLIENTS 100						SOCOM 200				DTI 300											DMP 400								DDC 500								DSD 600
101	Passation des commandes.								101	201																			401								501
																									301
						201	Réception des bons de commande et envoi des instructions			301		Réception des instructions de SOCOM et Traitement des instructions									401		Réception du programme de livraison et instructions.						501		Réception des instructions de livraison et établissement des ordres de chargement						601			Réception du tableau récapitulatif des rapports de distribution des produits
						301
																																						TRR
											Lettre							IC
																					PL					IC
																													IC					OC
201 301
										102
																														401
																					302
102	Réception de la lettre de livraison des produits									302		Etablissement du dispatching ou programme de livraison adressé à la direction de DMP.
		Lettre
														PL

M F I T I G r a c e P a g e | 55

IV.4.1. Description du schéma

N°	POSTE	TACHE	Commentaire de la tâche
01	100	101	Passation des commandes.
		102	Réception de la lettre de livraison des produits
02	200	201	Réception des bons de commande et envoi des instructions
03	300	301	Réception des instructions de SOCOM et Traitement des instructions
		302	Etablissement du dispatching ou programme de livraison adressé à la direction de DMP.
04	400	401	Réception du programme de livraison et instructions.
05	500	501	Réception des instructions de livraison et établissement des ordres de chargement.
06	600	601	Réception du tableau récapitulatif des rapports de distribution des produits.

IV.4.2. Légende du schéma

: Un document manuel

: Archivages

: Classement : Provenance

: Destination

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 56

IV.5. ETUDE DES MOYENS DE TRAITEMENT DES INFORMATIONS

Par moyens de traitement des informations, nous présentons de façon précise les moyens humains et matériels utilisés dans la dite gestion (¹⁶).

IV.5.1. Moyens humains

Par moyens humains, nous faisons allusion aux personnes qui participent à la gestion des commandes et des fonds y afférents. En effet, ce service compte 6 responsables secondé par plusieurs personnes qui travaillent sous leur direction.

Il est à noter que les agents qui prestent dans ce service sont d'une qualité et d'un bon niveau intellectuel.

IV.5.2. Moyens matériels

Par moyens matériels, nous faisons allusions aux outils de travail utilisés dans la gestion de commandes et programme de livraison des produits aux clients. Notons que les agents du service de distribution n'utilisent dans leur travail les matériels ci-après :

- L'ordinateur ;

- Le stylo ;

- Les papiers ;

- Les tables et armoires ;

- Les imprimés ;

- Les lattes ;

- Les cahiers.

Bref, la gestion des commandes, de programme de livraison aux clients est mixte, c'est-à-dire manuel et informatique. Au niveau manuel, ce service utilise tout ce qu'un système manuel peut utiliser dans une gestion. Mais sur le plan informatique, le constat est que le système informatique utilisé est moins perfectionne manque plusieurs éléments qui peuvent le rendre plus performant dans la gestion des commande et programme de livraison des produits aux clients.

(¹⁶) MVIBUDULU KALUYITUKAKO, Cours de MAI, Institut Supérieur de Commerce de la Gombe, 2010-2011, inédit

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 57

IV.5.3. Moyens financiers

La société fonctionne avec les recettes réalisées par l'entreprise à travers les ventes de produits pétroliers.

IV.6. CRITIQUE DE L'EXISTANT

IV.6.1. Aspects positifs

Au niveau manuel, nous avons observé que les moyens mis à la disposition de services de distribution de SEP sont suffisants et efficaces. C'est-à-dire un nombre insuffisant des travailleurs avec un travail important à réaliser, un travail stressants, demande de beaucoup des concentrations, ils n'ont pas droit à l'erreur et le temps est vraiment limité.

IV.6.2. Aspects négatifs

Du point de vue informatique, le système informatique installé dans le service de distribution connait d'une manière récurrente les problèmes de connexion.

En effet, ce système mixte de travail au service de distribution permet à ce dernier d'atteindre les clients et suivre l'évolution du dossier des commandes.

Départ l'analyse que nous avons menés sur les systèmes d'information existant du service de distribution de SEP est purement manuel malgré la présence des certains outils informatiques.

IV.7. PROPOSITION DES SOLUTIONS

IV.7.1. Solution manuelle améliorée (Sur le plan manuel)

Le service de distribution de SEP est un service qui se doit de servir aisément et rapidement sa clientèle vue l'importance que présentent les produits distribués par SEP.

Cependant, toutes les opérations commerciales, le facteur premier pour les opérations commerciales, le facteur pour les réaliser c'est le temps, Le service a l'obligation de tenir compte de ce facteur et revoir tant soit peu le circuit de la circulation des informations d'un service à un autre.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 58

Sur ceux, en améliorant son système, le service de distribution de SEP privilégie une bonnes tenues des opérations qu'il effectue avec ses clients, ce qui peut entraîner une amélioration de son travail envers le client et une attirance de la clientèle.

IV.7.2. Solution informatique

Afin de répondre aux besoins de traitement des informations relatives à la gestion des activités de distribution de service de distribution de SEP, notre proposition serait de mettre à la disposition de ce service un outil informatique conçue et programmée afin de faciliter le travail de ce service mais rendra aussi la tâche à exécuter par les agents des services concernés facile et éviterait des retards d'exécution des tâches.

C'est ainsi l'implantation d'un système automatisée d'information (SA!) est nécessaire.

Le SA! est un sous-ensemble du système d'information (S!) dont les événements ou informations entrées permettent de déterminer par programme les événements ou informations conséquents.

IV.7.3. Choix de la meilleure solution

Une solution est choisie lorsqu'elle est capable d'atteindre les objectifs. Vue les grands nombre davantage offerts par la solution informatique, notre choix est porté sur cette dernière et nous proposons au service de distribution de SEP d'opter pour le système totalement informatisé qui va lui garantir une gestion rapide, efficace et cela dans un temps record en ce qui concerne les livraisons à effectuer afin de fournir par le traitement automatique des informations fiables pour la bonne prise de décisions en temps réels.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 59

V.1. INTRODUCTION

L'objectif de l'application est de faciliter le suivi de distribution des produits pétroliers auprès des clients. Au niveau de ce chapitre, qui constitue la première phase du processus unifié « incubation », nous détaillons et analysons les besoins fonctionnels et non fonctionnels de notre projet.

V.2 CAPTURE DES BESOINS

V.2.1. Besoins fonctionnels

Un besoin fonctionnel spécifie l'action qu'un système doit être capable d'effectuer, hors contrainte physique : besoin spécifiant un comportement d'entrée/sortie d'un système (¹⁷).

La gestion du circuit de distribution des produits pétroliers doit être assurée durant toutes ses phases, dès l'initiation jusqu'à la clôture. La première étape est la réception des commandes par les clients contenant toutes les spécifications détaillées, puis la publication d'un programme de livraison. Une fois le programme de livraison publié, il faut procéder à l'exécution de programme de livraison et l'analyse de ce dernier permet d'ordonner les livraisons aux clients.

Dans ce contexte notre application de gestion du circuit de distribution des produits pétroliers, implémente les fonctionnalités suivantes :

- Le suivi de la distribution : chaque responsable de la direction de la distribution peut consulter la situation d'un circuit de distribution, ou bien la liste de tous les clients dont on doit livrés les produits pétroliers.

- La gestion de commande : le responsable chargé de la gestion du mouvement de produit doit informer celui qui gère le circuit de distribution du niveau de stock dans le dépôt.

(¹⁷) MORLEY C., LEBLANC B. et HUGUES J., UML pour l'analyse d'un système d'information, Le

cahier des charges du maître d'ouvrage, Dunod, Paris, 2000.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 60

- L'élaboration des produits dans le stock : le chargé de l'élaboration des produits en stock doit présenter à celui qui est chargé de la commande de la situation générale de chaque produit dans le dépôt.

- Le chargé de suivi des instructions : doit informer le responsable de la gestion de la distribution du respect des instructions ou non en ce qui concerne le programme du dispatching des produits auprès de clients.

V.2.2. Besoins non fonctionnels

Un besoin non fonctionnel est besoin spécifiant des propriétés du système, telles que les contraintes liées à l'environnement et l'implémentation, les exigences en matière de performances, de dépendances de plate-forme, de facilité de maintenance, d'extensibilité et de fiabilité (¹⁸).

Dans notre système, on distingue les besoins non fonctionnels suivant :

- Sécurité : la plateforme doit assurer la sécurité pour les utilisateurs (Authentification).

- Convivialité : ergonomie des interfaces homme machine et facilité d'utilisation.

- Contrôle : saisie contrôlée selon les choix prédéfinis.

- Gagner du temps à l'intérieur de l'entreprise.

V.3. ANALYSE DES BESOINS V.3.1. Modèle cas utilisation

La spécification des besoins représente l'ensemble des services que doit fournir le logiciel à son utilisateur (¹⁹). Selon le processus unifié chaque service est modélisé sous un cas d'utilisation, pour élaborer à la fin un diagramme UML de cas d'utilisation. Chaque cas d'utilisation est décrit sous une forme textuelle représentant un scenario nominal (ensemble des actions à réaliser pour atteindre l'objectif).

Dans cette partie, nous allons dégager tous les acteurs en les décrivant. Ensuite, nous allons exprimer dans des phrases les principales actions du système et des acteurs. Enfin, nous allons représenter et décrire

(18) LAI M., UML : La notation unifiée de modélisation objet - De Java aux EJB, Dunod, Paris, 2000

(19) Idem

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 61

les différents diagrammes des cas d'utilisation pour donner une vue externe sur notre système.

V.3.1.1. Identifications des acteurs

Un acteur est une personne, un matériel ou un logiciel qui interagit directement avec le système pour réaliser une tâche. Ainsi, un acteur peut consulter et/ou modifier directement l'état du système en émettant et/ou recevant des messages susceptibles contenir des données.

Notre système comprend plusieurs utilisateurs que nous citons : le responsable de la direction, le responsable du mouvement des produits, le chargé du dispatching commercial, le chargé de suivi de traitement des instructions et le chargé de l'élaboration des stocks dans les dépôts de l'intérieur.

- Le responsable de la direction de distribution (RDD): le système lui offre la possibilité de s'authentifier et gérer les activités faites par le responsable du mouvement des produits, le chargé de suivi de traitement des instructions, le chargé de l'élaboration des stocks dans les dépôts de l'intérieur et le chargé du dispatching commercial.

- Responsable adjoint de l'assurance du respect des procédures du service de distribution (CRASD): traite des vignettes, c'est-à-dire contrôler les factures de consommations des carburante par les entités de SEP, fait le suivi des sorties des clients de dépôts et de bases, c'est-à-dire il s'agit de toutes les sorties des produits pétroliers réaliser dans les dépôts pour le compte des sociétés commerciales, établi des commandes carburants pour le compte des entités, dépôts et bases de SEP, fait le suivi des consommations de dépôts.

- Le responsable du mouvement des produits (RMD) : émet les bons et établi les programmes dans un système de gestion de base des données (SGBD) appelés SUN.

a) Le chargé du dispatching commercial (CDC): fait l'établissement du dispatching qui découle du traitement des instructions.

b) Le chargé de suivi de traitement des instructions (CSI) : fait le suivi des établissements du dispatching.

c) Le chargé de l'élaboration des stocks dans les dépôts de l'intérieur (CES) : élabore des stocks par produit et par sociétés commerciales dans chaque province et fait la facturation des services demandés aux sociétés commerciales.

M F I T I G r a c e P a g e | 62

V.3.1.2. Identification des cas d'utilisation

Un cas d'utilisation est une fonctionnalité de système qui produit un résultat observable pour un utilisateur potentiel du système. Le cas d'utilisation regroupe une famille de scénario ou chaque scénario est un traitement particulier du système (²⁰).

Lors de notre analyse des besoins nous avons pu identifier les actions importantes que nous présenterons ci-dessous et nous les modélisons par la suite avec les diagrammes cas utilisation d'UML.

Les cas d'utilisations les plus importantes par acteurs sont :

Mémoire dirigé par Eric WANGI NGOY

(²⁰) SOUTOU C., Objet-Relationnel sous Oracle8, Modélisation avec UML, Eyrolles, Paris, 1999.

M F I T I G r a c e P a g e | 63

V.3.1.2. Identification des cas d'utilisation

Cas d'Utilisation	Acteur	Procédures
S'authentifier	Tous les utilisateurs	Pour accéder au système, l'utilisateur doit s'authentifier par la saisie de son mot de passe.
Gérer type produit	Le chargé d'élaboration des stocks	Tous les utilisateurs ayant le souci de connaître la situation des stocks de produits peuvent utilise la table créée par ce dernier.
Gérer fournisseur	Responsable de distribution	Le responsable de distribution gère les fournisseurs des produits accrédités par la SEP.
Gérer le stock	Le chargé d'élaboration des stocks	Il met à jour la situation des stocks des produits de la SEP
Gérer dépôt	Le responsable de distribution	Il veille sur base de rapport en sa possession à l'évolution des stocks dans le dépôt
Gérer mode livraison	Le chargé d'élaboration des stocks	Avant la livraison d'un produit, il vérifie les informations sur la situation des stocks
Gérer les factures	Le chargé d'élaboration des stocks	Avant que les produits soient livrés, il passe en revue toutes les étapes liées à cette vente avant l'élaboration des factures
Gérer les clients	Le chargé d'élaboration des stocks	Il connaît sur base des commandes à livrées le nombre des clients à servir.
Dispatching	Le chargé de suivi des instructions	Il veille à ce que toutes les actions à entreprendre puissent s'effectuer dans le respect des instructions
Gérer les commandes	Le responsable de mouvement de produits	Il veille sur base des données sur les produits, les commandes des clients
Impression	Tous les utilisateurs	Pour certaines informations nécessaire dans la distribution des produits, il est aussi permis à ces utilisateurs d'imprimer un document ou plusieurs
Consulter	Tous les utilisateurs	Consulter les différentes phases du circuit de distribution des produits

Mémoire dirigé par Eric WANGI NGOY

MFITI GracePage | 64

V.3.1.3. Diagramme de cas d'utilisation général

RDD

CSI

Gérer type produit Gérer le stock

Gérer produit

Gérer
fournisseur

Gérer dépôt

« include » « include »

« include »

« includ

« include »

« include »

« Include »

Gérer mode livraison

« Include »

S'authentifier

Gérer les Gé l

factures

Dispatching

« Include »

« Include

Gérer les commandes

Gérer les clients

CES

RMP

mpressionImpression ConsultationConsultati

Figure n°1 : Diagramme de cas d'utilisation

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 65

V.3.1.4 Affectation des priorités

Les cas d'utilisation peuvent être classés selon leur ordre d'importance pour chacun des acteurs. Ce classement donne lieu à la définition d'un ordre de priorité pour les cas d'utilisation.

Dans notre cas, les cas d'utilisation qui s'avèrent les plus prioritaires ont la priorité la plus forte « 1 » et les moins prioritaires ont la priorité « 2 ».

Nous avons considéré à haut priorité, tout cas d'utilisation qui sont faciles a développé vu la non maîtrise du langage de programmation.

Ceci est représenté dans le tableau ci-dessous :

Cas d'Utilisation	Acteurs	Priorité
Gérer type produit	Le responsable de distribution (RDD)	1
Gérer fournisseur	Le responsable de distribution (RDD)	1
Gérer stock	Le chargé d'élaboration des stocks (CES)	1
Gérer produit	Le chargé d'élaboration des stocks (CES)	1
Gérer dépôt	Le responsable de distribution (RDD)	1
Gérer mode livraison	Le chargé d'élaboration des stocks (CES)	1
Gérer facture	Le chargé d'élaboration des stocks (CES)	1
Gérer clients	Le chargé d'élaboration des stocks (CES)	1
Gérer dispatching	Le chargé de suivi de traitement des instructions (CSI)	1
Gérer commande	Le responsable de mouvement produit (RMP)	1
Consultation	Tous les utilisateurs	2
Impression	Tous les utilisateurs	2
S'authentifier	Tous les utilisateurs	2

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 66

V.4. RAFFINEMENT DES CAS UTILISATION PRIORITAIRE

Les cas d'utilisation les plus importants sont :

- Gérer type produit ;

- Gérer produit ;

- Gérer fournisseur ;

- Gérer dépôt ;

- Gérer les clients ;

- Gérer le stock ;

- Gérer mode livraison ;

- Dispatching ;

- Gérer les commandes ;

- Consultation ;

- Impression ;

- Gérer les factures ;

- S'authentifier.

V.4.1. Description textuelle de cas d'utilisation « Gérer type produit »

Nom cas
Pré- condition	Serveur ouvert et utilisateur authentifié
Post - condition
Scenario nominal	1. Démarrer le système 2. Saisir loging et mot de passe 3. Cliquer sur le bouton valider 4. Affichage du menu principal 5. Cliquer sur gérer type produit 6. Affichage de la fenêtre type produit 7. Saisir code produit et valider 8. Rechercher le produit et affichage du message 9. Saisir les autres informations 10. Valider l'opération (ajout, modification ou suppression) 11. Vérification des champs obligatoire 12. Message de confirmation
Exception	10 un message est affiché dans le cas d'échec de l'opération, dans ce cas le système vous renvoi à l'étape 9
Erreur	3 message d'erreur « login ou mot de passe » incorrect, le système vous renvoi à l'étape 9 11 champ obligatoire non rempli et le système vous renvoi à l'étape 9

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 67

Le principal objectif recherché, lorsqu'on détaille chaque cas d'utilisation est de décrire le flot d'événement qui le constitue en précisant les modalités de début et de fin ainsi que ses interactions avec les acteurs.

V.4.2. Analyse des cas d'utilisation prioritaires

Après avoir détaillé les cas d'utilisation, nous procédons par une analyse pour chaque cas, nous commencerons par présenter la traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse, ensuite nous présentons le diagramme de classe du modèle d'analyse et enfin le diagramme de collaboration de ces cas.

a) Analyse du Cas d'Utilisation « S'authentifier »

Le cas d'utilisation « S'authentifier » correspond dans le modèle d'analyse aux classes d'analyse suivante :

- La classe de dialogue « : Interface_utilisateurs ", désignée par le stéréotype « boundary ", qui permet à l'utilisateur d'interagir avec le système.

- La classe entité « : users ", désignée par le stéréotype « entity ", qui sert à modéliser les informations de longue durée et souvent de nature persistante.

- La classe contrôle « : gestionnaire_authentification ", désignée par le stéréotype « control ", qui se charge de contrôler les données saisies par l'utilisateur. La classe contrôle joue le rôle de coordinateur entre la classe interface el la classe entité.

MFITI GracePage | 68

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation « S'authentifier ».

« Participate »

Users

InterfaceUtilisateurs

« Trace »

« Participate »

S'Authentifier

« Participate »

S'Authentifier

Utilisateur

GestionnaireAuthentification

Figure n°2 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation « S'authentifier ».

La traçabilité ente le modèle de cas d'utilisation et le modèle d'analyse met en relation deux livrables de deux jalons différents du cycle de vie du projet. C'est un moyen qui favorise le passage immédiat d'une phase à une autre du processus unifié.

2- Diagramme de classes des modèles d'analyse pour les cas d'utilisation « s'authentifier »

Users

Utilisateur Interface_Utilisateurs Gestionnaire_Authentification

Figure n°3 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « s'authentifier »

Le diagramme de classes d'analyse effectue la jonction entre, d'une part, les cas d'utilisation, et d'autre part, les diagrammes de conception logicielle que sont les diagrammes d'interaction (diagramme de séquence d'analyse dans notre cas).

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 69

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « s'authentifier »

Users

Gestion_ Authentification

1. Afficher_interface authentification

3 : Saisie (login, mot de passe)

2 : Interface_Authentification_Affiché

8 : message visualisé

7. Afficher message résultat

Utilisateur

6 : Résultat

5. Recherche (login, mot de passe)

Interface Authentification

4. Envoyer (login, mot de passe)

Figure n°4 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « s'authentifier »

Pour accéder au système, tous les utilisateurs doivent valider leurs authentifications. L'utilisateur tape ses paramètres de connexion (login et mot de passe), ces paramètres vont être envoyée au gestionnaire, après avoir recherché ces derniers dans la base et vérifiés leurs validités. En cas de succès, la page d'accueil est renvoyée selon les droits d'accès. Un message d'erreur est renvoyé le cas échéant.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 70

b) Analyse du cas d'utilisation « Gérer Type Produit »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation « Gérer Type Produit »

InterfaceType produit

Utilisateur

: Type produit

« Trace » Gérer type produit

Gérer Type produit

Gestionnaire__Type produit

Figure n°5 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation « Gérer Type Produit »

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer Type Produit »

Interface Type Produit

Utilisateur

:Type Produit Gestionnaire_Type Produit

Figure n°6 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer Type Produit »

Mémoire dirigé par Eric WANGI NGOY

MFITI GracePage | 71

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Type Produit »

1 :Afficher_interface_Type Produit 2 : Interface_Type Produit_affiche

: Type Produit

3 : Saisit (code Type)

9 : Saisit autres données

Utilisateur

8 : Message visualisé (existe ou n'existe pas)

7 : Affiche_message résultat

6: Résultat

Interface_Type produit

4 :4 : EnvoyerEnvoye (Code(Code Type)Typ

10 : Envoie requête

Gestionnaire_ Type Produit

5 : Recherche (Code Type)

11: Mise_à_jour)

Figure n°7 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Type Produit »

Commentaire :

L'utilisateur demande la visualisation de l'interface_Type Produit. L'interface affichée lui permettra de saisir le code type pour lancer la recherche dans l'entité Type Produit. A la fin, un résultant doit être retourné à l'utilisateur. Soit ce type produit existe déjà, soit il n'existe pas.

L'utilisateur doit ensuite saisir les autres données puis cliquer sur un bouton. Une requête doit être envoyée à l'entité Type Produit selon qu'il s'agit d'une requête et ajout, modification ou de suppression,

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 72

pour que la mise à jour s'est déclenche. Un message signalant le déroulement ou de l'opération est visualisée sur le poste de cet agent.

c) Analyse du cas d'utilisation « Gérer Produit »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse

Gérer Produit

Gérer Produit

« Trace »

Gestionnaire_ Produit Interface Produit

Utilisateur

Produit Type Produit

Figure n°8 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse cas d'utilisation « Gérer Produit »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 73

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisateur « Gérer Produit »

Interface Produit

Gestionnaire_Produit

: Type Produit

: Produit

Figure n°9 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer Produit »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 74

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Produit »

7: Recherche (Code Type)

5: Recherche (code Produit) 12: mise_à_jour

6: Résultat

: Produit

: Type Produit

1 : Affiche_Interface_Produit

2 : Interface_Produit affiche

3 : Saisit (code produit)

3 : Saisit autres données

Utilisateur

8: Message visualisé (Existe ou n'existe pas)

7: Affiche_message résultat

Interface Produit

4 : Envoyer (code Produit) 10 : Envoie Requête

Gestionnaire_Produit

Figure n°10 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Produit »

Commentaire :

Pour faire la mise à jour d'un produit, l'utilisateur demande la visualisation de l'interface Produit, puis saisit le Code produit. Le système effectue la recherche pour savoir si c'est produit existe déjà ou pas. A la fin de la recherche un message sera envoyé à l'interface si c'est produit existe ou pas. Ensuite, l'utilisateur doit saisir les autres données puis cliquer un bouton. Une requête doit être envoyé à l'entité Type Produit pour la

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 75

vérification du Code Type saisit puis une requête de mise à jour (ajout ou modification ou encore suppression) sera envoyée à l'entité Produit. Un message signalant le déroulement de l'opération est visualisé sur le poste de cet agent.

d) Analyse du cas d'utilisation « Gérer Fournisseur »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse

Gérer Fournisseur

Utilisateur

Gérer Fournisseur

« Trace »

Gestionnaire_ Fournisseur Interface Fournisseur

: Fournisseur

Figure n°11 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation « Gérer Fournisseur »

M F I T I G r a c e P a g e | 76

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer Fournisseur »

: Fournisseur

Gestionnaire Fournisseur

: Utilisateur

Figure n°12 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer Fournisseur »

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Fournisseur »

		1 : Affiche_Interface_Fournisseur			2 : Interface_Fournisseur_Affiché
			3 :Saisit (code fournisseur)			Interface Fournisseur

: Utilisateur

9 : Saisit autres données

8 : Message visualisé (existe ou n'existe pas)

7 : Afficher_message_résultat

4 : Envoyer (code fournisseur) 10 : Envoie requête

			6 : Résultat
: Fournisseur				5 : Recherche (Code fournisseur) ^11 eà 11 : mise_à_jour ()			Gestionnaire_Fournisseur

Figure n°13 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Fournisseur »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 77

Commentaire :

Pour faire la mise à jour d'un fournisseur, l'utilisateur demande la visualisation de l'interface Fournisseur, puis saisit le Code de Fournisseur .Le système doit effectuer la recherche pour savoir si fournisseur existe déjà ou pas. A la fin de la recherche un message sera envoyé à l'interface si c'est fournisseur existe ou pas. Ensuite, l'utilisateur doit saisir les autres données puis cliquer un bouton. Puis une requête de mise à jour (ajout ou modification ou encore suppression) sera envoyée à l'entité fournisseur. Un message signalant le déroulement de l'opération est visualisé sur le poste de cet agent.

e) Analyse du cas d'utilisation « Gérer dépôt »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse

« Trace »

Utilisateur

Gérer Dépôt

Gestionnaire_ Dépôt Interface Dépôt

: Dépôt

Figure n°14 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation « Gérer Dépôt »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 78

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer Dépôt »

Interface Dépôt

: Utilisateur

GestionnaireDépôt

: Dépôt

Figure n°15 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer Dépôt »

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Dépôt »

Interface Dépôt

6 : Résultat

: Dépôt

Gestionnaire_Dépôt

5 : Recherche (Code Dépôt) 11 : mise_à_jour ()

1 : Affiche_Interface_Dépôt

2 : Interface_Dépôt_Affiché

: Utilisateur

9 : Saisit autres données

8 : Message visualisé (existe ou n'existe pas)

7 : Afficher_message_résultat

4 : Envoyer (code dépôt)

10 : Envoie requête

3 :Saisit (Code Dépôt)

Figure n°16 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Dépôt »

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 79

Commentaire :

Pour mettre à jour le dépôt, l'utilisateur demande la visualisation de l'interface dépôt, puis saisit le Code dépôt. Le système effectue la recherche pour savoir si le dépôt existe déjà ou pas. A la fin de la recherche un message sera envoyé à l'interface si c'est dépôt existe ou pas. Ensuite, l'utilisateur doit saisir les autres données puis cliquer un bouton puis une requête de mise à jour (ajout ou modification ou encore suppression) sera envoyée à l'entité dépôt. Un message signalant le déroulement de l'opération est visualisé sur le poste de cet agent.

f) Analyse du cas d'utilisation « Gérer stock »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse

Utilisateur

: stock

: Dépôt

: Fournisseur

Gérer stock

: Produit Gestionnaire_ stock Interface stock

« Trace »

Figure n°17 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation « Gérer stock »

M F I T I G r a c e P a g e | 80

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer stock »

Interface

Gestionnaire_ stock

: Produit

: Dépôt

: Fournisseur

Utilisateur

: stock

Figure n°18 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer stock »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 81

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer stock »

Gestionnaire_Stock

12 : mise_à_jour ()

1 : Affiche_Interface_Stock

2 : Interface_Stock_Affiché

5 : Recherche
(code
fournisseur)

Interface stock

: Utilisateur

9 : Message visualisé

4 : Envoyer (code fournisseur ou code produit)

8 : Afficher_message_résultat

7 : Recherche (code produit)

11 : Envoie requête

: Dépôt

: Fournisseur

: Stock

3 :Saisit (Code produit)

: Produit

6 : Recherche (code dépôt)

10 : Saisit autres données

Figure n°19 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer stock »

Commentaire :

Pour mettre à jour le stock, l'utilisateur demande la visualisation de l'interface stock, puis saisit le Code Produit, Code dépôt et Code fournisseur. Le système doit effectuer la recherche pour savoir si les codes saisis existent réellement. A la fin de la recherche un message sera

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 82

envoyé à l'interface si une des codes saisis n'est pas dans la base de données. Ensuite, l'utilisateur doit saisir les autres données puis cliquer un bouton. Puis une requête de mise à jour (ajout ou modification ou encore suppression) sera envoyée à l'entité stock. Un message signalant le déroulement de l'opération est visualisé sur le poste de cet agent.

g) Analyse du cas d'utilisation « Gérer clients »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse

« Trace »

Utilisateur

Gérer clients

GestionnaireClients Interface Clients

:Clients

Figure n°20 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation « Gérer Clients »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 83

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisation « gérer clients »

: Client

GestionnaireClient

Interface Clients

: Utilisateur

Figure 21 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer Clients »

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer clients »

			1 : Affiche_Interface_Clients			2 : Interface_Clients_Affiché
				3 : Saisit (Code Clients)				Interface Client

: Utilisateur

9 : Saisit autres données

8 : Message visualisé

7 : Afficher_message_résultat

4 : Envoyer (code client) 10 : Envoie requête

			6 : Résultat
: Client				5 : Recherche (Code Client) 11 : mise_à_jour ()			Gestionnaire_Client

Figure n°22 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Clients »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 84

Commentaire :

Pour mettre à jour le client, l'utilisateur demande la visualisation de l'interface client, puis saisit le Code client. Le système effectue la recherche pour savoir si le client existe déjà ou pas. A la fin de la recherche un message sera envoyé à l'interface si c'est client existe ou pas. Ensuite, l'utilisateur doit saisir les autres données puis cliquer un bouton. Puis une requête de mise à jour (ajout ou modification ou encore suppression) sera envoyée à l'entité client. Un message signalant le déroulement de l'opération est visualisé sur le poste de cet agent.

H. Analyse du cas d'utilisation « Gérer Mode livraison »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse

« Trace »

Gérer Mode Livraison

Utilisateur

Gestionnaire_Mode Livraison Interface_ModeLivraison

Mode Livraison

Figure n°23 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation « Gérer Mode Livraison »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 85

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer Mode Livraison »

Interface Mode Livraison

: Mode Livraison GestionnaireMode Livraison

: Utilisateur

Figure n°24 : Diagramme de classe du modèle d'analyse pour le cas d'utilisation « Gérer Mode Livraison »

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Mode Livraison »

6 : Résultat

: ModeLivraison

Gestionnaire_ModeLivraion

5 : Recherche (Code Livraison) 11 : mise_à_jour ()

1 : Affiche_Interface_ModeLivraison

F F

2 : Interface_ModeLivraison_Affiché

F F

8 : Message visualisé

7 : Afficher_message_résultat

Interface ModeLivraison

4 : Envoyer (code Livraison)

10 : Envoie requête

: Utilisateur

3 : Saisit (Code Livraison)

9 : Saisit autres données

Figure n°25 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer Mode Livraison »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 86

Commentaire :

Pour mettre à jour le programme de livraison, l'utilisateur demande la visualisation de l'interface livraison, puis saisit le Code livraison. Le système doit effectuer la recherche pour savoir si la livraison existe déjà ou pas. A la fin de la recherche un message sera envoyé à l'interface si cette livraison existe ou pas. Ensuite, l'utilisateur doit saisir les autres données puis cliquer un bouton. Puis une requête de mise à jour (ajout ou modification ou encore suppression) sera envoyée à l'entité Mode Livraison. Un message signalant le déroulement de l'opération est visualisé sur le poste de cet agent.

h) Analyse du cas d'utilisation « Dispatching »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse

« Trace »

Utilisateur

Dispatching

Gestionnaire_Dispatching Interface_Dispatching

Dispatching

Figure n°26 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse « Dispatching »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 87

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Dispatching »

Utilisateur

Interface

Gestionnaire_ Dispatching

: Produit

: Dépôt

: Fournisseur

: Dispatching

Figure n°27 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Dispatching »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 88

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Dispatching »

Gestionnaire_Dispatching

12 : mise_à_jour ()

1 : Affiche_Interface_Dispatching

2 : Interface_Dispatching_Affiché

3 :Saisit (Code produit)

5 : Recherche
(code
fournisseur)

Interface Dispatching

: Utilisateur

9 : Message visualisé

4 : Envoyer (code produit)

8 : Afficher_message_résultat

7 : Recherche (code produit)

11 : Envoie requête

: Dépôt

: Fournisseur

Dispatching

: Produit

6 : Recherche (code dépôt)

10 : Saisit autres données

Figure n°28 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Dispatching »

Commentaire :

Pour mettre à jour le dispatching, l'utilisateur demande la visualisation de l'interface dispatching, puis saisit le Code dispatching. Le système doit effectuer la recherche pour savoir si le dispatching existe déjà ou pas. A la fin de la recherche un message sera envoyé à l'interface si ce

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 89

dispatching existe ou pas. Ensuite, l'utilisateur doit saisir les autres données puis cliquer un bouton. Une requête doit être envoyé à l'entité Produit pour la vérification du Code Produit, une autre à l'entité dépôt pour la vérification de code dépôt et enfin un autre à l'entité fournisseur, pour la vérification du code fournisseur. Puis une requête de mise à jour (ajout ou modification ou encore suppression) sera envoyée à l'entité dispatching. Un message signalant le déroulement ou non de l'opération est visualisé sur le poste de cet agent.

i) Analyse du cas d'utilisation «Gérer les commandes »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse

« Trace »

Gérer les commandes

Utilisateur

Gestionnaire_Commandes Interface_Commandes

Commandes

Figure n°28 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse « Gérer les commandes »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 90

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer les commandes »

Utilisateur

Interface

: Produit

: Dépôt

: Fournisseur

Gestionnaire_ Commandes

: Commandes

Figure n°29 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Gérer les commandes »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 91

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation «Gérer les commande »

Interface Commandes

1 : Affiche_Interface_Commandes

3 :Saisit (Code produit)

2 : Interface_Commandes_Affiché

: Utilisateur

9 : Message visualisé

4 : Envoyer (code produit)

: Produit

6 : Recherche (code dépôt)

8 : Afficher_message_résultat

7 : Recherche (code produit)

11 : Envoie requête

Gestionnaire_Commandes

12 : mise_à_jour ()

: Dépôt

: Fournisseur

Commandes

5 : Recherche
(code
fournisseur)

10 : Saisit autres données

Figure n°30 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation « Gérer les commandes »

Commentaire :

Pour mettre à jour la commande, l'utilisateur demande la visualisation de l'interface commande, puis saisit le Code commande. Le système doit effectuer la recherche pour savoir si la commande existe déjà ou pas. A la fin de la recherche un message sera envoyé à l'interface si cette

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 92

commande existe. Ensuite, l'utilisateur doit saisir les autres données puis cliquer un bouton. Une requête doit être envoyée à l'entité Type Produit pour la vérification du Code Produit. De même pour l'entité dépôt et fournisseur. Puis une requête de mise à jour (ajout ou modification ou encore suppression) sera envoyée à l'entité commande. Un message signalant le déroulement ou non de l'opération est visualisé sur le poste de cet agent.

j) Analyse du cas d'utilisation « Facturation »

1- Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse

Facturation

Gérer Facture

Facture

commande

« Trace »

Utilisateur

Interface Facturation

Gestionnaire_ Facture

Figure n°31 : Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse « Facturation »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 93

2- Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Facturation »

Gestionnaire_Facture

Utilisateur

Interface Facturation

Commande

: Facturation

Figure 32 : Diagramme de classes du modèle d'analyse pour le cas d'utilisation « Facturation »

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 94

3- Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation «Facturation»

7: Recherche (Refcom)

5: Recherche (code Facture) 12: mise_à_jour

6: Résultat

: Facture

Commande

2 : Interface_Facture_affiche

1 : Affiche_Interface_Facture

8: Message visualisé

7: Affiche_message résultat

Interface Facture

4 : Envoyer (code Facture) 10 : Envoie Requête

Utilisateur

3 : Saisit (code Facture)

3 : Saisit autres données

Gestionnaire_Facture

Figure 33 : Diagramme de collaboration du modèle d'analyse pour le cas d'utilisation «Facturation»

Commentaire :

Pour mettre à jour la facturation, l'utilisateur demande la visualisation de l'interface facturation, puis saisit le Code facture. Le système doit effectuer la recherche pour savoir si la facture existe déjà ou pas. Ensuite, l'utilisateur doit saisir les autres données puis cliquer un bouton. Puis une requête de mise à jour (ajout ou modification ou encore

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 95

suppression) sera envoyée à l'entité facture. Un message signalant le déroulement de l'opération est visualisé sur le poste de cet agent.

I.5. Diagramme de séquences

A cette étape, nous allons présenter nos diagrammes de séquences qui montrent les échanges de messages entre les différents objets du système.

Pour des raisons du temps, nous allons réalisés uniquement les séquences de cas d'utilisation à haut priorité.

a) Diagramme de séquence pour cas d'utilisation « Gérer Type Produit »

Utilisateur

Form

Authentification

Form

Type Produit

T : Users

Form

Menu principal

T : Type Produit

3 : Accepté

1 :s'authentifier

2 : Rechercher (login ou mot de passe)

4 : Résultat

8 : Saisie (Code Type Produit)

11 : Saisie autres données

5 : Affichage du formulaire

6 : Choix Type Produit

7 : Changement

13 : Message de confirmation

9 : Recherche (Code Type Produit)

10 : Résultat

12 : Mise à jour (ajout, modification, suppression)

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 96

Figure 34 : Diagramme de séquence pour le cas « Gérer Produit » Commentaire :

Après s'authentifier, l'utilisateur fait le choix du Type Produit dans le menu principal, puis le système lance le chargement du formulaire, type produit. Dès que le formulaire est chargé, l'utilisateur saisi le code Type après cela, le système lance la recherche code type dans la table TypeProduit, après le système renvoi le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi les autres données et le valide, après la mise à jour qui est de deux types soit la modification ou la suppression (est enfin, il y a un message de confirmation). S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

M F I T I G r a c e P a g e | 97

b) Diagramme de séquence pour « Gérer Produit »

Form

Authentification

Form

Menu principal

Form

Produit

T : Users

Utilisateur

1 :s'authentifier

3 : Résultat

4 : Accepté

5 : Choix Produit

6 : Changement

9 : Résultat

12 : Mise à jour

8 : Recherche

(Code Produit)

11 : Recherche (Code Type)

Produit

7 : Saisie (Code Produit)

10 : Saisie autres données

13 : Message de confirmation

4 : Affichage du formulaire

2 : Rechercher (login ou mot de passe)

Type
Produit

Figure 35 : Diagramme de séquence pour le cas « Gérer Produit »

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 98

Commentaire :

Après s'authentifier, l'utilisateur fait le choix du produit dans le menu principal, puis le système lance le chargement du formulaire produit. Dès que le formulaire est chargé, l'utilisateur saisi le code produit après cela, le système lance la recherche code produit dans la table Produit, après le système renvoie le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi les autres données et le valide, après la mise à jour qui est de deux types soit la modification ou la suppression (est enfin, il y a un message de confirmation). S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

M F I T I G r a c e P a g e | 99

c) Diagramme de séquence pour « Gérer Fournisseur »

Utilisateur

Form

Authentification

Form

Fournisseur

T : Users

Form

Menu principal

T : Fournisseur

3 : Accepté

8 : Saisie (Code fournisseur)

1 :s'authentifier

11 : Saisie autres données

13 : Message de confirmation

5 : Affichage du formulaire

6 : Choix fournisseur

2 : Rechercher (login ou mot de passe)

4 : Résultat

7 : Changement

12 : Mise à jour (ajout, modification, suppression)

10 : Résultat

9 : Recherche (Code

fournisseur)

Commentaire :

Après s'authentifier, l'utilisateur fait le choix du fournisseur dans le menu principal, puis le système lance le chargement du formulaire fournisseur. Dès que le formulaire est chargé, l'utilisateur saisi le code fournisseur après cela, le système lance la recherche code fournisseur dans la table fournisseur, après le système renvoi le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 100

les autres données et le valide, après la mise à jour qui est de deux types soit la modification ou la suppression (est enfin, il y a un message de confirmation). S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

d) Diagramme de séquence pour « Gérer Dépôt »

Utilisateur

Form

Authentification

Form

Dépôt

T : Users

Form

Menu principal

T : Dépôt

1 :s'authentifier

3 : Accepté

2 : Rechercher (login ou mot de passe)

4 : Résultat

5 : Affichage du formulaire

6 : Choix dépôt

7 : Changement

8 : Saisie (Code dépôt)

11 : Saisie autres données

13 : Message de confirmation

9 : Recherche (Code dépôt)

10 : Résultat

12 : Mise à jour (ajout, modification, suppression)

Commentaire :

Après s'authentifier, l'utilisateur fait le choix du dépôt dans le menu principal, puis le système lance le chargement du formulaire

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 101

dépôt. Dès que le formulaire est chargé, l'utilisateur saisi le code dépôt après cela, le système lance la recherche code dépôt dans la table dépôt, après le système renvoi le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi les autres données et le valide, après la mise à jour qui est de deux types soit la modification ou la suppression (est enfin, il y a un message de confirmation). S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

M F I T I G r a c e P a g e | 102

e) Diagramme de séquence pour « Gérer les clients »

Utilisateur

Form

Authentification

Form
Clients

T : Users

Form

Menu principal

T : Client

2 : Rechercher (login ou mot de passe)

4 : Résultat

1 :s'authentifier

3 : Accepté

5 : Affichage du formulaire

6 : Choix client

7 : Changement

8 : Saisie (Code client)

9 : Recherche (Code client)

11 : Saisie autres données

10 : Résultat

13 : Message de confirmation

12 : Mise à jour (ajout, modification, suppression)

Commentaire :

Après s'authentifier, l'utilisateur fait le choix du client dans le menu principal, puis le système lance le chargement du formulaire client. Dès que le formulaire est chargé, l'utilisateur saisi le code client après cela, le système lance la recherche code client dans la table client, après le système renvoi le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi les autres données et le valide, après la mise à jour qui est de deux types soit la modification ou la

Mémoire dirigé par Eric WANGI NGOY

Stock

T : Users

M F I T I G r a c e P a g e | 103

suppression (est enfin, il y a un message de confirmation. S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

f) Diagramme de séquence pour « Gérer le stock »

Form
Produit

Form
Dépôt

Form
Fournisseur

Utilisateur

1 :s'authentifier 4 : Accepté

2 : Rechercher (login ou mot de passe)

3 : Résultat

11 : Recherche
(Code dépôt)

12 : Mise à jour

8 : Recherche

(Code Produit)

9 : Résultat

7 : Saisie (Code fournisseur, Code dépôt)

10 : Saisie autres données

6 : Changement

4 : Affichage du formulaire

5 : Choix stock

13 : Message de confirmation

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 104

Commentaire :

Après s'authentifier, l'utilisateur fait le choix du stock dans le menu principal, puis le système lance le chargement du formulaire stock. Dès que le formulaire est chargé, l'utilisateur saisi le code produit, code fournisseur et le code dépôt après cela, le système passe à la vérification des codes saisis, après le système renvoi le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi les autres données et le valide, après la mise à jour qui est de deux types soit la modification ou la suppression (est enfin, il y a un message de confirmation). S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

M F I T I G r a c e P a g e | 105

g) Diagramme de séquence pour « Gérer le mode livraison »

Form

Authentification

Form

Menu principal

Form

Livraison

T : Users

Utilisateur			T : Livraison
1 :s'authentifier	2 : Rechercher (login ou mot de passe)

4 : Résultat

3 : Accepté

8 : Saisie (Code client)

11 : Saisie autres données

5 : Affichage du formulaire

6 : Choix de la livraison

7 : Changement

13 : Message de confirmation

12 : Mise à jour (ajout, modification, suppression)

10 : Résultat

9 : Recherche (Code client)

Commentaire :

Après s'authentifier, l'utilisateur fait le choix de la livraison dans le menu principal, puis le système lance le chargement du programme de livraison. Dès que le programme est chargé, l'utilisateur saisi le code client après cela, le système lance la recherche code client dans la table livraison, après le système renvoi le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi les autres données et le valide, après la mise à jour qui est de deux types soit la

Mémoire dirigé par Eric WANGI NGOY

T : Users

M F I T I G r a c e P a g e | 106

modification ou la suppression (est enfin, il y a un message de confirmation). S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

h) Diagramme de séquence pour « Dispatching »

Form

Authentification

Form

Menu principal

Form

Dispatching

Utilisateur

3 : Accepté

1 :s'authentifier

T : Dispatching

2 : Rechercher (login ou mot de passe)

4 : Résultat

5 : Affichage du formulaire

6 : Choix dispatching

7 : Changement

8 : Saisie (Code dispatching)

11 : Saisie autres données

13 : Message de confirmation

9 : Recherche (Code

dispatching)

10 : Résultat

12 : Mise à jour (ajout, modification, suppression)

Commentaire :

Après s'authentifier, l'utilisateur fait le choix du dispatching dans le menu principal, puis le système lance le chargement du dispatching. Dès que le programme est chargé, l'utilisateur saisi le code

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 107

dispatching après cela, le système lance la recherche code dispatching dans la table dispatching, après le système renvoi le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi les autres données et le valide, après la mise à jour qui est de deux types soit la modification ou la suppression (est enfin, il y a un message de confirmation). S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

M F I T I G r a c e P a g e | 108

i) Diagramme de séquence pour « Gérer les commandes »

	Form Authentification	Form Menu principal	Form Commandes	T : Users

Utilisateur

3 : Accepté

8 : Saisie (Code commandes)

1 :s'authentifier

11 : Saisie autres données

13 : Message de confirmation

5 : Affichage du formulaire

6 : Choix commandes

2 : Rechercher (login ou mot de passe)

4 : Résultat

7 : Changement

12 : Mise à jour (ajout, modification, suppression)

10 : Résultat

9 : Recherche (Code

commandes)

T : Commandes

Commentaire :

Après s'authentifier, l'utilisateur fait le choix de la commande dans le menu principal, puis le système lance le chargement de la commande. Dès que le programme est chargé, l'utilisateur saisi le code de commande après cela, le système lance la recherche code commande dans la table commande, après le système renvoi le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi les autres données et le valide, après la mise à jour qui est de deux

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 109

types soit la modification ou la suppression (est enfin, il y a un message de confirmation). S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

j) Diagramme de séquence pour « Authentification »

Utilisateur

3 : Accepté

1 :s'authentifier

Form

Authentification

2 : Rechercher (login ou mot de passe)

4 : Résultat

Form

Menu principal

T : Users

Commentaire :

Pour accéder au système, l'utilisateur doit s'authentifier en saisissant son login et mot de passe. Ensuite, le système passe à l'authentification des informations saisies si l'utilisateur est reconnu, alors le système charge le menu principal. S'il n'est pas reconnu, un message doit être renvoyé.

M F I T I G r a c e P a g e | 110

k) Diagramme de séquence pour « Facturation »

Form

Authentification

Form

Menu principal

Form

Facturation

T : Users

T : Facturation

Utilisateur

1 :s'authentifier

2 : Rechercher (login ou mot de passe)

3 : Accepté

4 : Résultat

8 : Saisie (Code facture)

11 : Saisie autres données

13 : Message de confirmation

5 : Affichage du formulaire

6 : Choix de la facture

7 : Changement

9 : Recherche (Code

facture)

10 : Résultat

12 : Mise à jour (ajout, modification, suppression)

Commentaire :

Après s'authentifier, l'utilisateur fait le choix de la facture dans le menu principal, puis le système lance le chargement de la facture. Dès que le programme est chargé, l'utilisateur saisi le code de la facture après cela, le système lance la recherche code facture dans la table facturation, après le système renvoi le résultat. Ce résultat est de deux types soit il existe déjà ou il n'existe pas. S'il existe, l'utilisateur saisi les autres données et le valide, après la mise à jour qui est de deux types soit la

Mémoire dirigé par Eric WANGI NGOY

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 111

modification ou la suppression (est enfin, il y a un message de confirmation). S'il n'existe pas, alors la mise à jour consistera à l'ajout d'une nouvelle donnée. Dans l'une ou l'autre cas le système doit envoyer un message de confirmation.

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 112

La réalisation d'un programme est l'objectif capital de notre travail qui s'oriente vers l'informatique de gestion, cela a été prouvé par les besoins ressentis au cours de l'Analyse de la gestion du circuit de distribution de la SEP.

La matérialisation du nouveau système par l'analyse organique prépare l'analyse d'un programme en facilitant la compréhension du langage par l'ordinateur afin d'obtenir les résultats voulus.

VI.1. ENVIRONNEMENT MATERIEL

L'implémentation du nouveau système d'information s'avère obligatoire de prendre des ressources informatiques. Vu cette évidence, notre application sera pris en charge par un ordinateur. Le matériel informatique est l'ensemble des pièces détaches des appareils informatique. En vue développement de système, nous proposons les matériel suivants :

1°) Aspect Hardware

Celui-ci n'est rien d'autre que l'ensemble des matériels, physiques, palpables constituant l'ordinxateur outre les matériels présentés dans l'existant qui servent aux travaux bureautique, nous proposons m'acquisition d'une nouvelle configuration dont les caractéristiques techniques ci-après :

- Micro-ordinateur ;

- Processeur : coreDuo ;

- Vitesse : 3 GHz ;

- Disque dure : 500 GO ;

- Mémoire RAM : 2GO ;

- Lecteur DVD Rewrite table ;

- Clavier AZERTY ;

- Port USB ;

- Port parallèle ;

- Port serie ;

- Ecrans plat `'17» ;

- Carte son ;

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 113

- Carte réseau internet ;

- Sourie optique ;

- Imprimante : HP Laserjet 2015P ; - Onduleur 1500 VA

2°) Aspect Software

C'est une partie immatérielle ou intelligente de l'ordinateur, c'est-à-dire ce qu'on ne peut pas voir, ni toucher :

- système exploitation Windows XP

- MS office 2013

- Logiciel d'antivirus : Microsoft Essential Security - Plate-forme de développement : java

V.2. CHOIX DES OUTILS DE DEVELOPPEMENT ET DU SGBD

V.2.1. Langage de programmation

Le langage de programmation est un ensemble des moyens (symboles, mots, conventions), utilisés pour décrire sous la forme d'un programme, les opérations demandées à un ordinateur. Tout langage se caractérise par sa sémantique (étude des mots considérés dans leur signification) et par sa syntaxe (étude de la fonction et de la disposition des mots dans la phrase).

V.2.1.1. Choix du langage de programmation

La programmation adoptée dépend souvent du type d'application que l'on souhaite développer, ce choix prenant en compte, suivant les cas, des critères de rapidité, de facilité de traitement du graphisme ou de calcul, etc. Il existe de nombreux types de programmation couramment employés, parmi lesquels on peut mentionner les programmations ascendante, descendante, linéaire, logique, modulaire, structurée et orientée objet.

Notre choix s'est porté sur le langage de programmation JAVA. C'est un langage permettant de créer des applications et des Applets.

Il possède des avantages par rapport aux autres langages de programmation, nous pouvons cités :

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 114

- Le Java est neutre d'architecture, c'est-à-dire, il ne tient pas compte des processeurs de la machine ;

- Il permet de créer des applications qui peuvent être exécuté sur le net ;

- Le programme Java communique avec n'importe quel SGBD (Access, Paradoxe, ORACLE...) ;

- Il permet de créer des applications qui peuvent se communiquer à distance et les deux applications peuvent être écrites avec des langages différents : Java par exemple pour le client, et Visual Dbase pour le serveur.

V.2.TI.2. Présentation de l'environnement

V.2.2. SGBD

Le SGBD (système de gestion de base de données) est un écran qui joue le rôle d'interface entre l'homme (utilisateur) et la machine. Il est considéré comme un outil permettant d'insérer, de modifier et de chercher efficacement des données spécifiques dans une grande masse d'informations partagées par tous les utilisateurs.

V.2.2.1. Choix du Système de Gestion de la Base de Données

Nous avons opté notre choix pour l'utilisation de SQL

serveur.

V.2.2.2. Présentation de l'environnement

Microsoft SQL Server est un système de gestion de base de données (abrégé en SGBD ou SGBDR pour « Système de gestion de base de données relationnelles ») développé et commercialisé par la société Microsoft.

SQL Server est un SGBD relationnel. Il est possible de définir des relations entre les tables de façon à garantir fortement l'intégrité des données qui y sont stockées. Ces relations peuvent être utilisées pour modifier ou supprimer en chaîne des enregistrements liés.

V.2.2.3. Modèle relationnel

Le modèle relationnel est basé sur une organisation des données sous forme de tables. La modélisation relationnelle permet de représenter les relations à l'aide de tables (à deux dimensions) dont chaque

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 115

colonne a un identificateur qui représente un domaine. Une ligne du tableau représente donc une entité et chacune des cases représente un de ses attributs.

1- Règle de passage du modèle de classe en modèle relationnel

- Les classes deviennent des tables ;

- Les attributs de la classe deviennent les attributs de la table et la méthode de la classe disparaît ;

- Si la classe possède un identifiant celui-ci devient la clé primaire de la table ;

- Cas de relation un vers plusieurs : la classe ayant la multiplicité un envoie sa clé vers l'autre classe et devient la clé étranger ;

- Cas de relation plusieurs vers plusieurs : cette relation créée une nouvelle classe appelée ci-haut une classe d'association qui hérite des clés provenant de classe participante a cette relation ;

- Décomposition par distinction, il faut transformer chaque sous-classe en une relation. La clé de la super-classe migre dans la (les) relation(s) de la (des) sous-classe(s) et devient à la fois clé étrangère ;

- Décomposition descendante, deux cas sont possibles ; s'il existe une contrainte de totalité ou de partition sur l'association, il est possible de ne pas traduire la relation issue de la surper-classe. Il faut alors faire migrer tous les attributs dans la (les) relation(s) de la (des) sous-classes. Dans le cas contraire, il faut faire migrer tous les attributs dans la (les) relation(s) issues de la (des) sous-classes.

M F I T I G r a c e P a g e | 116

2- Présentation du modèle relationnel

Nom table	Champ	Type	Taille	Contrainte
Produit	Codepro	Varchar	10	Primary key
	Designapro	Varchar	10	Not null
	Typespro	Varchar	15	Not null
	Prixunit	Varchar	10,2	Not null
	Quantistock	Varchar	10,2	Not null
Fournisseur	Codefournis	Varchar	10	Primary key
	Nomfournis	Varchar	15	Not null
	Téléphonefourn	Varchar	15
	Paysfourn	Varchar	15	Not null
Type produit	Codetype	Varchar	10	Primary key
	Libeltype	Varchar	10	Not null
Dépôt	Codep	Varchar	10	Primary key
	Libedep	Varchar	15	Not null
Client	Codecli	Varchar	10	Primary key
	Nomcli	Varchar	15	Not null
	Adrcli	Varchar	20	Not null
	Télephocli	Varchar	15
Mode livraison	Codeliv	Varchar	10	Primary key
	Libeliv	Varchar	15	Not null
Commande	Refcom	Varchar	10	Primary key
	Codecli	Varchar	10	Not null
	Codeliv	Varchar	10	Not null
	Datecom	Varchar	8	Not null
	Delait	Varchar	15	Not null
	Lieuliv	Varchar	20	Not null
	stacom	Varchar	15	Not null
Souscription	Noumsous	Varchar	10	Primary key
	Codepro	Varchar	10	Not null
	Refcom	Varchar	10	Not null
	Avant	Varchar	10,2	Not null
	prixto	Varchar	10,2	Not null
Stock	Codstock	Varchar	10	Primary key
	Codev	Varchar	10	Not null
	Codepro	Varchar	10	Not null
	Datestocks	Varchar	8	Not null
	Quantentr	Varchar	10,8	Not null
	Étatpro	Varchar	15	Not null
	codefour	Varchar	10	Not null
Facture	Numfact	Varchar	10	Primary key
	Refcom	Varchar	10	Not null
	Datfac	Date	8	Not null
	Totalfact	Decimal	10,2	Not null
Dispatching	Codedispa	Varchar	10	Primary key

Mémoire dirigé par Eric WANGI NGOY

M F I T I G r a c e P a g e | 117

	Codel	Varchar	10	Not null
	Refcom	Varchar	10	Not null
	Date disp	Varchar	15	Not null

3- Description des tables

Mémoire dirigé par Eric WANGI NGOY