Memoire Online - Conception et réalisation d’un site web e-commerce d’exposition des produits informatiques de l’établissement Ciims/Bukavu

Dans ce chapitre nous avons présenté une étude du système existant circuit d'information, les documents de gestion , les lacunes qu'il comprend ainsi que les solutions que nous proposons pour pallier ces problèmes, nous avons aussi cité les besoins fonctionnels et non fonctionnels qui sont indispensables pour mieux faciliter le travail à réaliser.

Dans le chapitre suivant nous allons aborder l'étude conceptuelle de notre site, tout en mentionnant tous les scénarios possibles, les acteurs, les diagrammes ...

DEUXIEME PARTIE CADRE PRATIQUE

CHAPITRE TOISIEME

MODELISATION DU SYSTEME INFORMATIQUE

Le présent chapitre qui est l'étude et modélisation su système informatique, nous allons procéder à faire une analyse des besoins fonctionnels et non fonctionnels (les besoins opérationnels) dont le développement de l'application attendue à travers la description des besoins du système qui doivent répondre à l'attente de l'utilisateur.

Cependant, l'identification des besoins fonctionnels représente une étape importante du processus du développement du système. Aucune activité d'informatisation n'est possible sans la spécification de besoins des utilisateurs. L'informatisation étant un projet complexe, il sera important dans ce chapitre de commencer la capture des besoins des utilisateurs et de terminer avec l'élaboration.

III.1.Capture des besoins

C'est dans cette section que les besoins des utilisateurs seront capturés. La capture de besoins des utilisateurs se subdivise en deux parties, on parle de besoins fonctionnels et besoins techniques.

III.1.1.Capture des besoins fonctionnels

Les besoins fonctionnels sont liés aux fonctionnalités de l'application à mettre en place. Mais sont obtenus à l'issu de l'interview sous forme d'une narration. Partant de cette narration, avons fait intervenir les diagrammes ci-après pour la capture de besoins fonctionnels :

y' Le diagramme de cas d'utilisation (DCU) ; y' Le diagramme de séquences (DES).

Un acteur représente l'abstraction d'un rôle joué par des entités externes qui interagissent directement avec le système étudié. Un acteur peut consulter et/ou modifier directement l'état du système, en émettant et/ou en recevant des messages éventuellement porteurs de données. Voici les acteurs du système :

y' Le visiteur : c'est un individu qui est entrain de fouiller sur le net, cherchant un produit pour l'acheter ou pour avoir une idée sur les modèles et les prix. Jusqu'à ce stage, c'est un utilisateur inconnu donc il n'est pas encore un client ;

y' Le Client : cet acteur est un visiteur ayant déjà créé un compte sur notre site, il peut donc suivre le processus d'achat des produits en toute sécurité sachant que notre système doit être l'unique responsable de la confidentialité des données personnelles de ses clients ;

y' Boutique : la boutique sera considérée comme un point où le client pourra passer pour récupérer le produit acheté sur la plateforme et avant le passage du client il doit etre notifier sur la validation de ses commandes ;

V' Gestionnaire de stock : c'est l'agent chargé d'alimenter le stock des produits. Il fait le suivi du stock et assure les approvisionnements ;

V' L'administrateur : Pour les sites web, on l'appelle généralement « le webmaster ». C'est celui qui assure le dynamisme du site et veille sur les mises à jour des produits, de leurs prix, de leurs disponibilités, de la gestion des payements et la gestion des livraisons.

Les rôles des diagrammes de cas d'utilisation sont de recueillir, d'analyser et d'organiser les besoins, ainsi que de recenser les grandes fonctionnalités d'un système. Il s'agit donc de la première étape UML pour la conception d'un système.

Un diagramme de cas d'utilisation capture le comportement d'un système, d'un sous-système, d'une classe ou d'un composant tel qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d'utilisation, ayant un sens pour les acteurs. Ainsi ces cas d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d'une vision informatique.

Un cas d'utilisation (Use case) « représente un ensemble de séquences d'actions réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier » (Phitos Mbaa ; 2014, p.44).

Le tableau suivant représente quelques cas d'utilisations avec les acteurs spécifiques

Acteur	Cas d'utilisation	Scénarii
Visiteur	Consultation du catalogue	S0 : Consulter les produits
Visiteur	Inscription	S1 : Inscription
Client	Consultation du catalogue	S2 : Consulter les produits
	Remplissage du panier	S3 : Remplissage du panier par des produits
	Payement en ligne	S5 : Remplissage panier S6 : Joindre une pièce de justification
Boutique	Consulter les commandes	S7 : consulter commande
	Valider commande	S8 : valider livraison
	Télécharger pièce justificative	S9 : Téléchargement de la pièce jointe
Gestock	Ajouter catalogue	S10 : Ajouter produit
	Modifier catalogue	S11 : sélection produit S12 : modifier produit
	Supprimer catalogue	S13 : sélection produit S14 : supprimer produit
	Ajouter Approvisionnement	S15 : Ajouter approvisionnement

Administrateur	Ajouter agent	S16 : Ajouter agent
	Visualiser historique des ventes	S17 : Visualiser les ventes
	Visualiser les clients	S18 : Visualiser les clients

Un Acteur : c'est l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système. Il se représente par un petit bonhomme avec son nom inscrit dessous.

Un cas d'utilisation : c'est une unité cohérente représentant une fonctionnalité visible de l'extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service. Il représente par une ellipse contenant le nom du cas (un verbe à l'infinitif), et optionnellement, au-dessus du nom, un stéréotype.

Les relations : Trois types de relations sont pris en charge par la norme UML et sont graphiquement représentées par des types particuliers de ces relations. Les relations indiquent que le cas d'utilisation source présente les mêmes conditions d'exécution que le cas issu. Une relation simple entre un acteur et une utilisation est un trait simple

1.2.3. Diagrammes de cas d'utilisation de notre site web a) Diagramme de cas d'utilisation d'un visiteur

Avant de devenir client, un internaute ne possède que la possibilité de consulter le catalogue des produits disponibles dans le stock du fournisseur et la possibilité de s'inscrire pour devenir client sur notre site web.

(Figure N°10. Sur le Diagramme de cas d'utilisation d'un Gestionnaire de stock)

Celui-ci s'intéresse beaucoup plus sur la gestion des catalogues et l'ajout des

Par la suite, nous illustrons graphiquement dans ce tableau le diagramme de cas d'utilisation global :

Figure N°13 diagramme de cas d'utilisation (global) 1. Description textuelle des cas d'utilisations

Afin de décrire les interactions entre les cas d'utilisation, nous présentons ces derniers de façon textuelle. Il s'agit donc d'associer à chaque cas d'utilisation un nom, un objectif, les acteurs qui y participent, les préconditions et des scénarii. Cependant ; il existe trois types de scénarii : les scénarii nominaux ; les scénarii d'exceptions et les scénarii alternatifs. Dans notre description textuelle, nous présentons seulement les scénarii nominaux et alternatifs. Nous nous restreindrons à la description des cas d'utilisation suivants : authentification et inscription (application Web). Les autres cas seront détaillés dans les annexes.

CU : S'authentifier

Résumé : Ce CU permet à un utilisateur de se connecter au système et lui présente une interface.

Acteurs : Administrateur, client, boutique

Pré conditions : Introduire login et mot de passe

Post-Condition : Le cas démarre après le point 02 de l'enchaînement nominal, l'utilisateur s'authentifie

Scénario nominal

DESCRIPTION DU SCENARIO NOMINAL « DEBUT »

01 : Le système invite l'utilisateur à entrer son login et son mot de passe

02 : L'utilisateur saisie son login et son mot de passe

03 : Le système vérifie les paramètres

04 : Le système ouvre l'Espace de travail de l'acteur « FIN »

Scénario alternatif

DESCRIPTION DU SCENARIO ALTERNATIF

Le login ou le mot de passe est incorrect : ce scénario commence au point 03 du scénario nominal

01 : Le système informe l'utilisateur que les données saisies sont erronées et le scénario reprend au point 01 du scénario nominal

Acteurs : Visiteur

Post-Condition : Le cas démarre après le point 02 de l'enchaînement nominal, l'utilisateur s'inscrit au site

Scénario nominal

DESCRIPTION DU SCENARIO NOMINAL « DEBUT »

01 : Le système affiche un formulaire d'inscription à l'acteur

02 : L'acteur saisie ses informations

03 : Le système vérifie la validité des informations saisies

04 : Le système enregistre ces informations dans la base de données

05 : Le système notifie l'acteur du bon déroulement de l'opération « FIN »

Scénario alternatif

les informations sont manquantes ou incorrectes: ce scénario commence au point 03 du scénario nominal.

01 : Le système informe l'acteur que les données saisies sont erronées, garde les informations saisies avant et le scénario reprend au point 02 du scénario nominal.

Tableau 3 : Description textuelle du cas d'utilisation « Inscription au site » III.1.2. Capture de besoins techniques

On va s'intéresser à la branche droite du cycle en Y qui est « la capture des besoins techniques » en couvrant avec celle des besoins fonctionnels les contraintes qui ne traitent pas la description applicative.

L'expression des besoins techniques implique également le choix d'architecture. Ce choix est crucial puisqu'il intervient dans l'évolutivité du système, le temps de développement, le coût et les performances.

A ce niveau, la conception de l'application est élaborée de manière à fonctionner sur un ordinateur unique. En fait, tous les services fournis par l'application résident sur la même machine et sont inclus dans l'application. Toutes les fonctionnalités sont donc comprises dans une seule couche logicielle.

Cette architecture physique est assez semblable à l'architecture client/serveur, mais en plus des « clients» et du serveur de données évoquées plus haut, un serveur d'application intervient comme un troisième tiers. En effet, les machines clientes, également appelées «clients légers» ne contiennent que l'interface de l'application de manière qu'elles déchargées de tout traitement.

En effet, le traitement est ainsi assuré par le serveur d'application, qui sert de liaison entre l'interface applicative et les données localisées au niveau du serveur de données.

Dans le cadre de notre système, nous avons utilisés l'architecture 3 tiers pour notre application.

Conception et réalisation d’un site web e-commerce d’exposition des produits informatiques de l’établissement Ciims/Bukavu

Conclusion partielle du deuxième chapitre

DEUXIEME PARTIE CADRE PRATIQUE

CHAPITRE TOISIEME

MODELISATION DU SYSTEME INFORMATIQUE

III.1.Capture des besoins

III.1.1.Capture des besoins fonctionnels