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