MODÉLISATION
FONCTIONNELLE
Etude conceptuelle Modélisation fonctionnelle
Section I : Modélisation fonctionnelle
Identification des acteurs du système :
Avant de s'atteler à la difficile tâche de
l'identification et la description des cas d'utilisation du futur
système, il nous faudra déterminer ses acteurs principaux et
secondaires. Précisons seulement qu'un « acteur
représente un rôle joué par une entité externe
(utilisateur humain, dispositif matériel ou autre système) qui
interagit directement avec le système étudié ».
Et celui-ci peut « consulter et/ou modifier directement l'état
du système, en émettant et/ou en recevant des messages
susceptibles d'être porteurs de données ».
[UML01]
Acteurs primaires :
a) Les employés ; c'est-à-dire les postes
identifiés lors de la phase étude de l'existant :
- Préparateur ICC MATRIX
- Préparateur commande
- Chargé du suivi livraisons
- Rédacteur de rapports
- Préposé à la réception
- Group leader
b) L'administrateur du système, et qui s'occupera aussi
de sa maintenance.
Acteurs secondaires : Afin de permettre au personnel du
service des ventes de pièces de rechange de Toyota Algérie de
connaître l'état de telle ou telle commande, et par la suite
pouvoir renseigner les clients, nous considérerons le département
des ventes (qui pourrait être considéré comme un
système externe) comme acteur secondaire ayant uniquement le droit de
consulter une partie de notre application.
Diagramme de contexte statique :
Afin d'avoir une meilleure vision et répertorier tous
les acteurs en un seul schéma, et pour spécifier le nombre
d'instances d'acteurs connectées au système à un moment
donné, nous réalisons un diagramme de contexte statique. Pour
cela, la notation suivante a été utilisée :
49
0..1 ; 0..* : Nombre d'instances
connectées en même temps.
Etude conceptuelle Modélisation fonctionnelle
50
- FIG. 10 : Diagramme de contexte statique -
Identification des cas d'utilisation :
Un cas d'utilisation est l'image ou le comportement du
système du point de vue d'un ou de plusieurs utilisateurs. Il
reflète l'ensemble d'actions réalisées par le
système (déclenchées en réponse à des
stimulations d'acteurs externes en général) qui produisent un
résultat tangible et intéressant pour l'utilisateur. On note
toutefois que l'on décrit le quoi d'un cas d'utilisation sans mentionner
le comment.
On peut considérer le cas d'utilisation comme
étant la représentation la plus exhaustive possible des besoins
d'un acteur donné qui sont recentrés et restructurés de
façon à obtenir d'une part une liste de besoins réels en
réduisant les imprécision, la complexité et les
éventuels oublis ; et d'autre part pour concrétiser le futur
système sur la base de ces besoins, car le système est avant tout
destiné à ses futurs utilisateurs. L'intérêt
principal des cas d'utilisation est donc la possibilité de
décrire le caractère fonctionnel du futur système et de
pouvoir modéliser les principales tâches effectuées par les
acteurs.
Etude conceptuelle Modélisation fonctionnelle
51
« Chaque cas d'utilisation correspond à une
fonction métier du système ». [UML
01]
« Un cas d'utilisation est un classificateur qui
modélise une fonctionnalité d'un système ou d'une classe.
L'instanciation d'un cas d'utilisation se traduit par l'échange de
messages entre le système et ses acteurs ». [UML
02]
Partant de ces définitions, nous avons pu distinguer ces
différents cas d'utilisation relatifs à notre étude :
|
N°
|
Cas d'utilisation
|
Acteur(s) concerné(s)
|
|
01
|
Réaliser la matrice ICC
|
Préparateur ICC MATRIX
|
|
02
|
Préparer la commande
|
Préparateur commandes
|
|
03
|
Etablir statistiques et rapports
|
Rédacteur de rapports
|
|
04
|
Suivi livraisons
|
Chargé du suivi livraison
|
|
05
|
Suivi comptable
|
Chargé du suivi livraison
|
|
06
|
Vérifier marchandise
|
Préposé à la réception
|
|
07
|
Gérer les références pièces
|
Chef de département
|
|
08
|
Vérifier commandes
|
Chef de département ; Préparateur commandes
|
|
09
|
Traiter factures
|
Chef de département ; Préparateur commandes
|
|
10
|
Consulter commandes
|
Service des ventes
|
|
11
|
Administrer le système
|
Administrateur système
|
|
12
|
S'authentifier
|
Tous les utilisateurs
|
- TAB. 01 : Liste des cas d'utilisation -
En transcrivant ces informations sur un schéma en
utilisant la notation présentée ci-dessous, on obtient notre
diagramme de cas d'utilisation.
Etude conceptuelle Modélisation fonctionnelle
52
- FIG. 11 : Diagramme de cas d'utilisation
-
Etude conceptuelle Modélisation fonctionnelle
Description des cas d'utilisation :
A présent nous allons documenter nos cas d'utilisation en
utilisant la description textuelle, on aura plus loin (modélisation
dynamique) l'occasion d'illustrer chaque cas énuméré par
un diagramme de séquence.
CAS N° 1 : Réaliser la
matrice ICC
- Acteur principal : Préparateur ICC
matrice
- Précondition :
· L'utilisateur possède les droits
d'accès.
- Scénario nominal :
1. L'utilisateur sélectionne les références
à traiter.
2. Il charge les paramètres (1).
3. Le système calcule la demande globale et moyenne pour
chaque référence et établit les classes de
références. Il calcule par la suite le MIP pour chaque
pièce.
4. Le système compare les résultats avec les
chiffres précédents et signale d'éventuels écarts
importants.
5. Le système demande la confirmation de l'utilisateur
avant d'enregistrer les résultats.
6. Le système enregistre les modifications et informe les
autres utilisateurs concernés de la disponibilité des nouveaux
chiffres (mis à jour).
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : L'utilisateur prend en compte les écarts
détectés par le système ; le processus reprend en 3
A3 : L'utilisateur ferme l'application avant d'avoir
enregistré ; le système lui demande s'il veut enregistrer les
modifications.
A4 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
- Contraintes :
Lors des calculs et des mises à jour des données,
l'accès à ces données doit être momentanément
verrouillé pour empêcher de travailler avec d'anciennes
versions.
Les références dont le MIP est nul doivent
être mises en évidence par le système en raison de leur
traitement spécial.
53
(1) : Ventes, BO et LOST SALES qui sont des
paramètres d'un autre système.
Etude conceptuelle Modélisation fonctionnelle
CAS N° 2 : Préparer la
commande
- Acteur principal : Préparateur
commandes
- Précondition :
· L'utilisateur possède les droits
d'accès.
- Scénario nominal :
1. L'utilisateur sélectionne les références
à traiter.
2. Il charge les paramètres (2).
3. Le système calcule les quantités à
commander (SOQ)
4. Le système compare les résultats avec les
chiffres précédents et signale d'éventuels écarts
importants
5. L'utilisateur crée une nouvelle commande.
6. Le système met à disposition une nouvelle
commande avec toutes les informations requises (entête, N° de la
commande, date...etc.)
7. L'utilisateur sélectionne les références
à transformer en lignes commandes.
8. Le système ajoute aux références leurs
prix unitaires et calcule le total (en HT et/ou TTC)
9. L'utilisateur enregistre la commande sous un certain
format*
10. Le système demande la confirmation de l'utilisateur
avant d'enregistrer les résultats.
11. Le système enregistre la commande et informe le chef
de département de la disponibilité de la nouvelle commande.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : L'utilisateur prend en compte les écarts
détectés par le système ; le processus reprend en 3
A3 : L'utilisateur ferme la commande sans avoir enregistré
; le système demande confirmation
A4 : L'utilisateur ferme l'application avant d'avoir
enregistré ; le système lui demande s'il veut enregistrer les
modifications.
A5 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
- Contraintes :
Les références dont le MIP est nul doivent
être mises en évidence par le système, il en résulte
un SOQ négatif. L'utilisateur pourra le changer manuellement.
54
(2) : On Hand et BO qui dépendent d'un
autre système.
Etude conceptuelle Modélisation fonctionnelle
55
CAS N° 3 : Etablir statistiques et
rapports
- Acteur principal : Rédacteur de
rapports
- Précondition :
· L'utilisateur possède les droits
d'accès.
- Scénario nominal :
1. L'utilisateur consulte les références, les
factures et les commandes, et définit les lignes
qui sont en back
order et qui ne sont pas des commandes spéciales.
2. Il les copie à la section Back Order Follow Up
datée du jour même.
3. L'utilisateur enregistre les données.
4. le système offre certains outils statistiques.
5. Le système lui demande la confirmation avant
d'enregistrer le résultat.
6. Le système demande à l'utilisateur s'il veut
imprimer un rapport, et envoie un message aux différents utilisateurs
pour prévenir de la mise à jour.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : L'utilisateur ferme l'application avant d'avoir
enregistré ; le système lui demande s'il veut enregistrer les
modifications.
A3 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
Etude conceptuelle Modélisation fonctionnelle
56
CAS N° 4 : Suivi livraisons
- Acteur principal : Chargé du suivi
livraison
- Préconditions :
· L'utilisateur possède les droits
d'accès.
· Réception d'une facture et de son avis
d'expédition.
- Scénario nominal :
1. Le système crée un nouveau dossier «
livraison » dés l'arrivée d'une facture.
2. Lorsque l'avis d'expédition est reçu,
l'utilisateur complète alors les informations requises, et enregistre le
dossier.
3. L'utilisateur met à jour les informations relatives
à une réception à chaque arrivée d'un document du
fournisseur.
4. Le système commence à calculer (dynamiquement)
le délai de livraison, et alerte l'utilisateur à chaque
étape réalisée par une livraison.
5. Le système alerte le service de réception et
les utilisateurs concernés de l'état de l'expédition avant
l'arrivée d'une livraison.
6. Le système met à jour quelques données
comme la moyenne du temps de livraison après chaque dossier
fermé.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : Une livraison concerne plus d'une facture ; L'utilisateur
sélectionne les factures concernées afin de les regrouper en seul
dossier de livraison.
A3 : Le dossier est refermé sans enregistrement des
données ; Le système demande la confirmation de l'utilisateur.
A4 : L'utilisateur ferme l'application avant d'avoir
enregistré ; le système lui demande s'il veut enregistrer les
modifications.
A5 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
- Contraintes :
Le système doit alerter l'utilisateur à plusieurs
étapes de la livraison selon les informations introduites au fur et
à mesure, le système doit donc anticiper l'étape suivante
et rappeler l'utilisateur la suite à entreprendre.
Cette partie du système doit être multi
utilisateurs, en effet le statut d'une livraison plus particulièrement
doit être accessibles à plusieurs utilisateurs en même temps
(réception notamment).
Etude conceptuelle Modélisation fonctionnelle
57
CAS N° 5 : Suivi comptable
- Acteur principal : Chargé du suivi
livraison
- Préconditions :
· L'utilisateur possède les droits
d'accès.
· Réception d'une facture et de son avis
d'expédition.
- Scénario nominal :
1. Le système crée un nouveau dossier «
comptabilité » dés l'arrivée d'une facture.
2. L'utilisateur doit saisir les informations relatives à
la comptabilité à chaque arrivée d'un document (douane,
transitaire, compagnie maritime, assurance...etc.)
3. Le système met à jour les données telles
le coût de revient et le temps de livraison.
4. Le système prévient l'utilisateur en cas
d'oubli ou de retard dans le traitement des données.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : Le dossier est refermé sans enregistrement des
données ; Le système demande la confirmation de l'utilisateur.
A3 : L'utilisateur ferme l'application avant d'avoir
enregistré ; le système lui demande s'il veut enregistrer les
modifications.
A4 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
- Contraintes :
Le système doit offrir à l'utilisateur des
données supplémentaires, dont le taux de change de la devise
utilisée pour les transactions par rapport au dinar algérien
principalement.
Etude conceptuelle Modélisation fonctionnelle
58
CAS N° 6 : Vérifier
marchandise
- Acteur principal : Préposé
à la réception
- Préconditions :
· L'utilisateur possède les droits
d'accès.
· Existence du dossier de livraison.
- Scénario nominal :
1. Le système prépare les étiquettes de
réception à imprimer (Lorsque l'arrivée d'une marchandise
est imminente) ainsi que la planification de réception.
2. L'utilisateur informe le système des données
restantes (nombres de personnes affectées à la réception,
zone de stockage temporaire, localisation finale...etc.).
3. L'utilisateur déclenche le chronomètre avant de
commencer la vérification physique.
4. L'utilisateur remplit au fur et à mesure de la
vérification de l'état et du nombre de pièces
reçues.
5. Le système renvoie à la fin de
l'opération le rapport de déchargement de la marchandise ainsi
que de l'état des pièces si anomalie il y a.
6. Le système informe les autres utilisateurs
concernés de la fin de l'opération et des résultats
observés.
7. Le système enregistre les données et imprime le
rapport si demandé par l'utilisateur.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : Un problème inattendu survient lors de la
réception ; L'utilisateur (qui dispose de ce privilège) peut
suspendre le chronométrage en identifiant la cause.
A3 : L'utilisateur ferme l'application avant d'avoir
enregistré ; le système lui demande s'il veut enregistrer les
modifications.
A4 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
Etude conceptuelle Modélisation fonctionnelle
59
CAS N° 7 : Gérer les
références pièces
- Acteur principal : Chef de
département
- Précondition :
· L'utilisateur possède les droits
d'accès.
- Scénario nominal :
1. L'utilisateur choisis une des deux options : ajout d'une
référence pièce (à partir du NMPL) ou modification
d'une référence qui existe.
2. L'utilisateur saisi les données concernant la (les)
pièce(s) de rechange et enregistre.
3. Le système vérifie si les données
n'existaient pas auparavant.
4. Le système enregistre les nouvelles données.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : La pièce de rechange ajoutée existait
déjà ; Le système demande confirmation (remplacement) ou
annulation de l'ajout.
A3 : L'application est refermée sans enregistrement des
données ; Le système demande une confirmation de la part de
l'utilisateur.
A4 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
Etude conceptuelle Modélisation fonctionnelle
60
CAS N° 8 : Vérifier les
commandes
- Acteurs principaux : Chef de
département ; Préparateur commandes
- Préconditions :
· L'utilisateur possède les droits
d'accès.
· La commande est prête à être
lancée.
- Scénario nominal :
1. L'utilisateur consulte la dernière commande
établie.
2. L'utilisateur peut modifier les quantités à
commander ou ajouter ou supprimer les lignes commandes.
3. L'utilisateur enregistre les modifications.
4. Le système enregistre les nouvelles données
après confirmation de l'utilisateur et avertit les autres utilisateurs
de la mise à jour de la commande concernée.
5. L'utilisateur enregistre la commande sous un format
particulier pour pouvoir l'envoyer au fournisseur.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : La commande n'existe pas ; Le système demande
à l'utilisateur de vérifier le numéro de la commande
recherchée.
A3 : L'utilisateur ne procède à aucune modification
; Le scénario va directement à la fin (au N°5).
A4 : L'application est refermée sans enregistrement des
données ; Le système demande une confirmation de la part de
l'utilisateur.
A5 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
- Contraintes :
La commande doit être vérifiée avant
d'être envoyée, et le système enregistre la date et l'heure
de l'envoi de la commande.
Etude conceptuelle Modélisation fonctionnelle
61
CAS N° 9 : Traiter les factures
- Acteurs principaux : Chef de
département ; Préparateur commandes
- Préconditions :
· L'utilisateur possède les droits
d'accès.
· La facture a été reçue de la part du
fournisseur.
- Scénario nominal :
1. L'utilisateur charge la facture reçue et les documents
attachés (POSS, BO).
2. Le système traite les données en ne gardant que
les informations nécessaires et enregistre les documents ainsi
transformés.
3. L'utilisateur vérifie les documents et confirme
l'enregistrement.
4. Le système prévient les autres utilisateurs de
l'arrivée d'une nouvelle facture.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : Les données n'ont pas été totalement
chargées ; L'utilisateur doit remplir les champs perdus.
A3 : L'utilisateur ferme la facture par erreur ; Le
système demande à l'utilisateur s'il veut enregistrer avant de
quitter.
A4 : L'utilisateur ferme l'application avant d'avoir
enregistré ; le système lui demande s'il veut enregistrer les
modifications.
A5 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
- Contraintes :
Le système doit mettre à jour les informations dans
tout ce qui est relatif à la facturation. Il met en évidence
l'information plus spécialement pour le préposé au suivi
de livraison ainsi qu'au service de réception.
Etude conceptuelle Modélisation fonctionnelle
62
CAS N° 10 : Consulter des
commandes
- Acteur principal : Service des ventes
- Préconditions :
· L'utilisateur possède les droits
d'accès.
- Scénario nominal :
1. L'utilisateur fait une recherche selon un certain
critère particulier pour retrouver une commande (Numéro,
référence ...etc.).
2. Le système renvoie l'information à
l'utilisateur. Les critères de recherche sont enregistrée
séparément afin d'établir des statistiques par la
suite.
3. Le système rend la mais à l'utilisateur qui
pourra effectuer d'autres recherches.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : La commande recherchée n'existe pas ; Le
système propose à l'utilisateur de vérifier les
données ou de faire une autre recherche.
CAS N° 11 : Administrer le
système
- Acteur principal : Administrateur
système
- Préconditions :
· L'utilisateur possède les droits
d'accès.
- Scénario nominal :
1. L'utilisateur introduit son login et mot de passe avec
privilèges administrateur.
2. Le système donne accès à tous les volets
fonctionnels et d'administration de l'application (administration des profils,
des privilèges et des comptes en général) ainsi que
l'accès à la base de donnée.
3. L'administrateur peut ajouter, supprimer ou modifier
n'importe quelle partie de l'application et de la base de données.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : L'ordinateur s'arrête de fonctionner normalement ou
n'est plus sous tension ; le système enregistre une version de
récupération.
Etude conceptuelle Modélisation fonctionnelle
CAS N° 12 : S'authentifier
- Acteurs: Tous les utilisateurs
- Préconditions :
· L'utilisateur possède un login et un mot de
passe.
- Scénario nominal :
1. L'utilisateur saisit son login et son mot de passe
2. Le système vérifie la présence et la
correspondance des champs saisis
3. Le système connecte l'utilisateur à
l'application selon les privilèges attribués à son compte
ainsi que son profil.
- Scénario alternatif :
A1 : Login ou mot de passe erroné ; l'authentification est
demandée à nouveau.
A2 : L'utilisateur oublie son mot de passe ou son login ; Le
système lui demande des informations complémentaires, ou de
s'adresser directement à l'administrateur.
Regroupement des cas d'utilisation en catégories
:
À présent nous allons structurer les cas
d'utilisations décrits en ensembles cohérents appelés
PACKAGES. Nous les regrouperons selon le domaine fonctionnel de chaque cas,
comme suit :
PACKAGE N°1 PACKAGE N°2
PACKAGE N°3
ACHATS
PIECES
LIVRAISONS
PIECES
SUPPORT ECHNIQUE
63
CAS 1,2,8,9,10 CAS 4,5,6 CAS 3,7,11,12
- FIG. 12 : Catégories de cas d'utilisation
-
| 
