Chapitre II Spcification et analyse des

besoins
Introduction
Dans ce chapitre on prsenter les diffrentes besoins fonctionnels et
non fonctionnels du site de vente des matriels agricultures et didentifier
les messages changs entre les diffrents acteurs du systme.
Donc lobjectif de cette partie est de donner une description des
fonctionnalits du site en utilisant des diagrammes de cas dutilisation.
I.

Identification des besoins

1. Besoins fonctionnels

Notre application de vente de matrielles agricultures permet de

raliser les tches suivantes :

Lapplication permet un nouvel utilisateur internaute de

sinscrire. En effet, linternaute doit remplir un formulaire

dinscription (nom, prnom, identifiant, mot de passe).

Lapplication permet un utilisateur ou agriculteur (dj
inscrit) daccder sa propre session en fournissant un

identifiant et un mot de passe.

a. Les besoins de ladministrateur
Lapplication offre ladministrateur la possibilit de :
sidentifier pour pouvoir accder sa propre session,
grer les inscriptions,
grer les offres,
grer produits,
grer les maladies agricultures,
grer le contact,
mettre jour les informations.
b. Les besoins internautes

Lapplication permet un nouveau utilisateur internaute de

sinscrire, on remplit un formulaire dinscription (nom, prnom,
identifiant, mot de passe).

Elle permet aux internautes de :

c. Les

consulter le site et les offres

faire inscription
faire recherche produits
besoins de lagriculteur

Lapplication offre aux agriculteurs la possibilit :

d'accder sa propre session en fournissant un identifiant et un

mot de passe,
consulter les produits agricultures,
achat en ligne,
faire recherche maladies en ligne,
de contacter en ligne ladministrateur,
de faire paiement en ligne.

1. Besoins non fonctionnels

Les besoins non fonctionnels prsentent les exigences implicites la
quelles lapplication doit rpondre. Parmi ces besoins nous citons :
a. La convivialit
L'application doit avoir des interfaces conviviales. Faciles utiliser,
adapter chaque type d'utilisateur. Elle doit combiner des donnes
textuelles bien claires et des donnes graphiques bien structures.
b. Lefficacit
Lapplication doit tre efficace lors des transactions effectues par
ladministrateur ou par les employs ou par les visiteurs.

c. La scurit
L'application doit assurer un accs privilgi (chaque utilisateur
n'accde un domaine qu'aprs authentification). Pour assurer la bonne
scurit, on a utilis les sessions de php pour le site. Les sessions PHP sont
aujourd'hui le meilleur moyen pour stocker temporairement des variables
lies un visiteur, sur un site internet. Une session PHP vous permet de
stocker des informations de l'utilisateur sur le serveur (son mail, ses
identifiants de connexion...) ce qui offre un haut niveau de scurit,
l'inverse des cookies qui stockent les informations directement sur le poste
du agriculteur. Toutefois, une session est temporaire et est efface trs
rapidement du serveur.
d. La maintenance
Les diffrences modules de lapplication doivent tre bien
comprhensibles et bien comments pour pouvoir les maintenir facilement
et rapidement.
Aprs avoir dtaill cette application, il est ncessaire, maintenant, de
transformer lensemble des ides prcdemment voques en dfinitions
et notation plus dtailles. Ainsi, on passe la phase de conception.
II.

Spcification des besoins

Nous sommes bass sur les diagrammes UML, plus particulirement

les diagrammes de cas dutilisation, pour lexpression et le raffinement des
besoins fonctionnels du systme raliser.
UML

(Unified

Modeling

Language

Langage

unifi

pour

la

modlisation) est un langage de modlisation bas sur un ensemble de

modle permettant de reprsenter un systme dinformation .Lusage de

ces modles par les informaticiens sappuient sur une expression des
besoins que devra satisfaire la future application .1
1. Identification et classification des cas dutilisation
a. Dfinition des acteurs
Un cas dutilisation ou encore use case spcifie une squence
dinteractions entre les acteurs et le systme, produisant un rsultat
satisfaisant pour un acteur particulier. Lidentification des cas dutilisation
permet la prsentation et la comprhension des besoins fonctionnels du
systme2 .
Dans cette partie, nous allons prsenter les diffrents acteurs et leurs
besoins. Dans le tableau suivant, nous essayons de classer les diffrents
acteurs de cas dutilisation du systme selon leurs fonctionnalits dans le
site web.
Acteur
Internaute

Agriculteur

Administrateur

Rle
Consulter le site et les produits
Faire inscription
Faire recherche produit
Authentification
Achat produit agriculture
Recherche maladie agriculture
Contact
Paiement
Authentification
Grer inscription
Grer produit
Grer maladies agricultures
Voir contact
Grer offre
Tableau 1:les classification des acteurs

b. Diagramme de cas dutilisation globale

Aprs avoir identifi les acteurs et les cas dutilisation, il est utile de
restructurer lensemble des cas dutilisation que nous lavons fait

1 https://fr.wikipedia.org
2 http://fr.wikipedia.org

apparaitre afin de rechercher les comportements partags, les cas

particuliers et les gnralisations.
Les relations possibles entre cas dutilisation : lUML dfinit trois types
de relations standardises entre cas dutilisation, dtailles ci-aprs :
Une relation dinclusion : formalise par la dpendance Include .
Une relation dextension : formalise par la dpendance extend .
Une relation de gnralisation/spcification.

Figure 1:diagramme de cas d'utilisation globale

c. Diagramme de cas dutilisation cot administrateur
Ce digramme montre les fonctionnalits de ladministrateur, mais aprs
avoir authentifi. Il peut faire la gestion dinscription, gestion des offres,
gestion produits, gestion de contact, gestion maladies agricultures... Il
peut aussi faire la mise jour et la maintenance du site.

Figure 2:diagramme de cas d'utilisation "cot administrateur"

d. Diagramme cas dutilisation authentification administrateur
Dans ce cas dutilisation, pour permettre ladministrateur de grer son
site web, il faut faire une authentification (login, mot de passe) pour
accder son espace administrateur pour grer son site web comme par
exemple : grer inscription, de supprimer, ajouter ou modifier ou grer
produit, grer maladies agriculture, voir contact, grer les offres.

Figure 3:diagramme de cas "authentification administrateur"

e. Diagramme cas dutilisation gestion produit
Aprs avoir sidentifie, ladministrateur permet de grer les produits. Il a le
droit dajouter, modifier ou supprimer un produit agriculture.

Figure 4:diagramme de cas "gestion produit"

f. Diagramme de cas dutilisation inscription internaute
Linternaute sinscrit en remplissant un formulaire pour pouvoir accder au
site et le consulter ainsi que ralis plusieurs oprations. Une entit
internaute est dfinie par son identit, nom, prnom, adresse, ville,
code, date de naissance, login et mot de passe. Cette fonctionnalit est
illustre par le diagramme de cas dutilisation suivant :

Figure 5:diagramme de cas "inscription internaute"

g. Diagramme de cas dutilisation authentification agriculteur
Dans

ce

diagramme,

pour

permettre

au

agriculteur

dutiliser

les

fonctionnalits de site web, il faut faire une authentification (login, mot de

passe) pour accder son espace personnel pour faire lachat produit
agriculture en ligne, faire le paiement en ligne, contacter administrateur.

Figure 6:diagramme de cas "authentification agriculteur"

h. Diagramme de cas dutilisation achat produit

Aprs avoir identifie, lagriculteur permet de choisir un produit agriculture
pour lacheter. Il a le droit de valider la procdure de lachat ou dannuler.

Figure 7:diagramme de cas "achat produit"

i. Diagramme de cas dutilisation paiement en ligne
Pour faire le paiement, lagriculteur doit de sauthentifier tout dabord pour
accder son espace. Aprs lauthentification, aprs avoir pass sa
commande, lagriculteur choisi le mode de paiement comme par exemple
la carte bancaire, carte e-dinar.

Figure 8:diagramme de cas "paiement en ligne"

Conclusion
Ce chapitre nous permit principalement de mieux comprendre les
besoins fonctionnels et non fonctionnels du systme, ce qui nous permet
de concevoir notre site travers une modlisation dtaille, que nous
stabilisons au cours du chapitre suivant, dans la phase de conception.

Chapitre III Conception

Introduction
Aprs avoir identifi les principaux cas dutilisation et les acteurs
qui lui sont confis les diffrentes fonctionnalits attendues par le systme
au cours du chapitre prcdent, en ce qui concerne ce chapitre , nous
allons dtailler et dcrire chaque cas dutilisation qui doit faire lobjet
dune dfinition apriori qui dcrit lintention de lacteur lorsquil utilise le
systme et les squences dactions principales quil est susceptible
deffectuer.
Dans ce chapitre, nous allons prsenter les diagrammes de cas
dutilisations qui ont pour but d'identifier les diffrentes fonctionnalits et
acteurs du systme, nous allons prsenter ensuite le diagramme des
classes, quelques diagrammes de squences et diagrammes dactivit.
I.

UML (Unified Modelling Langage)

1. Dfinition de lUML
UML (Unified Modelling Langage) est un langage de modlisation

unifi et no pas une mthode de conception. UML a t conu pour

permettre la modlisation de tous les phnomnes de lactivit du monde

rel indpendamment des techniques dimplmentation mis en uvre.
Cest un langage trs expressif qui couvre toutes les perspectives
ncessaires au dveloppement puis au dploiement de systme.
2. Les concepts dUML
Larchitecture dUML est prsente en deux volets :
Dune part, les constituants lmentaires qui forment la structure
complte de langage et dautre part, sa structure globale.
UML dfinit plusieurs modles pour la prsentation des systmes :

Le modle de classes qui capture la structure statique.

Le modle des tats qui exprime le comportement dynamique

des objets.

Le modle des cas dutilisation qui dcrit les besoins des

utilisateurs.

Le modle dinteraction qui reprsente le scnario et les flux

des messages.

Le modle de ralisation qui montre les units de travail.

Le modle de dploiement qui prcise la rparation des

processus.

Ces modles sont regards et manipuls par les utilisateurs au

moyen des vues graphiques. Des nombreuses vues peuvent tre
construites partir des modles de base, elles peuvent montrer tout ou
une partie du modle.
3. Les diagrammes dUML
Les diagrammes dUML sont :

Le diagramme de cas dutilisation : reprsente les relations

entre les acteurs et les fonctionnalits de systme. Les cas
dutilisation reprsentent une vie externe de la faon dutiliser un
systme, que ce soit lapplication, un sous-systme, une fonction,
un composant.

Le diagramme de classes : est un ensemble dlments statiques

qui montrent la structure dun modle (les classes, leurs types, leurs
contenus).

Le diagramme dobjets :(objet : une instance dune classe)

reprsente les objets et les liens entre eux. Il permet daffiner un
aspect particulier dun diagramme de classes pour un contexte
donn.

Le diagramme dtats transition : dcrit le cycle de vie des

objets formaliss dans une classe.

II.

Diagramme de classe
1. Prsentation
Le diagramme de classes contient :
-

Les classes qui dcrivent le domaine de dfinition dun ensemble

dobjet. Un objet est une instance dune classe.

Les attributs qui reprsentent un type dinformation contenu

dans une classe et les oprations qui reprsentent un lment de
comportement contenu dans une classe.

Lassociation qui reprsente une relation smantique durable

entre deux classes.

Figure 9:diagramme de classe

III.

Diagramme de squence
1. Prsentation

Les diagrammes de squence mettent en valeur les changes de

messages entre acteurs et objets de manire chronologique, lvolution
du temps se lisant de haut en bas.

2. Diagramme squence cas authentification

Titre
Acteur
Pr condition
But
Scnario normale
1.
2.
3.
4.

Authentification
Utilisateur (agriculteur,
administrateur)
Saisir login et mot de passe
Accde au compte utilisateur

Lutilisateur doit sauthentifier

Saisir login et mot de passe
Vrification
Afficher page accueil
Scnario alternatif

1. Le contrle demande lutilisateur de sauthentifier de nouveau

2. Vrification
3. Message erreur si les champs sont mal remplir
Tableau 2: description de cas "authentification"

Figure 10:diagramme squence cas "authentification"

3. Diagramme de squence cas inscription internaute
Titre
Acteur
Pr condition
But
Scnario normale
1.
2.
3.
4.

Inscription
Internaute
Entre les informations personnelles
Avoir un compte personnel

Linternaute doit sinscrire

Remplir formulaire inscription
Vrification
Succs davoir un compte personnel
Scnario alternatif

1. Le contrle demande linternaute de remplir le formulaire de

nouveau
2. Vrification
3. Message erreur si les champs sont mal remplir
Tableau 3:description de cas "inscription"

Figure 11:diagramme squence "inscription internaute"

4. Diagramme de squence cas achat produit
Titre
Acteur
Pr condition
But
Scnario normale
1.
2.
3.
4.

Achat produit
Agriculteur
Disponibilit de stock
Achat produit

Lagriculteur choisit le produit acheter

Remplir formulaire dachat
Remplir formulaire de paiement
Achat produit
Scnario alternatif

1. Le contrle va vrifier la disponibilit de stock de produit

2. Vrification de stock
3. Message erreur si la quantit demand est suprieur la quantit
de stock

Tableau 4:description de cas "achat produit"

Figure 12:diagramme squence "achat produit"

4. Diagramme squence ajout produit

Titre
Acteur
Pr condition
But
Scnario normale

Ajout produit
Administrateur
Sidentifier
Ajout produit agriculture

1. Ladministrateur demande formulaire dajout produit

2. Remplir formulaire dajout
3. Insertion nouveau produit

Scnario alternatif

Tableau 5:description de cas "ajout produit"

Figure 13:diagramme squence "ajout produit"

4. Diagramme squence de cas modifier produit
Titre
Acteur
Pr condition
But
Scnario normale

Modifier produit
Administrateur
Sidentifier
Modifier produit agriculture

1.
2.
3.
4.

Ladministrateur accde la page modification dun produit

Il choisit le produit modifier
Vrification
Produit modifi
Scnario alternatif

1. Le contrle va vrifier les donnes entres

2. Vrification
3. Message erreur si les champs sont mal remplir
Tableau 6:description de cas "modifier produit"

Figure 14:diagramme squence "modifier produit"

4. Diagramme de squence supprimer produit
Titre
Acteur
Pr condition
But
Scnario normale

Suppression produit
Administrateur
Sidentifier
Supprimer un produit

1.
2.
3.
4.

Ladministrateur choisit le produit supprimer

Demande confirmation de suppression
Suppression de produit
Mise jour
Scnario alternatif

Tableau 7:description de cas "supprimer produit"

Figure 15:diagramme squence "supprimer produit"

IV.

Diagramme dactivit
1. Prsentation

Le diagramme d'activit est un diagramme comportemental d'UML,

permettant de reprsenter le dclenchement d'vnements en fonction
des tats du systme et de modliser des comportements paralllisables.
Le diagramme d'activit est galement utilis pour dcrire un flux de
travail.

2. Diagramme activit pour le cas ajout produit

Nous prsentons le diagramme dactivit pour le scnario ajout
produit. Ladministrateur

a comme activit dans ce scnario le

remplissage du formulaire qui contient quelques informations sur un

produit. On distingue deux cas :
1) Si les informations sont valides, alors on passe la confirmation
dajout.
2) Sinon, il faut les vrifier jusqu' atteindre le premier cas.

Figure 16:diagramme activit "ajout produit"

3. Diagramme activit de cas modifier produit

Nous prsentons le diagramme dactivit pour le scnario modifier
produit. Dans ce scnario, le but dadministrateur est de modifi un

produit donn. Pour atteindre ce but, ladministrateur demande interface

modification produit . Pour cette opration, on distingue deux cas :
1) Si les donnes envoyes la base de donnes sont valides, la
confirmation

de

modification

est

effectue

avec

succs

ladministrateur.
2) Sinon, le systme va afficher un message erreur ladministrateur,
ce dernier saisit de nouveau les nouvelles donnes jusqu arriver au
premier cas.

Figure 17:diagramme activit "modifier produit"

4. Diagramme dactivit supprimer produit

Ce diagramme montre le scnario de cas de suppression produit . Le

but est de supprimer un produit, le systme va afficher la liste de produit
exist. Ladministrateur va choisir le produit supprimer. Aprs avoir
confirm par ladministrateur, la base de donnes va raliser une mise
jour.

Figure 18:diagramme d'activit "supprimer produit"

V.

Diagramme dtat de transition

1. Prsentation

Le diagramme dtat de transitions reprsente le comportement des classes travers

lvolution dans un tat successif. Chaque objets doit suit le comportement dcrit dans le
diagramme dtat de transitions de la classe associes.
Le diagramme dtat de transitions peuvent reprsente des scnarios de comportement.
2. Diagramme dtat de transition pour le cas inscription

Figure 19:diagramme d'tat de transition "inscription"

3. Diagramme dtat de transition achat produit

Figure 20:diagramme d'tat de transition "achat produit"

VI.

Diagramme de collaboration
1. Prsentation

Un diagramme de collaboration est un diagramme d'interactions UML 1.x,

reprsentation simplifie d'un diagramme de squence se concentrant sur
les changes de messages entre les objets, et o la chronologie
n'intervient que de faon annexe.
Il consiste en un graphe dont les nuds sont des objets et les arcs
(numrots selon la chronologie) les changes entre ces objets

2. Diagramme de collaboration de cas sidentifier

Figure 21:diagramme de collaboration de cas "s'identifier"

3. Diagramme de collaboration de cas sinscrire

Figure 22:diagramme de collaboration de cas "s'inscrire"

4. Diagramme de collaboration de cas ajout produit

Figure 23:diag cas collaboration

Conclusion
Dans ce chapitre, nous avons prsent le diagramme de classes
comme vue statique de systme, et nous avons fini par la prsentation
des diagrammes de squences et diagramme dactivit ; en effet, il s'agit
de la partie dynamique de systme en fonction de temps (lordre
chronologique de diffrentes fonctionnalits).
Nous allons maintenant pouvoir passer la dernire phase de cycle
de vie de notre application savoir la phase de la ralisation.

Sommaire
Chapitre II Spcification et analyse des besoins1
Introduction......................................................................................................... 1
a. Les besoins de ladministrateur..........................................................1
b. Les besoins internautes........................................................................1
c.

Les besoins de lagriculteur.................................................................2

1. Besoins non fonctionnels......................................................................2

a. La convivialit......................................................................................... 2
b. Lefficacit................................................................................................ 2
c.

La scurit............................................................................................... 3

d. La maintenance...................................................................................... 3
II.

Spcification des besoins.....................................................................3

1. Identification et classification des cas dutilisation.........................3

a. Dfinition des acteurs........................................................................... 3
I.

UML (Unified Modelling Langage)...........................................................9

1. Dfinition de lUML................................................................................. 9
2. Les concepts dUML............................................................................... 9
3. Les diagrammes dUML......................................................................10

Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure

1:diagramme de cas d'utilisation globale....................................................5

2:diagramme de cas d'utilisation "cot administrateur"..............................5
3:diagramme de cas "authentification administrateur"...............................6
4:diagramme de cas "gestion produit"........................................................6
5:diagramme de cas "inscription internaute"..............................................7
6:diagramme de cas "authentification agriculteur".....................................7
7:diagramme de cas "achat produit"...........................................................7
8:diagramme de cas "paiement en ligne"....................................................8
9:diagramme de classe.............................................................................. 11
10:diagramme squence cas "authentification"........................................13
11:diagramme squence "inscription internaute".....................................14
12:diagramme squence "achat produit"..................................................15
13:diagramme squence "ajout produit"...................................................16
14:diagramme squence "modifier produit"..............................................17
15:diagramme squence "supprimer produit"...........................................18
16:diagramme activit "ajout produit".......................................................19
17:diagramme activit "modifier produit".................................................20
18:diagramme d'activit "supprimer produit"............................................21
19:diagramme d'tat de transition "inscription"........................................22
20:diagramme d'tat de transition "achat produit"...................................23
21:diagramme de collaboration de cas "s'identifier".................................24
22:diagramme de collaboration de cas "s'inscrire"....................................24

Figure 23:diagramme de collaboration "ajout produit".........................................25

Tableau
Tableau
Tableau
Tableau
Tableau
Tableau
Tableau

1:les classification des acteurs..................................................................4

2: description de cas "authentification"..................................................12
3:description de cas "inscription"............................................................13
4:description de cas "achat produit".......................................................15
5:description de cas "ajout produit"........................................................16
6:description de cas "modifier produit"...................................................17
7:description de cas "supprimer produit"................................................18