Analyse du besoin

Introduction

Dans ce premier TD, il fut question d'analyse du besoin , ce qui correspond à la mise en conception à partir du Cahier des Charges Fonctionnel (CdCF). Celui-ci formulant le besoin au moyen de fonctions détaillant les services attendus et les contraintes auxquelles le produit à fournir est soumis. Cette partie représente le cœur de l’analyse. Il est composé de cas d’utilisation et d'un contexte statique. On y décrit donc le contexte, les acteurs ou utilisateurs du projet logiciel, les fonctionnalités du logiciel mais aussi les interactions entre ces acteurs et ces fonctionnalités.

Notions

  • Acteur : Un acteur représente le rôle d'une entité externe (utilisateur humain ou non) interagissant avec le système.

  • Cas d'utilisation : Relation entre un acteur et le système qui exprime une interaction.

  • Diagramme de contexte statique : Le diagramme de contexte sert à délimiter le contour du système en cours d'étude, de définir clairement ses frontières et les acteurs avec lesquels il communique.

Étude de cas

Description initiale : La galerie d'art

  1. Nous voulons informatiser une galerie d'art, par laquelle nous souhaitons vendre des oeuvres d'arts à des clients. Les paiements doivent être sécurisés en utilisant le système de paiement externe “chaimoinscheir”.
  2. Les oeuvres et les artistes sont gérés par les administrateurs via des interfaces adaptées.
  3. Un internaute doit pouvoir s'inscrire sur le site pour devenir client.
  4. Un internaute peut naviguer sur le site : retrouver un artiste par son nom, visualiser les oeuvres par artiste ou par catégorie.
  5. Les clients peuvent voter pour les oeuvres ou les artistes qu'ils préfèrent.
  6. Une fois par jour, un super-administrateur déclenche une opération de sauvegarde de la galerie.
  7. L'identification des clients fait partie du système de la galerie.
  8. Un client peut téléphoner à la secrétaire pour demander l'édition d'une facture consécutive à une vente passée.

Questions à se poser :Cliquez sur une des question pour en voir la réponse.

  • Quel est le système concerné ?

  • Qui sont les acteurs ?

  • Quels sont les cas d’utilisation ?


Identifier les acteurs intervenant sur les cas d'utilisation peut représenter une véritable problématique. Pour vous aider, voici quelques questions qui vous permettrons plus facilement d'identifier les acteurs de votre système :

  • Quels sont les utilisateurs qui ont besoins d'un système pour réaliser le travail ?
  • Quels sont les utilisateurs qui vont effectuer les fonctions principales du système ?
  • Quels sont les utilisateurs qui vont exécuter les fonctions principales du système (maintenance et administration) ?
  • Est-ce que le système interagit avec du matériel ou d'autres logiciels ?

L'ensemble des cas d'utilisation doit décrire exhaustivement les exigences fonctionnelles du système. Chaque cas d'utilisation correspond donc à une fonction métier du système, selon le point de vue d'un de ses acteurs. Aussi, pour identifier les cas d'utilisation, il faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se sert du système. Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon niveau d'abstraction. Trouver le bon niveau de détail pour les cas d'utilisation est un problème difficile qui nécessite de l'expérience.


Diagramme de contexte statique

Le diagramme de contexte statique délimite le domaine d’étude en précisant ce qui est à la charge du système et en identifiant l’environnement extérieur au système étudié avec lequel ce dernier communique.
Ses composants sont :

  • Les acteurs externes : entité externe au système étudié qui interagit avec le système.
  • Un processus unique symbolisant le Système d'Information étudié :
  • Échange entre le système étudié et son environnement

Notre Système d'Information : la galerie d'art

À noter : On représente les interactions des acteurs avec le système étudié. Mais pas les interactions entre acteurs.


Identification des cas d'utilisation

Après avoir représenté les relations entre le système et les acteurs, nous allons déterminer les cas d’utilisation. Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un système. Il est une unité significative de travail. Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas d'utilisation (use cases).

Diagramme de cas d'utilisation de la galerie d'art :

À noter : le plus souvent, le diagramme des cas est établi par le maître d'ouvrage d'un projet lors de la rédaction du cahier des charges afin de transmettre les besoins des utilisateurs et les fonctionnalités attendues associées au maître d'œuvre.

Question : Comment exprimer l’obligation ? la possibilité ? l’héritage ? Ces trois élément permettre d'instaurer un système de relation entre les cas d'utilisation, chose que vous allons voir.


Description textuelle

La description textuelle d'un cas d'utilisation permet de détailler ce qui se passe entre l’acteur et le système lorsque le cas d’utilisation est exécuté. Cela correspond à un flot d'événement, qui peut prendre plusieurs cas de figure :

  • Flot nominal : Déroulement classique de l'événement, les actions s'enchainent jusqu'à la terminaison de l'évènement.

  • Flot alernatif : Une façon d'effectuer le cas d'utilisation par d'autre évènement, mais qui en déroule une terminaison identique.

  • Flot d’exception : Une suite d'évènement provoquant une erreur finale, une terminaison incorrecte de l'évènement.

Flot nominal : Un internaute s'inscrit pour devenir client de la galerie d'art
  1. L'internaute saisit son nom, son prénom, son adresse email ;
  2. Le système valide ces informations (bien construites) ;
  3. Le système enregistre le nouveau client ;
  4. Le système signale au client que tout s'est bien passé.

À noter : le retour vers l'acteur est quasi obligatoire dans tout scénario, sous peine de définir un système qui n'est pas assez explicite

Flots alernatif : Un internaute s'inscrit pour devenir client de la galerie d'art

L'enchaînement A1 démarre au point 2 du scénario nominal.

  1. Le système indique à l'internaute que les données sont invalides ;
  2. Le scénario nominal reprend au point 1.

L'enchaînement A2 démarre au point 3 du scénario nominal.

  1. Le système indique à l'internaute qu'un client avec les mêmes informations est déjà connu du système ;
  2. Le système propose à l'internaute de ressaisir les informations ;
  3. Le scénario nominal reprend au point 1.


Description d'un cas d'utilisation : Acheter des œuvres

Ce cas d'utilisation permet à un client d'acheter des oeuvres d'art en se déplaçant sur le site via l'utilisation d'un panier.
Aperçu : Un Client sélectionne des oeuvres qu’il met dans son panier. Le Client demande à passer commande. Le système vérifie la disponibilité des oeuvres et bloque leur vente. Il calcule le montant de la commande…

Client (principal) ; système de paiement (secondaire)

Le 1 mars 2015

Le 8 mars 2015

1.0.1

M. Dupont

Le client est authentifié et est autorisé à faire des achats en lignes.
La gestion des stocks est correcte et seules des oeuvres en stock sont sélectionnables.

  1. Le client a sélectionné un mode de navigation.
  2. Le système propose les oeuvres d’art.
  3. Le client sélectionne des oeuvres d’art (cf. sous Flot S1 : Sélectionner)
  4. Le client demande à acheter.
  5. Le contenu du panier est réservé dans les stocks.
  6. Le système demande au système de paiement l’encaissement du panier.
  7. Le système de paiement valide le paiement et retourne une facture.
  8. Le système enregistre le retrait du stock.
  9. Le système confirme l’achat au client

Flot alternatif n°1 : Aucune oeuvre n'est sélectionnée :. L'enchaînement A1 démarre au point 4 du flot nominal.

  1. Le système signale au client qu'aucune oeuvre n'est sélectionnée.
  2. Le scénario nominal reprend au point 2.
Flot alternatif n°2 : Une ou plusieurs œuvres ont déjà été réservées :. L'enchaînement A2 démarre au point 4 du flot nominal.
  1. Le système signale au client qu'une œuvre et déjà réservée et invite à la supprimer de la commande
  2. L'utilisateur supprime l'œuvre de sa commande
  3. Le scénario nominal reprend au point 2.

Flot d'erreur n°1 : Le système de paiement est indisponible

L'enchaînement E1 démarre au point 5 du flot nominal.
  1. Le système relâche le contenu du panier : les oeuvres contenues dans le panier ne sont plus réservées.
  2. Le système signale le problème au client.
Le cas d'utilisation se termine en échec.

Les oeuvres vendues ne sont plus en stock.
La facture est bien associée au client et aux oeuvres vendues.

  • Temps de réponse : La transaction entre le la demande d'achat par le client et la validation du paiement ne peut pas excéder 15mn.

  • Concurrence : Plusieurs achats simultanés par des clients différents sont possibles grâce à la réservation des oeuvres le temps de la transaction financière. Néanmoins pour des raisons de surcharge et de contrat avec le système de paiement, il ne sera pas possible d'avoir plus de 100 demandes simultanées d'achats.(Flot d'erreur à rajouter).

  • Disponibilité : Le système sera disponible 7j/7, 24h/24. L'indisponibilité du système de paiement n'empêchera pas la mise en oeuvre des premières étapes du scénario…

  • Confidentialité : L'ensemble de la navigation d'un client sera sécurisée.


Relation entre cas d'utilisation

Afin de mettre en place le système d'information de la galerie d'art, nous devons respecter plusieurs exigences (ou spécifications). Elles se traduisent, dans le cas des cas d'utilisation, par des relation entre ces derniers. Trois types de relations sont prises en charge par la norme UML et sont graphiquement représentées par différentes types de flèche : L'inclusion (obligation), l'extension (posibilité) et la généralisation (héritage). Elles ont été au préalable inclues dans le diagramme d'utilisation ci-dessus, mais nous allons les synthétiser :

Spécifications de la galerie d'art

  1. Pour acheter ou voter, un client doit s'être authentifié.
  2. Un internaute qui désire voter est invité à s'inscrire sur le site.
  3. La visualisation des oeuvres peut consister en une navigation “classique” dans les oeuvres, une navigation dans un espace virtuel en 3D où les oeuvres sont présentées par thèmes, un catalogue “virtuel”, ou des options de recherche avancées .
  4. Un super administrateur est un administrateur.
  5. Avant de valider sa commande un client peut consulter la popularité des oeuvres dans son panier.

Passer la souris sur une des spécification pour en voir la relation

Une relation d'inclusion (Include) implique une obligation entre deux cas d'utilisation, autrement dit entre deux actions. Si l'action (ou encore l'étape) A implique, oblige, d'avoir effectué au préalable l'action B, alors le cas d'utilisation B inclut le cas d'utilisation A.

Une relation d'extension (Extend) propose une option à un cas d'utilisation étendu avec un autre. Le second sera l'option du premier. Dit de manière plus rigoureuse, l'extension représente un prolongement logique de certaines tâches sous certaines conditions.

Une relation de généralisation (ou de spécialisation) représente l'héritage. Le cas d'utilisation A est une généralisation de B, si B est un cas particulier de A c'est-à-dire lorsque A peut être substitué par B pour un cas précis. Dans ce cas, B hérite de tout les attributs de A et en propose généralement d'autres, spécifiques à B. Ces relations sont des traits pleins terminés par une flèche en triangle. Attention, la seule relation possible entre acteurs est celle-ci.