Ici, nous allons apprendre à faire le diagramme de cas d'utilisation. Il a pour but de définir le système avec les différentes interactions entre les utilisateurs et ce dernier. Il nous permet donc de bien trouver les limites de notre système.

Pour aborder les différentes notions, nous diviserons le diagramme de cas d'utilisation en 3 niveaux : 

• Débutant
• Intermédiaire
• Avancé

 Cela nous permettra de ne pas vous surcharger avec de nombreuses notions.

Pour tous nos diagrammes, nous utiliserons le même cas que nous approfondirons (plus ou moins en fonction du niveau que vous étudiez). Elle sera basée sur un sujet disponible ici (de Mme Blay, ensaignante à l'IUT de Nice).
Il y aura une correction des différents niveaux mais retenez bien qu'il n'y a pas une unique solution lors de la modélisation. Cependant, lorsque l'on a un sujet écrit comme ici, il ne faut pas imaginer des informations qui ne nous sont pas fournies par le sujet.

• Débutant
• Intermédiaire
• Avancé (Partie 1)
• Avancé (Partie 2)

• Débutant

  Étude de cas niveau débutant

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  MyWaze doit permettre à un « conducteur » de s’identifier, visualiser la carte, spécifier un itinéraire, d’envoyer un message et de recevoir un message. Pour ce qui concerne les messages, MyWaze ne gère pas lui-même les messages mais utilise un système de messagerie externe.

  Analyser le sujet

  Lors de la lecture du sujet, il faut réussir à filtrer les informations est à garder seulement les informations nécessaire. Nous allons donc essayer d'épurer le sujet. Je vais donc vous montrer ce qu'il faut retenir du sujet.

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  MyWaze doit permettre à un « conducteur » de s’identifier, visualiser la carte, spécifier un itinéraire, d’envoyer un message et de recevoir un message. Pour ce qui concerne les messages, MyWaze ne gère pas lui-même les messages mais utilise un système de messagerie externe.

  Nous retenons donc que les éléments barrés sont juste de la mise en contexte. Pour ce qui est des parties en gras, cela représente ce que l'on va devoir modéliser dans notre diagramme de cas d'utilisation.
  Maintenant, nous allons construire ensemble votre premier diagramme de cas d'utilisation. 

  Ici nous avons notre premier acteur le "conducteur" que nous nommerons utilisateur (c'est un choix de ma part qui n'est pas obligatoire). Mais si vous faites cela, il faudra le spécifier dans le glossaire. Si vous ne savez pas encore ce qu'est un glossaire je vous invite à voir à quoi sert et comment faire un glossaire ici.
  Notre utilisateur peut s’identifier, visualiser la carte, spécifier un itinéraire, envoyer un message car notre MyWaze (notre système) le lui permet. Tout cela représente donc des cas d'utilisation. Si vous vous demandez pourquoi "recevoir un message" ne fait pas un cas d'utilisation, c'est que pour moi, l'utilisateur ne demande pas au système de recevoir un message mais il le fait automatiquement. Une fois de plus, ce genre de décision est à préciser dans le glossaire. 
  Il nous reste une chose à ne pas oublier, c'est notre acteur externe. Ici, c'est notre système de messagerie externe. Comme on nous dit que " MyWaze ne gère pas lui-même les messages", nous savons qu'il y a une relation entre "envoyer un message" et notre acteur externe "système de messagerie externe".
  
  Il ne nous reste maintenant plus qu'à placer les cardinalités. Comme nous l'avons vu dans l'explication des notions, les cardinalités du côté de notre utilisateur et de notre système de messagerie externe sont toujours égales à 1 car ils ne peuvent effectuer qu'une seule fois la tâche en même temps. Du côté du cas d'utilisation, lorsqu'il provient de :
  
  

  • l'utilisateur, la cardinalité est 0..1 car le cas d'utilisation est soit effectuer par l'utilisateur soit il ne l'est pas.
  • le système de messagerie externe, la cardinalité est 0..* car le système peut envoyer des groupes de messages en même temps.

  On obtient donc le diagramme de cas d'utilisation suivant :

  

• Intermédiaire

  Étude de cas niveau intermédiaire

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  MyWaze doit permettre à un « conducteur » de s’identifier, visualiser la carte, spécifier un itinéraire, d’envoyer un message et de recevoir un message. Pour ce qui concerne les messages, MyWaze ne gère pas lui-même les messages mais utilise un système de messagerie externe. Un conducteur n’a pas besoin de s’identifier pour demander à visualiser une carte, mais dans tous les autres cas c’est indispensable. De plus lorsqu’il visualise la carte, le système lui propose de se connecter. Il peut s’identifier soit par un mot de passe, soit en utilisant des périphériques extérieurs comme un lecteur d’empreintes digitales. Le conducteur doit pouvoir commander le boitier à la voix ou au toucher.

  Un administrateur peut configurer le boitier pour l’associer à un conducteur en précisant les informations sur ses réseaux sociaux (par exemple, le compte « chut » sur Twitter, « NSA » sur google+, etc.). Il doit également pouvoir créer de nouveaux modèles de messages, dits « créatifs », en modifier ou en détruire. Un modèle de messages peut être soit prédéfini et dans ce cas, il s’agit des modèles de messages fournis par MyWaze (accident, bouchon, …), soit « créatif » et dans ce cas nous nous nous limitons aux modèles de messages sur Twitter ou par Email.

  Analyser le sujet

  Lors de la lecture du sujet, il faut réussir à filtrer les informations est à garder seulement les informations nécessaire. Nous allons donc essayer d'épurer le sujet. Je vais donc vous montrer ce qu'il faut retenir du sujet.

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  MyWaze doit permettre à un « conducteur » de s’identifier, visualiser la carte, spécifier un itinéraire, d’envoyer un message et de recevoir un message. Pour ce qui concerne les messages, MyWaze ne gère pas lui-même les messages mais utilise un système de messagerie externe. Un conducteur n’a pas besoin de s’identifier pour demander à visualiser une carte, mais dans tous les autres cas c’est indispensable. De plus lorsqu’il visualise la carte, le système lui propose de se connecter. Il peut s’identifier soit par un mot de passe, soit en utilisant des périphériques extérieurs comme un lecteur d’empreintes digitales. Le conducteur doit pouvoir commander le boitier à la voix ou au toucher.

  Nous retenons donc que les éléments barrés sont juste de la mise en contexte. Pour ce qui est des parties en gras, cela représente ce que l'on va devoir modéliser dans notre diagramme de cas d'utilisation.
  Maintenant, nous allons construire ensemble votre deuxième diagramme de cas d'utilisation. 

  Ici nous avons notre premier acteur le "conducteur" que nous nommerons utilisateur (c'est un choix de ma part qui n'est pas obligatoire). Mais si vous faites cela, il faudra le spécifier dans le glossaire. Si vous ne savez pas encore ce qu'est un glossaire je vous invite à voir à quoi sert et comment faire un glossaire ici.
  Notre utilisateur peut s’identifier, visualiser la carte, spécifier un itinéraire, envoyer un message ainsi que commander le boitier car MyWaze (notre système) le lui permet. Tout cela représente donc des cas d'utilisation. Si vous vous demandez pourquoi "recevoir un message" ne fait pas un cas d'utilisation, c'est que pour moi, l'utilisateur ne demande pas au système de recevoir un message mais il le fait automatiquement. Une fois de plus, ce genre de décision est à préciser dans le glossaire. 

  Maintenant, nous allons voir s'il n'y a pas de généralisation, d'extend ou encore d'include. Vers le milieu du texte, on apprend qu'il est nécessaire de se connecter pour tous les cas d'utilisation sauf pour le "Visualiser la carte". Le fait qu'il soit nécessaire nous informe donc de la présence d'include entre tous les cas d'utilisation (sauf "Visualiser la carte") et "S'identifier". Ensuite, on identifie une possibilité qui est offerte à l'utilisateur par la phrase suivante "lorsqu’il visualise la carte, le système lui propose de se connecter". Or lorsqu'il sagit d'une proposition, cela cache souvent des extends. On ajoute donc un extend entre "Visualiser la carte" et "S'identifier". On termine en observent dans les deux dernières phrases des indices nous permettant de déceler des généralisations. Cela est marqué par un choix qui est obligatoire pour effectuer le cas d'utilisation. On l'observe ici "s’identifier soit par un mot de passe, soit en utilisant des périphériques extérieurs" et "commander le boitier à la voix ou au toucher". On ajoute donc cela à notre diagramme.

  Il nous reste une chose à ne pas oublier, c'est notre acteur externe. Ici, c'est notre système de messagerie externe. Comme on nous dit que " MyWaze ne gère pas lui-même les messages", nous savons qu'il y a une relation entre "envoyer un message" et notre acteur externe "système de messagerie externe".

  Il ne nous reste maintenant plus qu'à placer les cardinalités. Comme nous l'avons vu dans l'explication des notions, les cardinalités du côté de notre utilisateur et de notre système de messagerie externe sont toujours égales à 1 car ils ne peuvent effectuer qu'une seule fois la tâche en même temps. Du côté du cas d'utilisation, lorsqu'il provient de :

  • l'utilisateur, la cardinalité est 0..1 car le cas d'utilisation est soit effectuer par l'utilisateur soit il ne l'est pas.
  • le système de messagerie externe, la cardinalité est 0..* car le système peut envoyer des groupes de messages en même temps.

  Maintenant que nos cas d'utilisations sont terminés pour notre utilisateur, concentrons nous sur les cas d'utilisations de l'administrateur. 

   Un administrateur peut configurer le boitier pour l’associer à un conducteur en précisant les informations sur ses réseaux sociaux (par exemple, le compte « chut » sur Twitter, « NSA » sur google+, etc.). Il doit également pouvoir créer de nouveaux modèles de messages, dits « créatifs », en modifier ou en détruire. Un modèle de messages peut être soit prédéfini et dans ce cas, il s’agit des modèles de messages fournis par MyWaze (accident, bouchon, …), soit « créatif » et dans ce cas nous nous nous limitons aux modèles de messages sur Twitter ou par Email.

  Dans cette partie, nous apprenons que nous avons un deuxième acteur "l'Utilisateur". Ce dernier peut éditer des modèles de messages ainsi que configurer des boitiers. Cela représente deux nouveaux cas d'utilisation. Nous apprenons aussi qu'il existe deux types de modèle créatif et prédéfini et qu'un modèle est forcement de l'un de ces deux types. Nous avons donc l'apparition de généralisation. La dernière chose que l'on apprend ici est que le modèle créatif comporte deux plateformes possible soit Twitter, soit par Email. Comme vous l'avez compris, voici encore une nouvelle généralisation. On obtient donc le diagramme suivant : 

  

• Avancé (Partie 1)

  Diagramme de cas d'utilisation

  Étude de cas niveau avancé

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  MyWaze doit permettre à un « conducteur » de s’identifier, visualiser la carte, spécifier un itinéraire, d’envoyer un message et de recevoir un message. Pour ce qui concerne les messages, MyWaze ne gère pas lui-même les messages. Un conducteur n’a pas besoin de s’identifier pour demander à visualiser une carte, mais dans tous les autres cas c’est indispensable. De plus lors de sa connexion, l’utilisateur peut visualiser la carte. Sa connexion peut se passer de deux façons différentes :

  • par un mot de passe,
  • par périphériques externe (comme un lecteur d’empreintes digitales).

   Le conducteur doit pouvoir commander le boitier à la voix ou au toucher. Le conducteur peut aussi commander le boitier au moment où il consulte ces messages.

  MyWaze propose aussi un compte premium qui permet aux clients premium en plus d’avoir leurs avantages de client classique d’autres avantages comme appeler le service de dépannage 24/24 géré par un système de téléphonie externe, commander en ligne en passant par un service de vente externe, enregistrer des adresses dans leurs GPS. Tous cela requière leur connexion sauf pour enregistrer des adresses. 

  Un administrateur peut configurer le boitier pour l’associer à un conducteur en précisant les informations sur ses réseaux sociaux (par exemple, le compte « chut » sur Twitter, « NSA » sur google+, etc.). Il peut le configurer de deux manières possibles, soit à l’aide d’un autre logiciel, soit directement en ligne de commande. Il doit également pouvoir créer de nouveaux modèles de messages, dits « créatifs », en modifier ou en détruire. Un modèle de messages peut être soit prédéfini et dans ce cas, il s’agit des modèles de messages fournis par MyWaze (accident, bouchon, …), soit « créatif » et dans ce cas nous nous nous limitons aux modèles de messages sur Twitter ou par Email.

  Analyser le sujet

  Lors de la lecture du sujet, il faut réussir à filtrer les informations est à garder seulement les informations nécessaire. Nous allons donc essayer d'épurer le sujet. Je vais donc vous montrer ce qu'il faut retenir du sujet.

  Votre rôle est de spécifier un nouveau système informatique à embarquer dans toutes les voitures connectées : MyWaze ! Vous avez vu un GPS ? Vous avez utilisé GoogleMap ? Vous connaissez MyWaze ? Au volant, pas toujours facile à utiliser... Vous avez déjà Twitté ? Vous avez parfois envoyé un email, un SMS ? Envoyé une photo sur Instagram ? Jamais en conduisant évidemment !! Et bien nous allons construire un boitier embarqué dans votre voiture qui vous permettra de faire tout cela en conduisant.

  MyWaze doit permettre à un « conducteur » de s’identifier, visualiser la carte, spécifier un itinéraire, d’envoyer un message et de recevoir un message. Pour ce qui concerne les messages, MyWaze ne gère pas lui-même les messages mais utilise un système de messagerie externe. Un conducteur n’a pas besoin de s’identifier pour demander à visualiser une carte, mais dans tous les autres cas c’est indispensable. De plus lorsqu’il visualise la carte, le système lui propose de se connecter. Il peut s’identifier soit par un mot de passe, soit en utilisant des périphériques extérieurs comme un lecteur d’empreintes digitales. Le conducteur doit pouvoir commander le boitier à la voix ou au toucher.  Le conducteur peut aussi commander le boitier au moment où il consulte ses messages.

  Nous retenons donc que les éléments barrés sont juste de la mise en contexte. Pour ce qui est des parties en gras, cela représente ce que l'on va devoir modéliser dans notre diagramme de cas d'utilisation.
  Maintenant, nous allons construire ensemble votre deuxième diagramme de cas d'utilisation. 

  Ici nous avons notre premier acteur le "conducteur" que nous nommerons utilisateur (c'est un choix de ma part qui n'est pas obligatoire). Mais si vous faites cela, il faudra le spécifier dans le glossaire. Si vous ne savez pas encore ce qu'est un glossaire je vous invite à voir à quoi sert et comment faire un glossaire ici.
  Notre utilisateur peut s’identifier, visualiser la carte, spécifier un itinéraire, envoyer un message, recevoir un message ainsi que commander le boitier car MyWaze (notre système) le lui permet. Tout cela représente donc des cas d'utilisation. 

  Maintenant, nous allons voir s'il n'y a pas de généralisation, d'extend ou encore d'include. Vers le milieu du texte, on apprend qu'il est nécessaire de se connecter pour tous les cas d'utilisation sauf pour le "Visualiser la carte". Le fait qu'il soit nécessaire nous informe donc de la présence d'include entre tous les cas d'utilisation (sauf "Visualiser la carte") et "S'identifier". Ensuite, on identifie une possibilité qui est offerte à l'utilisateur par la phrase suivante "lorsqu’il visualise la carte, le système lui propose de se connecter". Or lorsqu'il sagit d'une proposition, cela cache souvent des extends. On ajoute donc un extend entre "Visualiser la carte" et "S'identifier". On termine en observent dans les trois dernières phrases. Des indices nous permettent de déceler des généralisations. Cela est marqué par un choix qui est obligatoire pour effectuer le cas d'utilisation. On l'observe ici "s’identifier soit par un mot de passe, soit en utilisant des périphériques extérieurs" et "commander le boitier à la voix ou au toucher". On ajoute donc cela à notre diagramme.
  On observe aussi dans la dernière phrase que l'utilisateur "peut commander le boitier au moment où il consulte ses messages". Là encore, on remarque donc l'existence d'un extend que l'on rajoute. 

  Il nous reste une chose à ne pas oublier, c'est notre acteur externe. Ici, c'est notre système de messagerie externe. Comme on nous dit que " MyWaze ne gère pas lui-même les messages", nous savons qu'il y a une relation entre "envoyer un message" et notre acteur externe "système de messagerie externe".

  Il ne nous reste maintenant plus qu'à placer les cardinalités. Comme nous l'avons vu dans l'explication des notions, les cardinalités du côté de notre utilisateur et de notre système de messagerie externe sont toujours égales à 1 car ils ne peuvent effectuer qu'une seule fois la tâche en même temps. Du côté du cas d'utilisation, lorsqu'il provient de :

  • l'utilisateur, la cardinalité est 0..1 car le cas d'utilisation est soit effectuer par l'utilisateur soit il ne l'est pas.
  • le système de messagerie externe, la cardinalité est 0..* car le système peut envoyer des groupes de messages en même temps.

  À présent, nous allons nous intéresser à notre utilisateur premium. 

  MyWaze propose aussi un compte premium qui permet aux clients premium en plus d’avoir de leurs avantages de client classique d’autres avantages comme appeler le service de dépannage 24/24  géré par un système de téléphonie externe, commander en ligne en passant par un service de vente externe, enregistrer des adresses dans leurs GPS. Tous cela requière leur connexion sauf pour enregistrer des adresses.

  Voilà l'arrivée de notre second acteur "l'Utilisateur premium". Ce dernier possède les mêmes droits que l'utilisateur. Cela signifie donc qu'il existe une relation de généralisation entre les deux acteurs. En plus de cela, on apprend que l'utilisateur premium a trois nouveaux cas d'utilisation : appeler le service de dépannage 24/24, commander en ligne, enregistrer des adresses. 
  Maintenant, cherchons si il y a des extends, includes ou généralisation dans ces nouveaux cas d'utilisation. La phrase " requière leur connexion sauf pour enregistrer des adresses" nous apprend que la connexion est requise pour deux des trois nouveaux cas d'utilisation. On ajoute donc deux include. 
  Il ne nous reste à présent qu'a chercher s'il y a des acteurs externes pour nos utilisateurs premium. Dans ce texte, on nous informe clairement que le dépanage 24/24 ainsi que la commande en ligne nécessite deux acteurs externes.  Pour le dépanage, l'acteur externe est déjà présent. Il suffit alors de le relier. Mais pour la commande, il va falloir ajouter une nouvel acteur externe, "service de vente externe" puis relier le tout.

  Maintenant que nos cas d'utilisation sont terminés pour notre utilisateur premium, terminons sur les cas d'utilisations de l'administrateur. 

   Un administrateur peut configurer le boitier pour l’associer à un conducteur en précisant les informations sur ses réseaux sociaux (par exemple, le compte « chut » sur Twitter, « NSA » sur google+, etc.). Il doit également pouvoir créer de nouveaux modèles de messages, dits « créatifs », en modifier ou en détruire. Un modèle de messages peut être soit prédéfini et dans ce cas, il s’agit des modèles de messages fournis par MyWaze (accident, bouchon, …), soit « créatif » et dans ce cas nous nous nous limitons aux modèles de messages sur Twitter ou par Email.

  Dans cette partie, nous apprenons que nous avons un troisième acteur "l'Utilisateur". Ce dernier peut éditer des modèles de messages ainsi que configurer des boitiers. Cela représente deux nouveaux cas d'utilisation. Nous apprenons aussi qu'il existe deux types de modèle créatif et prédéfini et qu'un modèle est forcement de l'un de ces deux types. Nous avons donc l'apparition de généralisation. La dernière chose que l'on apprend ici est que le modèle créatif comporte deux plateformes possible soit Twitter, soit par Email. Comme vous l'avez compris, voici encore une nouvelle généralisation. On obtient donc le diagramme suivant : 

  

• Avancé (Partie 2)

  Flots des cas d'utilisations : "S'identifier" et "Commander en ligne"

  Pour effectuer nos différents flots de nos deux cas d'utilisations, nous n'aurons pas besoin du diagramme de cas d'utilisation complet mais seulement des deux cas d'utilisations. Je vous les remets donc ici isolé des autres. 

   

  Si vous souhaitez les faire seul avant de voir la réponse, n'allez pas plus loin.

   

  Cas d'utilisation : S'identifier

  Précondition :
  Avoir un compte.

  Flot basique :

  1) L’internaute saisit vocalement ou textuellement son login et son mot de passe.
  L’internaute saisit « Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. » et « test ».
  2) Le système interroge le gestionnaire de base de données pour savoir si le login et le mot de passe sont dans la base de données.
  Requête.
  3) Le gestionnaire de base de données lui indiquer que le compte est bien existant.
  Retour booléen.
  4) Le système amène l’internaute sur son compte client.
  5) L’internaute a donc accès à son compte client.

  Flot alternatif :

  3.1) Le gestionnaire de base de données indique que le login ou mot de passe entré par l’internaute est incorrect.
  a) Le système indique que le compte est inexistant.
  b) Retour au flot 1.

  Flot d’erreur :

  3.1) Le gestionnaire de base de données ne répond pas.
  a) Le système indique qu’il est impossible de se connecter pour le moment.
  b) Le flot se termine en échec.

  Postcondition :
  L’internaute est connecté au système.

  Cas d'utilisation : Commander

  Précondition :
  Le client doit s‘être identifié à son compte.
  Le client doit avoir au moins un article dans son panier.

  Flot basique :

  1) Le client demande à avoir sa commande.
  Le client demande vocalement ou clique sur « commande ».
  2) Le système lui lit le contenu de sa commande.
  3) Le client confirme vocalement ou textuellement sa commande pour passer au paiement.
  Le client demande vocalement ou clique sur « confirmer ma commande ».
  4) Le système propose différentes possibilités de paiement ainsi que de livraison.
  Le système affiche « PayPal, Carte bleu… En relais, a domicile… ».
  5) Le client choisi le lieu de livraison et la méthode de paiement.
  Le client envoie « PayPal, a domicile ».
  6) Le système fait appel au système de paiement externe choisi.
  Requête.
  7) Le système de paiement externe confirme le paiement.
  Retour booléen.
  8) Le système enregistre le paiement, la date ainsi que le contenu de la commande.
  Le système stock « 22/02/2018, 500euros… ».
  9) Le système envoie un mail et le lit avec la facture au client.
  Le système envoie « Bonjour Monsieur, Merci pour votre commande de … le … ».

  Flot alternatif :

  7.1) Le système externe de paiement refuse le paiement.
  a) Le système indique au client que son paiement a été refusé.
  Le système dit « paiement refusé ».
  b) Le système propose de retourner au niveau du choix de la méthode de paiement ou d’annuler sa commande.
  1.a) Le client choisit de retourner au niveau du choix de la méthode de paiement.
  1.b) Retour au flot 4.
  2.a) Le client choisit d’annuler sa commande.
  2.b) Le flot se termine

  7.2) Le système externe de paiement ne répond pas.
  a) Le système indique qu’il est impossible de se payer avec ce moyen de paiement pour le moment.
  b) Le système demande si le client souhaite utiliser un autre moyen de paiement.
  1.a) Le client souhaite utiliser un autre moyen de paiement.
  1.b) Retour flot 4.
  2.a) Le client choisit d’annuler sa commande.
  2.b) Le flot se termine.

  Flot d’erreur :

  7.1) Aucun système externe de paiement répond.
  a) Le système indique qu’il n’est pas possible de payer pour le moment.
  b) Le flot se termine en échec.
  
  Post condition :
  Le client a effectué son paiement et ainsi son achat en ligne.