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