I.3. Analyse du métier
L'analyse du métier est la prise de connaissance du
domaine d'application et du diagnostic des points forts et des points faibles
permettant une approche du problème. Il faut d'abord récolter les
informations ensuite assurer la présentation c'est-à-dire
inventorier ce qui existe et ainsi tirer les conséquences
nécessaires au changement ou au maintien de cet existant.
Ceci dit, voici comment se déroule le processus qui fait
l'objet de notre étude.
I.3.1. Description textuelle du métier
Cette partie du travail consistera à décrire le
fonctionnement de l'entreprise Publi-Inter, c'est-à-dire de la
réception d'un client jusqu'à l'exécution du service
demandé.
C'est sur base de cette description et des besoins
réels des utilisateurs que nous verrons maintenant quelles sont les
taches qu'on peut automatiser et celles qu'on ne peut pas automatiser. Cette
description est faite suivant l'ordre chronologique des opérations
ci-après :
· Un client vient solliciter un panneau auprès de la
réception ;
· La réception vérifie si il y a des panneaux
disponibles ;
· Si il y a des panneaux disponibles, la réception
propose au client les panneaux libres ;
· Si le client est d'accord alors il fait son choix et la
réception lui donne un contrat qu'il remplit ;
· La réception transmet le contrat rempli et
dûment signé par le client auprès du Directeur ;
· Le Directeur demande à la réception
d'établir la facture ;
· Le client paye la facture et la réception renvoie
cette dernière auprès du directeur pour validation ;
· Le directeur valide le contrat et ainsi on remet un
exemplaire au client.
I.3.2. Diagramme de contexte
Un diagramme de contexte est un diagramme qui
représente d'une manière globale le système sans le
détailler. Il permet de délimiter le périmètre du
système étudié.
Fig. 2 : Diagramme de contexte
I.3.3. Diagramme de cas d'utilisation métier
Le diagramme de cas d'utilisation est un diagramme UML, qui
modélise les besoins des utilisateurs. Il montre donc les interactions
fonctionnelles les besoins des utilisateurs, donc les interactions
fonctionnelles qui existent entre les acteurs et le système à
étudier.
Dans ce type de diagramme, nous distinguons deux concepts UML
fondamentaux pour la spécification des exigences qui sont : Les cas
d'utilisations et les acteurs.
· Un cas d'utilisation est un ensemble d'actions
réalisées par le système et c'est un acteur qui les
déclenche ;
· Un acteur est un rôle joué par une personne
ou un processus qui interagit avec le système.
12
Hormis ces deux concepts fondamentaux, nous retrouvons aussi
l'association qui est utilisée pour relier les acteurs aux cas
d'utilisation par une relation signifiant « participe ã »
Dans ce type de diagramme, nous pouvons aussi parler des
relations qui existent entre les différents cas d'utilisations.
Il y en a entre autres :
· La relation d'inclusion « include », qui
signifie qu'un cas d'utilisation A inclut un cas B lorsque l'exécution
de A dépend de l'exécution de B, et on dit que A dépend de
B.
· La relation d'extension « extend », qui
signifie qu'un cas d'utilisation A étend un cas B lorsque le cas A
peut-être appelé au cours de l'exécution du cas B.
· La relation généralisation, signifiant que
le cas d'utilisation B est un cas particulier du cas d'utilisation A.
I.3.3.1. Les acteurs
+ Le client : personne qui vient solliciter un panneau dans
l'entreprise + Le réceptionniste : Personne qui accueille le client
+ Le directeur : Personne qui contrôle toutes les
opérations du système
| 
