Chapitre II Spcification et analyse des besoinsIntroduction 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 besoins1. Besoins
fonctionnelsNotre 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
ladministrateurLapplication 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 internautesLapplication permet un nouveau utilisateur
internaute de sinscrire, on remplit un formulaire dinscription
(nom, prnom, identifiant, mot de passe).
Elle permet aux internautes de: consulter le site et les offres
faire inscription faire recherche produitsc. Les besoins de
lagriculteurLapplication 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 fonctionnelsLes 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 scuritL'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 besoinsNous 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.[footnoteRef:2]
[2: https://fr.wikipedia.org]
1. Identification et classification des cas dutilisationa.
Dfinition des acteursUn 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 systme[footnoteRef:3] .
[3: http://fr.wikipedia.org]
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.ActeurRle
Internaute Consulter le site et les produitsFaire
inscriptionFaire recherche produit
Agriculteur AuthentificationAchat produit agricultureRecherche
maladie agricultureContactPaiement
Administrateur AuthentificationGrer inscriptionGrer produitGrer
maladies agricultures Voir contactGrer offre
Tableau 1:les classification des acteursb. Diagramme de cas
dutilisation globaleAprs avoir identifi les acteurs et les cas
dutilisation, il est utile de restructurer lensemble des cas
dutilisation que nous lavons fait 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 dpendanceInclude. Une relation dextension: formalise par la
dpendanceextend. Une relation de gnralisation/spcification.
Figure 1:diagramme de cas d'utilisation globalec. Diagramme de
cas dutilisation cot administrateurCe 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 administrateurDans 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 produitAprs 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 internauteLinternaute 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 agriculteurDans 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 produitAprs 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 lignePour 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"ConclusionCe
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 ConceptionIntroduction 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 lUMLUML (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 dUMLLarchitecture 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 dUMLLes 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 classe1. 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 classeIII. Diagramme de squence1.
PrsentationLes 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 authentificationTitre
Authentification
Acteur Utilisateur (agriculteur, administrateur)
Pr condition Saisir login et mot de passe
But Accde au compte utilisateur
Scnario normale
1. Lutilisateur doit sauthentifier2. Saisir login et mot de
passe3. Vrification 4. Afficher page accueil
Scnario alternatif
1. Le contrle demande lutilisateur de sauthentifier de nouveau2.
Vrification3. 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 internauteTitre Inscription
Acteur Internaute
Pr condition Entre les informations personnelles
But Avoir un compte personnel
Scnario normale
1. Linternaute doit sinscrire2. Remplir formulaire inscription3.
Vrification 4. Succs davoir un compte personnel
Scnario alternatif
1. Le contrle demande linternaute de remplir le formulaire de
nouveau2. Vrification3. 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 produitTitre Achat produit
Acteur Agriculteur
Pr condition Disponibilit de stock
But Achat produit
Scnario normale
1. Lagriculteur choisit le produit acheter2. Remplir formulaire
dachat3. Remplir formulaire de paiement 4. Achat produit
Scnario alternatif
1. Le contrle va vrifier la disponibilit de stock de produit2.
Vrification de stock3. 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 produitTitre Ajout produit
Acteur Administrateur
Pr condition Sidentifier
But Ajout produit agriculture
Scnario normale
1. Ladministrateur demande formulaire dajout produit2. Remplir
formulaire dajout3. Insertion nouveau produit
Scnario alternatif
Tableau 5:description de cas "ajout produit"
Figure 13:diagramme squence "ajout produit"4. Diagramme squence
de cas modifier produitTitre Modifier produit
Acteur Administrateur
Pr condition Sidentifier
But Modifier produit agriculture
Scnario normale
1. Ladministrateur accde la page modification dun produit2. Il
choisit le produit modifier3. Vrification 4. Produit modifi
Scnario alternatif
1. Le contrle va vrifier les donnes entres 2. Vrification3.
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 produitTitre Suppression produit
Acteur Administrateur
Pr condition Sidentifier
But Supprimer un produit
Scnario normale
1. Ladministrateur choisit le produit supprimer2. Demande
confirmation de suppression3. Suppression de produit4. Mise
jour
Scnario alternatif
Tableau 7:description de cas "supprimer produit"
Figure 15:diagramme squence "supprimer produit"
IV. Diagramme dactivit 1. PrsentationLe 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 produitNous 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 produitNous 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 produitCe 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 transition1. PrsentationLe 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 collaboration1. PrsentationUndiagramme de
collaborationest un diagramme d'interactionsUML1.x, reprsentation
simplifie d'undiagramme de squencese concentrant sur les changes de
messages entre les objets, et o la chronologie n'intervient que de
faon annexe.Il consiste en ungraphedont 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 collaborationConclusion 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.
SommaireChapitre II Spcification et analyse des
besoins1Introduction1a.Les besoins de ladministrateur1b.Les besoins
internautes1c.Les besoins de lagriculteur21.Besoins non
fonctionnels2a.La convivialit2b.Lefficacit2c.La scurit3d.La
maintenance3II.Spcification des besoins31.Identification et
classification des cas dutilisation3a.Dfinition des acteurs3I.UML
(Unified Modelling Langage)91.Dfinition de lUML92.Les concepts
dUML93.Les diagrammes dUML10
Figure 1:diagramme de cas d'utilisation globale5Figure
2:diagramme de cas d'utilisation "cot administrateur"5Figure
3:diagramme de cas "authentification administrateur"6Figure
4:diagramme de cas "gestion produit"6Figure 5:diagramme de cas
"inscription internaute"7Figure 6:diagramme de cas
"authentification agriculteur"7Figure 7:diagramme de cas "achat
produit"7Figure 8:diagramme de cas "paiement en ligne"8Figure
9:diagramme de classe11Figure 10:diagramme squence cas
"authentification"13Figure 11:diagramme squence "inscription
internaute"14Figure 12:diagramme squence "achat produit"15Figure
13:diagramme squence "ajout produit"16Figure 14:diagramme squence
"modifier produit"17Figure 15:diagramme squence "supprimer
produit"18Figure 16:diagramme activit "ajout produit"19Figure
17:diagramme activit "modifier produit"20Figure 18:diagramme
d'activit "supprimer produit"21Figure 19:diagramme d'tat de
transition "inscription"22Figure 20:diagramme d'tat de transition
"achat produit"23Figure 21:diagramme de collaboration de cas
"s'identifier"24Figure 22:diagramme de collaboration de cas
"s'inscrire"24Figure 23:diagramme de collaboration "ajout
produit"25
Tableau 1:les classification des acteurs4Tableau 2: description
de cas "authentification"12Tableau 3:description de cas
"inscription"13Tableau 4:description de cas "achat
produit"15Tableau 5:description de cas "ajout produit"16Tableau
6:description de cas "modifier produit"17Tableau 7:description de
cas "supprimer produit"18