Conception du système de gestion des stocks dans un établissement commercial. Cas de l’établissement "La Parole ».

III.1.3. Diagramme de cas d'utilisation

^Livreur.

^{Administrateur}

^<<include>>

^Gestion

^d'inventaire

^System

^Facturier.

^{Commander l'article}

^<<include>>

^{Percevoir l'argent}

^<<include>>

^Caissier.

^{S'authentifier}

^<<include>>

^{Livraison Article}

^Fournisseur.

^<<include>>

^<<include>>

^{Gérer les utilisateurs}

^Gestion

^{Approvisionnement}

^Client.

^Gérant.

1. Description textuelle des cas d'utilisation

· Cas d'utilisation « Commander l'article »

ü Résumé : la commande de l'article étant enregistrée par le Facturier.

Acteur principale: client

Acteur secondaire : Facturier, Caissier

Pré condition : s'authentifier

Post condition : avis favorable

ü Scénario nominal :

Facturier	Système
1. Le client passe commande	2. Vérifier la disponibilité

38

3. le Facturier Transmet la facture

4. Enregistrer la facture

V' Diagramme de séquence du Cas d'utilisation « Commander l'article » :

·

^{sd Commander Article}

^Systeme

: Client : ^Facturier.

: ^Caissier.

¹ : ^{Le client passe commande()}

² : ^{CommandeClient()}

³ : ^{Verifier disponibilité()}

⁴ : ^{Transmet la facture()}

⁵ : ^{Enregistrer la facture()}

Cas d'utilisation « Percevoir l'argent » Résumé : le caissier perçoit le montant et acquitte la facture

Acteur : Caissier

- Pré condition : s'authentifier

- Post condition : Facture apurée

V' Scénario nominal :

Caissier		Système
1. percevoir montant 2. acquitter facture	2.	Facture Validée

39

V' Diagramme de séquence du Cas d'utilisation « Percevoir l'argent » :

·

^{sd Percevoir montant}

^Systeme

: ^Caissier.

¹ : ^{Montant perçu}

² : ^{Acquiter Facture() 3} : ^{Facture Validée}

Cas d'utilisation « Livraison Article»

V' Résumé : le livreur vérifie si la facture est acquittée et livre la marchandise au

client..

Acteur : Livreur

- Pré condition : S'authentifier;

- Post condition: Article livrée;

V' Scénario nominal :

Livreur		Système	1 .vérifier si la facture acquittée 2. livrer marchandise
3. Souche facture transmise

40

V' Diagramme de séquence du Cas d'utilisation « Livraison Article » :

·

^{sd Livraison Article}

^Systeme

: ^Caissier.

¹ : ^{la facture acquittée}

² : . ^{marchandise livrée()}

³ : ^{Souche facture transmise}

Cas d'utilisation « Gestion d'inventaire »

V' Résumé : le gérant enregistre la facture et met à jour le carnet d'inventaire. A la

réception du rapport de stock il édite une commande

Acteur Secondaire: Gérant

- Pré condition : S'authentifier;

- Post condition : Etat de stock ;

V' Scénario nominal :

Gérant		Système	1. Enregistrer facture 3. Préparer la commande
2. Afficher Etat de stock 4. Actualiser Carnet de commande

41

V' Diagramme de séquence du Cas d'utilisation «Gestion d'inventaire » :

·

^{sd Gestion d'Inventaire}

^Systeme

: ^Gérant.

¹ : ^{facture Enregistée()}

² : ^{Etat de Stock Affiché}

³ : ^{Préparer Commande()}

⁴ : ^{Carnet de Commande Actualisé}

Cas d'utilisation « Gestion Approvisionnement »

V' Résumé : le gérant les vérifie émet un ordre de paiement et met à la disposition

de la livraison les marchandises contrôlées.

Acteur principal : Fournisseur

Acteur Secondaire: Gérant

- Pré condition : S'authentifier;

- Post condition : Article classé;

V' Scénario nominal :

Gérant	Système
1. Article Contrôlé 2.paiement Mise en ordre 3. Mettre à la disposition de la livraison les marchandises contrôlées	4. Article classé

42

V' Diagramme de séquence du Cas d'utilisation «Gestion d'inventaire » :

^Systeme

¹ : ^{Article Deposé}

^{sd Gestion Approvisionnement}

: ^Gérant.

: ^Fournisseur.

² : ^{Article deposé}

³ : ^{Article Contrôlé()}

⁴ : ^{paiement Mise en ordre}

⁵ : ^{Article classé}

V' Cas d'utilisation « S'authentifier »

Résumé : authentifié un utilisateur afin de le connecté à son profil.

Auteurs principal: utilisateur

- Pré-conditions :

L'utilisateur doit disposer des paramètres de son profil.

- Post condition : L'utilisateur authentifier ;

V' Scénario nominal

	User		Système
1.	Saisir Login et Password	2.	Vérifier Login et Password
	3.	Ouvrir sa session

43

· Diagramme de séquence Système

^{Sd S'authentifier}

: ^SYSTEM

^Utilisateur

^{1. Saisire login&Password}

^{2. Vérifier login} & ^password

^{2. Ouvrir session}

Cas d'utilisation « Gérer les utilisateurs »

· Résumé : Création des nouveaux profils et affectation des utilisateurs ainsi que la modification ou la suppression d'un profil.

· Auteurs principal: Administrateur

Ø Pré conditions

L'administrateur est authentifié.

Ø Scénario nominal

Administrateur	Système
Créer un profil Modifier un profil Supprimer un profil	affiche le profil crée. supprimé le profil Le profil est créé ou modifié.

44

· Diagramme de séquence Système

^{Sd Gérer Utilisateur}

: ^SYSTEM

^Utilisateur

^{1. Gérer profil}

2. ^{Affichée profil crée}

4. ^{Modifier Profil}

6. ^{Profil Modifié 5.Supprimer Profil}

^{6.Profil Supprimé}

2. IDENTIFICATION DES CLASSES

Le diagramme de classes participantes est particulièrement important puis qu'il effectue la jonction entre, d'une part, les cas d'utilisation et le modèle du domaine, et d'autre part, les diagrammes de conception logicielle que sont les diagrammes d'interaction et le diagramme de classes de conception.

Il n'est pas souhaitable que les utilisateurs interagissent directement avec les instances des classes du domaine par le biais de l'interface graphique. En effet, le modèle du domaine doit être indépendant des utilisateurs et de l'interface graphique. De même, l'interface graphique du logiciel doit pouvoir évoluer sans répercussion sur le coeur de l'application.

C'est le principe fondamental du découpage en couches d'une application.

Ainsi le diagramme de classes participantes modélise trois types de classes d'analyse, les dialogues, les contrôles et les entités ainsi que leurs relations.

Les dialogues permettent les interactions entre l'application et ses utilisateurs. Il s'agit typiquement des écrans proposés à l'utilisateur : les formulaires de saisie, les résultats de recherche, etc. Il y a au moins un dialogue pour chaque paire acteur - cas d'utilisation. Les dialogues vont posséder des attributs et des opérations. Les attributs représenteront

45

des champs de saisie ou des résultats. Les opérations seront déterminées au niveau de la conception, bien entendu après l'élaboration du diagramme d'interaction.

Les contrôles contiennent la cinématique de l'application. Elles font la transition entre les dialogues et les concepts du domaine, en permettant aux écrans de manipuler des informations détenues par des objets métier.

Elles contiennent les règles applicatives et les isolent à la fois des objets d'interface et données persistantes. Les contrôles vont seulement posséder des opérations.

Les classes qui représentent les concepts du métier sont qualifiées d'entités. C'est-elle que nous avons appris à identifier au point précèdent, cas d'utilisation par cas d'utilisation. Elles sont très souvent persistantes, c'est-à-dire qu'elles vont survivre après l'exécution d'un cas d'utilisation particulier et qu'elles permettront à des données et des relations d'être stockées dans des fichier ou des bases de données. Nous allons également ajouter des associations entre les classes d'analyse, mais en respectant des règles assez strictes :

v Les dialogues ne peuvent être reliées qu'aux contrôles ou à d'autres dialogues, mais pas directement aux entités.

v les entités ne peuvent être reliées qu'aux contrôles ou à d'autres entités.

v les contrôles ont accès à tous les types de classes, y compris d'autres contrôles. Un acteur ne peut être lié qu'à un dialogue.

L'attribution des bonnes responsabilités aux bonnes classes est l'un des problèmes les plus délicats de la conception orientée objet. Ce problème sera affronté en phase de conception lors de l'élaboration des diagrammes d'interaction et du diagramme de classes de conception.

Lors de l'élaboration du diagramme de classes participantes, le chef de projet a la possibilité de découper le travail de son équipe d'analystes par cas d'utilisation. L'analyse et l'implémentation des fonctionnalités dégagées par les cas d'utilisation définissent alors les itérations à réaliser.

Diagramme de classes participante du cas d'utilisation s'authentifier

^Utilisateur

^{Ctrl_Authentification}

Ulisateur

: ^{Page d'authentification}

: ^{Menu Principal}

Diagramme de classes participante du cas d'utilisation Commander article

^Facturier.

^Caissier.

46

^Client. .

^{Menu Principal}

^I_Client

^CtrlClient

^Article.

Diagramme de classes participante du cas d'utilisation Percevoir Montant

^Client. .

^I_Client

^{Caissier. Menu Principal}

^I_Commande

^{Porter Sur}

Commande.

^CtrlCommande

^Article.

Diagramme de classe participante du cas d'utilisation Livraison d'Article

^Article.

^I_Client

^CtrlCommande

^Commande.

^Livreur.

^{Menu Principal}

^{Porter Sur}

^I_Commande

47

^{CtrlInventaire}

^Article.

^Inventaire.

^I_Commande

^I_Inventaire

^Commande.

^Gérant.

^{Menu Principal}

^Porter Sur

^Inventorier

Diagramme de classe participante du cas d'utilisation Gestion d'inventaire

48

Diagramme de classe participante du cas d'utilisation Gestion d'Approvisionnement

^Categorie.

^I_Article

^Article.

^{I_Fournisseur}

^{CtrlFournisseur}

^Gérant.

^{Menu Principal}

^Livrer..

^{Fournisseur..}

Diagramme de classe participante du cas d'utilisation gérer utilisateur

^Profil

^Ctrl_Profil

: ^Page_Profil

^{Administrateur}

: ^Menu_Prince