La démarche agile au service du e-business : Deuxième partie par ...

Sami.Jaber

Informations

• Publié par: alavozuv
• Nombre de lectures: 128
• Langue: Français
• Poids de l'ouvrage: 1 Mo

Extrait

La démarche agile au service du e-business : Deuxième partie par Pascal Roques  

Dans ce deuxième article, nous allons mettre en œuvre sur un petit exemple le processus simplifié que nous préconisons pour la modélisation des sites Web marchands, jusqu’à la conception détaillée sur la plateforme .NET.   Pour mémoire, ce processus (décrit dans l’article précédent) se situe à mi -chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et XP (eXtreme Programming), une approche minimaliste à la mode centrée sur le code. Nota : la description détaillée de ce processus ainsi q ue de sa mise en œuvre complète sur le cas de la librairie en ligne paraîtra prochainement chez Eyrolles, dans une nouvelle collection intitulée « Les cahiers du Programmeur », sous le titre : « Modéliser un site e - commerce ». Merci aux éditions Eyrolles ( www.eyrolles.com ) de nous avoir autorisés à publier des extraits du livre à paraître dans ces deux articles.   Le schéma général de la démarche est rappelé sur la figure ci- après, reprenant l’organisation en chapitres du livre précité.

 

Présentation simpli fiée du cas concret servant d’illustration     Le cas concret servant d’illustration à notre démarche agile consiste en la modélisation d’un site Web marchand, en l’occurrence une librairie. La librairie en ligne  constitue en effet un exemple facile à comprendre et suffisamment représentatif des projets e-commerce. Nous nous sommes inspirés des fonctionnalités de sites existants, comme www.amazon.fr , www.fnac.com , et bien sûr celui de notre librairie préférée : www.eyrolles.com ! L’objectif fondamental de tels sites est de permettre aux internautes de rechercher des ouvrages par thème, auteur, mot -clef, etc., de se constituer un panier virtuel, puis de pouvoir les commander et les payer directement sur le Web. Dans le cadre de cet article, nous nous restreindrons à la fonctionnalité de gestion du panier virtuel . Dans un véritable magasin, le client choisit ses articles les uns à la suite des autres, les dépose dans son panier, puis se rend à la caisse pour régler le tout. Les sites Web marchands tentent de reproduire ces habitudes d'achat le plus fidèlement possible. Ainsi, lorsque l'internaute est intére ssé par un ouvrage, il peut l'enregistrer dans un panier virtuel, comme indiqué sur l’exemple de la figure suivante. Il doit pouvoir ensuite à tout moment en ajouter, en supprimer ou encore en modifier les quantités avant de passer commande.

 

Acteurs et cas d’utilisation L’acteur le plus important pour un site d’e-commerce est bien sûr l’internaute . Ses cas d’utilisation principaux ont été mis en évidence par l’expression de besoins préliminaire du paragraphe précédent, à savoir : ?? Rechercher des ouvrages, ?? Gérer son panier,

 

 

?? Effectuer une commande. Nous nous intéresserons plus particulièrement dans la suite de cet article au cas d’utilisation « Gérer son panier », comme illustré sur le diagramme de cas d’utilisation simplifié ci- après.

 

  Nous donnons ci-dessous la description textuelle détaillée du cas d’utilisation qui nous concerne (le style utilisé est celui préconisé par A. Cockburn dans son récent ouvrage de référence : « Rédiger des cas d’utilisation efficaces », Eyrolles, 2001).  

  Préconditions : néant. Scénario nominal :   1. L’Internaute enregistre les ouvrages qui l’intéressent dans un panier virtuel (voir le cas d’utilisation Rechercher des ouvrages). 2. L’Internaute demande l’accès à son panier. 3. Le Système lui affiche l’état de son panier. Chaque ouvrage qui a été préalablement sélectionné est présenté sur une ligne, avec son titre, son auteur et son numéro ISBN. Son prix unitaire est affiché, la quantité est positionnée à « 1 » par défaut, et le prix total de la ligne est calculé. Le to tal de la commande est calculé par le Système et affiché en bas du panier avec l’indication des frais de port. 4. L’Internaute valide son panier en demandant à effectuer une commande. Extensions 3-4a. Le panier est vide

1. Le système affiche un message d’erreur à l’Internaute (« Votre panier est vide ! ») et lui propose de revenir à une recherche d’ouvrage. 4a. L’Internaute modifie les quantités des lignes du panier, ou en supprime. 1. L’Internaute revalide le panier en demandant le recalcul du total 2. Le Système met à jour le total calculé du panier et le cas d’utilisation reprend à l’étape 4 du scénario nominal. 4b. L’Internaute effectue une nouvelle recherche d’ouvrage (voir le cas d’utilisation correspondant). Le cas d’utilisation reprend à l’étape 1 du scénario nominal.     Exigences non-fonctionnelles    Le panier de l’internaute est sauvegardé pendant toute la durée de sa visite sur le site Web.

    Le diagramme de séquence système figure suivante :

d’un scénario représentatif est donné sur la

 

 

Objets métier Comment identifier les concepts du domaine ? Plutôt que de partir à l’aveugle et nous heurter à la taille du problème à résoudre, nous allons prendre les cas d’utilisation un par un et nous poser pour chacun la question suivante : quels sont les concepts métier qui participent à ce cas d’utilisation ?

Par exemple, pour la cas qui nous intéresse ( « Gérer son panier »), nous identifions facilement les concepts métier « Panier » et « Livre ». Nous allons modéliser ces concepts sous forme de diagrammes de classes contenant uniquement des attributs et des associations.

Le concept de panier est un concept du domaine, car dans les librairies réelles le client remplit également un panier avant de passer à la caisse. Le panier est simplement un conteneur des livres sélectionnés par le client. Cependant, nous devons prendre en compte le fait que le client peut choisir plusieurs exemplaires du même livre et que nous voulons le total du panier. Dans notre cas, le prix du panier est calculable simplement à partir du prix des livres sélectionnés, ce qui donne un attribut dérivé « /total » dans la classe Panier. Pour exprimer le fait que le panier

peut contenir plusieurs exemplaires du même livre, nous allons ajouter un concept intermédiaire qui correspond à une ligne du panier et qui concerne donc un seul livre, mais avec un attribut quantité, initialisé à « 1 » par défaut. Le diagramme de classes du domaine résultant est donné ci- après.

 

 

Réalisation des cas d’utilisation : analyse Dans ce paragraphe, nous allons identifier les classes d’analyse qui vont participer à la réalisation des cas d’utilisation. Nous distinguerons trois types de classes d’analyse  (comme proposé par I. Jacobson) : ?? les « dialogues » qui représentent les moyens d’interaction avec le système, ?? les « contrôles » qui contiennent la logique applicative ?? et les « entités » qui sont les objets métier manipulés. Pour compléter ce travail d’identification, nous allons ajouter des attributs et des opérations dans les classes d’analyse, ainsi que des associations entre elles. ?? Les « entités » vont seulement posséder des attributs. Ces attributs représentent en général des informations persistantes de l’application. ?? Les « contrôles » vont seulement posséder des opérations. Ces opérations montrent la logique de l’application, les règles métier, les comportements du système informatique. ?? Les « dialogues » vont posséder des attributs et des opérations. Les attributs vont représenter des champs de saisie ou des résultats. Les résultats seront distingués en utilisant la notation de l’attribut dérivé. Les opérations représenteront des actions de l’utilisateur sur l’IHM. Le diagramme de classes participantes du cas d’utilisation « Gérer son panier » est donné ci- après (l’acteur est relié au dialogue qui est relié au contrôle, lui -même relié aux entités).

Navigation IHM Les IHM modernes, en particulier celles destinées aux internautes via les sites Web marchands, cherchent à faciliter la communication avec l’utilisateur. Elles sont de plus en plus riches et puissantes. Mais cela oblige le concepteur du site à réfléchir de façon très précise au comportement attendu de tous ses éléments graphiques et pas seulement d’un point de vue visuel. UML nous offre la possibilité de représenter formellement la navigation dans le site, au moyen d’un diagramme dynamique appelé diagramme d’activités . Le diagramme d’activités représente ainsi un ajout important dans l’arsenal des outils de modélisation du concepteur de site Web, puisqu’il fournit la possibilité de décrire précisément et exhaustivement les aspects dynamiques de l’interface utilisateur. Un exemple de diagramme d’activités de navigatio n  concernant la gestion du panier est donné ci-dessous.

 

  Remarquez comment nous avons ainsi représenté la règle métier importante consistant à interdire l’accès à la commande dans le cas où le panier est vide.

Réalisation des cas d’utilisation : conceptio n préliminaire Dans ce paragraphe, nous allons maintenant attribuer des responsabilités  précises de comportement aux classes d’analyse identifiées précédemment. Nous représenterons le résultat de cette étude dans des diagrammes d’interactions UML  (séquence ou collaboration). Nous construirons également une vue statique complétée sous forme de diagrammes de classes de conception préliminaire , indépendamment des choix technologiques qui seront effectués au dernier paragraphe. 

Diagrammes d’interaction

L’attribution des bonnes responsabilités aux bonnes classes est l’un des problèmes les plus délicats de la conception orientée- objet. Pour chaque service ou fonction, il faut décider quelle est la classe qui va le contenir. Les diagrammes d’interactions sont particulièrement utiles au concepteur pour représenter graphiquement ses

décisions d’allocation de responsabilités. Chaque diagramme va ainsi représenter un ensemble d’objets de classes différentes collaborant dans le cadre d’un scénario d’exécution du système. Dans ce genre de diagramme, les objets communiquent en s’envoyant des messages  qui invoquent des opérations  (ou méthodes ) sur les objets récepteurs. Il est ainsi possible de suivre visuellement les interactions dynamiques entre objets, et les traitements réalisés par chacun. Par rapport aux diagrammes de séquence système, nous allons remplacer le système vu comme une boîte noire par un ensemble d’objets collaborants. Pour cela, nous utiliserons dans ce paragraphe les trois types de classes d’analyse, à savoir les « dialogues », les « contrôles » et les « entités ». Le changement de niveau   d’abstraction par rapport au diagramme de séquence système peut ainsi se représenter comme sur la figure ci -dessous.

Intéressons- nous au moment où l’internaute met de côté un premier livre dans son panier virtuel. Que se passe-t’il derrière le dialogue concerné ? Celui-ci passe la main à un contrôle spécialisé dans la gestion du panier. Ce contrôle a la responsabilité de créer le panier lors de la p remière sélection mais aussi toutes les lignes du panier au fur et à mesure. Il est également responsable d’afficher un dialogue particulier récapitulant le panier en cours et permettant à l’internaute de le modifier et de le recalculer.  Tout cela est représenté sur la figure suivante (diagramme de séquence).

 

  Pour illustration, le diagramme de collaboration correspondant est également donné ci- après. Notez l’utilisation de la notation graphique UML permettant de représenter une collection d’objets (multi - objets « les : LignePanier »), ainsi que la numérotation décimale des messages indiquant leur imbrication.

Continuons maintenant en considérant un scénario dans lequel l’internaute modifie la quantité d’un ouvrage sélectionné, puis demande un recalcul de son panier. Le contrôle reçoit une collection de quantités et la passe à l’entité panier. Celui-ci est responsable de la gestion de ses lignes. Il va donc demander à chaque ligne de se recalculer individuellement en lui passant en paramètre la quantité qui la concerne. Si cette quantité a été positionnée à zéro par l’internaute, la ligne est supprimée.

 

Pour terminer la gestion du panier, considérons enfin un scénario dans lequel l’internaute supprime explicitement une ligne du panier puis le vide totalement.

  Diagrammes de classes de conception préliminaire