WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception et Developpement d'un logiciel de gestion commerciale

( Télécharger le fichier original )
par Mchangama Ismaila
ISIMM - Maitrise 2007
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

4.3 Modélisation Statique :

Précédemment on a parlé des deux grandes catégories de diagrammes UML (statique et dynamique) l'un des diagrammes statiques nous intéresse beaucoup pour pouvoir implémenter le code, il s'agit du diagramme de classes

4.3.1 Diagramme de classes :

Ce modèle nous permet d'avoir une vue statique de l'application. Il nous montre les relations entre les différentes entités (classes) composant notre application. Il nous mène vers la solution finale. À partir de ce diagramme on retrouve les corps des différentes classes de notre application. Mieux encore en utilisant la technique de l'ingénierie (voir Annexe 3) on obtient une grande partie du code finale.

Figure 9. Diagramme de classes

Le schéma ci-dessus nous donne une vue globale de notre application. On a les classes principales qui vont nous servir à réaliser l'application.

Pour avoir de plus amples informations sur l'autre partie de notre application on peut penser à représenter le modèle conceptuel de données (modèle physique) il s'agit de représenter les données et les différentes relations entre elles. Ce modèle nous a permis de construire notre base de donnée, car chaque entité est associée à une table dans la base de donnée.

Faisons un feed-back sur le diagramme des classes et faisons quelques détails :

Ø Client :

Un client peut avoir plusieurs factures comme il peut avoir plusieurs commandes et plusieurs devis, et quand il reçoit un produit il doit avoir un bon de livraison.

Ø Fournisseur :

Il reçoit un ou plusieurs commandes de la société, donc il va donner une facture et un bon de livraison au moment de la livraison

Ø Facture, bon de commande, Devis, bon de livraison:

Ici il s'agit du coté vente, donc ils doivent posséder chacun une référence, un code client, une date et un ou plusieurs produits.

On peut avoir des transformations comme l'indique la table suivante :

Peut être transformé(e)

Facture

BL

BC

Devis

Facture

*******

Oui

Non

Non

BL

Non

*******

Non

Non

BC

Oui

Oui

*******

Non

Devis

Oui

Oui

Oui

*******

Tableau 2. Tableau des transformations.

Peut être transformé(e)

A B

Ø Facture, bon de commande, bon de livraison:

Ici il s'agit du coté achat, donc ils doivent posséder chacun une référence, un code fournisseur, une date et un ou plusieurs produits. Ici on n'a pas besoin des transformations.

Ø Produit :

Un produit est caractérisé par sa référence, sa désignation, sa catégorie, son type, la quantité, sa marque, tva et son prix d'achat.

Ø Administrateur/agent :

C'est seulement les deux personnes qui ont accès physiquement à l'application. Ils gèrent les clients, les fournisseurs, les factures, les commandes et les bons. Il est évident que l'administrateur hérite de l'agent, car c'est lui seul qui peut gérer les agents.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Enrichissons-nous de nos différences mutuelles "   Paul Valery