Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2018
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2018
    Messages : 23
    Points : 10
    Points
    10

    Par défaut Cas d'utilisation et documentation textuelle

    Voici le scénario :

    À l'achat d'un nouveau véhicule, le chef de parc procède à son enregistrement. Le chef de parc ajoute le véhicule à la flotte de l'entreprise. Le chef de parc peut supprimer le véhicule en cas de vente de ce dernier, de la liste des véhicules du parc automobile. Le chef de parc peut modifier et consulter le véhicule. Le chef service patrimoine et le responsable structure (directeur) peuvent consulter aussi le véhicule.

    C'est peut-être une perte de temps de s'attarder sur les relations stéréotypées dans le diagramme de cas d'utilisation, mais je voudrais tout de même éclaircir ce point, d'autant plus que cela va m'aider lors de la description textuelle des cas d'utilisation.

    Donc voici ma proposition pour le diagramme de cas d'utilisation:

    Nom : Screenshot_20180921_153532.png
Affichages : 93
Taille : 48,1 Ko

    Et la documentation des cas d'utilisation :

    =========================================================

    Cas d’utilisation :
    S’authentifier
    Acteurs : Administrateur et autres utilisateurs.
    Objectif : Il permet à l’acteur de s’identifier en saisissant son login et mot de passe.
    Précondition : L’acteur doit être présent dans la base de données.
    Postcondition :
    -Acteur authentifié.
    -La page d’accueil s’affiche.

    Scénario nominal :
    1. L’acteur ouvre l’application,
    2. Le système affiche la page d’authentification,
    3. L’acteur saisit le login et le mot de passe,
    4. Le système vérifie l’existence des données,
    5. Le système affiche la page d’accueil.

    Scénario alternatif :
    A. Erreur d’authentification : login ou mot de passe non valide.
    Cet enchaînement démarre au point 4.
    5. Le système affiche un message d’erreur.
    Le scénario reprend au point 2.
    B. Champs obligatoires vides.
    Cet enchaînement démarre au point 4.
    Le scénario reprend au point 2.

    ==========================================================

    Cas d’utilisation : Ajouter véhicule
    Acteurs : Chef de parc
    Objectif : Il permet au chef de parc d’ajouter un véhicule.
    Précondition : Succès d’authentification.
    Postcondition : Véhicule ajouté.
    Scénario nominal :
    1. Le chef de parc choisit l’ajout d’un nouveau véhicule,
    2. Le système affiche le formulaire à remplir,
    3. Le chef de parc saisit les informations à remplir sur le nouveau véhicule,
    4. Le système vérifie les données,
    5. Le système enregistre le véhicule dans la base de données.
    Scénario alternatif :
    A. Champs obligatoires non valides ou vides.
    Cet enchaînement démarre au point 4.
    5. Le système affiche un message d’erreur.
    Le scénario reprend au point 2.

    ============================================================

    Cas d’utilisation : Modifier véhicule
    Acteurs : Chef de parc
    Objectif : Il permet au chef de parc de modifier un véhicule.
    Précondition :
    -Succès d’authentification.
    -Succès de consultation de la liste des véhicules.
    Postcondition : Véhicule modifié.
    Scénario nominal :
    1. Le chef de parc choisit d’affiche la « Liste des véhicules »,
    2. Le système affiche la liste,
    3. Le chef de parc choisit la modification d’un véhicule,
    4. Le système affiche le formulaire de modification,
    5. Le chef de parc modifier les informations de véhicule,
    6. Le système demande la validation de modification,
    7. Le chef de parc valide la modification,
    8. Le système vérifie les données,
    9. Le système enregistre la modification dans la base de données.
    Scénario alternatif :
    A. Champs obligatoires non valides ou vides.
    Cet enchaînement démarre au point 8.
    9. Le système affiche un message d’erreur.
    Le scénario reprend au point 5.

    ===========================================================

    Cas d’utilisation : Supprimer véhicule
    Acteurs : Chef de parc
    Objectif : Il permet au chef de parc de supprimer un véhicule.
    Précondition :
    -Succès d’authentification.
    -Succès de consultation de la liste des véhicules.
    Postcondition : Véhicule supprimé.
    Scénario nominal :
    1. Le chef de parc choisit d’afficher la « Liste des véhicules »,
    2. Le système affiche la liste,
    3. Le chef de parc choisit la suppression d’un véhicule,
    4. Le système demande la validation de la suppression,
    5. Le chef de parc valide la suppression,
    6. Le système procède à la suppression du véhicule de la base de données.
    Scénario alternatif :
    A. Le chef de parc annule la suppression.
    Cet enchaînement démarre au point 4.
    9. Le système affiche une notification.
    Le scénario reprend au point 2.

    ================================================================

    Cas d’utilisation : Consulter la liste des véhicules
    Acteurs : Chef de parc, Chef service patrimoine, Responsable structure
    Objectif : Il permet aux acteurs de consulter la liste des véhicules.
    Précondition : Succès d’authentification.
    Postcondition : Aucune.
    Scénario nominal :
    1. L’utilisateur choisit d’afficher la liste des utilisateurs,
    2. Le système affiche la liste des véhicules,
    3. Le système vérifie le type d’utilisateur connecté (si chef de parc ou chef service patrimoine ou responsable structure),
    4. Si l’utilisateur est le chef de parc, le système fait appel aux cas d’utilisation interne « Modifier véhicule » et « Supprimer véhicule ».
    Scénario alternatif : Aucun.

    =====================================================================

    Cas d’utilisation : Gérer les véhicules
    Acteurs : Chef de parc
    Objectif : Il permet au chef de parc de gérer les véhicules.
    Précondition : Succès d’authentification.
    Postcondition : Aucune.
    Scénario nominal :
    1. Le système fait appel au cas d’utilisation interne « Ajouter véhicule ».
    Scénario alternatif : Aucun.

    =======================================================================

    Mes questions portent principalement sur les deux derniers cas d'utilisation documentés ; sont-ils bien documentés ? est-il intéressant de les garder ?
    Quelles améliorations apporter au diagramme de cas d'utilisation ?
    La documentation des cas d'utilisation est-elle bien faite ?
    Quand on modifie ou supprime un véhicule on consulte la liste des véhicules. Je trouve des difficultés à documenter ce point particulier des cas d'utilisation.

  2. #2
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2005
    Messages
    3 469
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2005
    Messages : 3 469
    Points : 6 569
    Points
    6 569

    Par défaut

    Bonjour,

    Vous faites l'erreur classique qui est de penser qu'un acteur est une personne, ce n'est pas le cas, un acteur représente d'abord un rôle
    Un rôle peut être tenu par plusieurs personnes, et une personne peut avoir plusieurs rôles

    Donc "le système vérifie .." n'a par définition pas de sens, pourquoi diantre avoir mis la suppression et la modification en extension de la consultation ?

    L'énoncé indique qu'il n'y a que deux rôles vis à vis des UCs :
    • l'un permettant d'ajouter / supprimer /modifier des véhicules
    • l'autre permettant de consulter la liste des véhicules


    le 1er rôle ne peut être tenu que par le chef de parc
    le second par le chef de parc, le chef de service, et le directeur

    Autre erreur classique, l'include vers l'authentification, un include indique une action obligatoirement faite, donc dans votre diagramme à chaque fois qu'un véhicule est géré il faut s'authentifier ce qui est évidemment faux. Il ne faut pas non plus remplacer l'include pas un extend car l'authentification doit être faite avant, c'est donc un pré requis qui apparait dans les description textuelle.
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  3. #3
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2018
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2018
    Messages : 23
    Points : 10
    Points
    10

    Par défaut

    Bonjour,

    Je vous remercie pour votre intervention et vos éclaircissements.

    Vous avez raison, j'ai fait l'erreur de confondre (personne) et (acteur). Pour moi, il fallait représenter tous les postes de travail et je n'ai pas pensé au rôle.
    Si je vous suis dans votre explication, il y a deux rôles :
    -Chef de parc,
    -Utilisateur qui hérite du chef de parc, responsable structure et le chef service patrimoine.

    Appliquer l'héritage sur les acteurs est-il plus intéressant que l'appliquer sur les cas d'utilisation ?
    Peut-on regrouper Ajouter/Modifier/Supprimer un véhicule dans un cas d'utilisation et qu'elle sera la dépendance à ce moment là ?

    Pourquoi avoir mis une relation stéréotypée « extend » entre Consulter la liste des véhicules et Modifier/Supprimer un véhicule :
    Je prévois d'inclure ces deux fonctionnalités (suppression et modification d'un véhicule) lors de l'affichage de la liste des véhicules. On fera donc appel à ces deux fonctionnalités au moment de parcourir les véhicules si on est un chef de parc. Mais je vous rejoins sur l'idée que ce n'est pas très clair et que dire que le système vérifie quel est l'utilisateur connecté ne convient pas.

    Voici le nouveau diagramme de cas d'utilisation réalisé à l'aide de votre outil BOUML, je vous en remercie :

    Nom : v2.png
Affichages : 63
Taille : 36,4 Ko


    Pour ce qui est de la description textuelle :

    Peut-on définir un cas d'utilisation Gérer les véhicules et y inclure Ajouter un véhicule, Supprimer un véhicule et Modifier un véhicule comme des enchaînements dans le scénario nominal ? Dans ce cas, on aura qu'à définir un seul cas d'utilisation de haut niveau Gérer les véhicules qui inclut l'ajout, la modification et la suppression.

  4. #4
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2005
    Messages
    3 469
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2005
    Messages : 3 469
    Points : 6 569
    Points
    6 569

    Par défaut

    Citation Envoyé par subrms Voir le message
    Si je vous suis dans votre explication, il y a deux rôles :
    -Chef de parc,
    -Utilisateur qui hérite du chef de parc, responsable structure et le chef service patrimoine.
    oui, le seul bémol est "utilisateur" qui est un nom avec une sémantique quasi nulle, il faudrait trouver quelque chose de plus proche du rôle

    Citation Envoyé par subrms Voir le message
    Appliquer l'héritage sur les acteurs est-il plus intéressant que l'appliquer sur les cas d'utilisation ?
    ni plus ni moins, dans le cas présent l'héritage entre acteur était la bonne solution

    Citation Envoyé par subrms Voir le message
    Peut-on regrouper Ajouter/Modifier/Supprimer un véhicule dans un cas d'utilisation ?
    non, le but des UC c'est de dire ce que le système doit permettre de faire, donc séparer ces trois actions est une bonne chose

    Citation Envoyé par subrms Voir le message
    Pourquoi avoir mis une relation stéréotypée « extend » entre Consulter la liste des véhicules et Modifier/Supprimer un véhicule :
    Je prévois d'inclure ces deux fonctionnalités (suppression et modification d'un véhicule) lors de l'affichage de la liste des véhicules. On fera donc appel à ces deux fonctionnalités au moment de parcourir les véhicules si on est un chef de parc.
    Attention, les UCs détaillent le but, et là on rendre plutôt dans l'implémentation

    Citation Envoyé par subrms Voir le message
    dire que le système vérifie quel est l'utilisateur connecté ne convient pas.
    encore une fois parce qu'on est au niveau UC, par contre il est très probable que cela sera fait par l'implémentation, mais c'est une autre histoire

    Citation Envoyé par subrms Voir le message
    Voici le nouveau diagramme de cas d'utilisation réalisé à l'aide de votre outil BOUML
    j'avais reconnu

    non seulement il est correct, mais en plus il est plus simple



    Citation Envoyé par subrms Voir le message
    Pour ce qui est de la description textuelle :

    Peut-on définir un cas d'utilisation Gérer les véhicules et y inclure Ajouter un véhicule, Supprimer un véhicule et Modifier un véhicule comme des enchaînements dans le scénario nominal ? Dans ce cas, on aura qu'à définir un seul cas d'utilisation de haut niveau Gérer les véhicules qui inclut l'ajout, la modification et la suppression.
    encore une fois ce n'est pas une bonne chose de regrouper alors que le but est de détailler

    "gérer" c'est comme "utilisateur", c'est trop vague, demander de but en blanc à quelqu'un ce que veut "gérer un véhicule" et vous aurez toutes les réponses possible y compris le conduire ou le laver

    par contre "ajouter à la liste", "retirer de la liste", "modifier description" ou des choses comme ca et c'est déjà plus clair même si bien sûr la description textuelle reste nécessaire
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  5. #5
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2018
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2018
    Messages : 23
    Points : 10
    Points
    10

    Par défaut

    Je vous remercie, je comprends mieux l'utilité du diagramme de cas d'utilisation et des relations stéréotypées. C'est vrai que j'étais en train de réfléchir à l'implémentation. Le besoin de la gestion des véhicules n'est pas le seul de mon projet de stage, il me reste : la gestion des réparations, des entretiens, des assurances, des fournisseurs/prestataires, des utilisateurs, des accidents. Il y a des ressemblances bien évidemment avec la gestion des véhicules.

    non seulement il est correct, mais en plus il est plus simple
    Le modèle est plus simple et la documentation l'est aussi.

    Qu'en pensez-vous de ces deux rôles ?

    -Le gestionnaire de parc qui hérite du chef de parc,
    -L'utilisateur de la gestion de parc qui hérite du chef de parc, responsable structure et le chef service patrimoine.

    Voici la nouvelle version du modèle :

    Nom : v3.png
Affichages : 63
Taille : 37,5 Ko

  6. #6
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2018
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2018
    Messages : 23
    Points : 10
    Points
    10

    Par défaut

    Autre question :
    Dans la documentation et lors de l'étape de l'identification des acteurs, le rôle d'un acteur n'a aucune signification, c'est bien ça ? Le rôle n'a de signification que dans le diagramme de cas d'utilisation. On parlera alors d'acteur et non de rôle y compris dans la description textuelle des cas d'utilisation, c'est bien ça ?

  7. #7
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2005
    Messages
    3 469
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2005
    Messages : 3 469
    Points : 6 569
    Points
    6 569

    Par défaut

    Citation Envoyé par subrms Voir le message
    Qu'en pensez-vous de ces deux rôles ?

    -Le gestionnaire de parc qui hérite du chef de parc,
    -L'utilisateur de la gestion de parc qui hérite du chef de parc, responsable structure et le chef service patrimoine.

    Voici la nouvelle version du modèle :
    ...
    Dans ma première réponse je voulais d'abord vous présenter cette solution, puis j'avais changé d'avis pour minimiser le nombre d'acteurs
    Cette solution convient donc aussi

    Citation Envoyé par subrms Voir le message
    Dans la documentation et lors de l'étape de l'identification des acteurs, le rôle d'un acteur n'a aucune signification, c'est bien ça ?
    Il y a toujours un/des rôle(s) associé(s) à un acteur, quand vous avez ajouté/identifié vos deux nouveaux acteurs vous l'avez fait en pensant à leur rôle associé, donc pas d'accord.
    Citation Envoyé par subrms Voir le message
    Le rôle n'a de signification que dans le diagramme de cas d'utilisation. On parlera alors d'acteur et non de rôle y compris dans la description textuelle des cas d'utilisation, c'est bien ça ?
    Oui on parle d'acteur et de cas d'utilisation, mais un acteur n'existe que via les rôles qu'il rempli, les deux sont indissociables, un acteur sans rôle associé cela n'a pas de sens
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  8. #8
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2018
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2018
    Messages : 23
    Points : 10
    Points
    10

    Par défaut

    Je vous remercie pour ces éclaircissements. Je vais m'attaquer à la modélisation d'autres cas et la prochaine étape : le diagramme de classes UML.

  9. #9
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 013
    Points : 31 723
    Points
    31 723
    Billets dans le blog
    5

    Par défaut

    Si je peux me permettre, moi le merisien plus habitué aux bases de données qu'à l'UML...
    il y a deux rôles :
    -Chef de parc,
    -Utilisateur qui hérite du chef de parc, responsable structure et le chef service patrimoine.
    C'est plutôt le contraire, il me semble : le chef de parc, le responsable structure et le chef service patrimoine héritent de Utilisateur. Ils sont capables de faire tout ce que fait l'utilisateur (la consultation de véhicule) et ils ont leurs cas d'utilisation propres (création, modification,suppression d'un véhicule).

    subrms, nous en avions déjà parlé par ailleurs !

    Pour le diagramme de classe, j'ai déplacé les messages dans une nouvelle discussion.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  10. #10
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2005
    Messages
    3 469
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2005
    Messages : 3 469
    Points : 6 569
    Points
    6 569

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    Si je peux me permettre, moi le merisien plus habitué aux bases de données qu'à l'UML...

    C'est plutôt le contraire, il me semble : le chef de parc, le responsable structure et le chef service patrimoine héritent de Utilisateur. Ils sont capables de faire tout ce que fait l'utilisateur (la consultation de véhicule) et ils ont leurs cas d'utilisation propres (création, modification,suppression d'un véhicule).
    oui, dans le diagramme les héritages sont dans le bon sens mais il sont inversés dans le texte
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  11. #11
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2018
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2018
    Messages : 23
    Points : 10
    Points
    10

    Par défaut

    Bonjour. Excusez mon absence.
    J'ai pris en compte vos précieuses remarques et corrigé la description textuelle, encore merci. Je vais mettre la discussion en résolue =)

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Aide ! - Description textuelle du cas d'utilisation
    Par Laidback dans le forum Cas d'utilisation
    Réponses: 7
    Dernier message: 17/05/2012, 16h48
  2. Inclusion d'un diagramme de cas d'utilisation dans un document LaTeX
    Par noussaENSI dans le forum Tableaux - Graphiques - Images - Flottants
    Réponses: 14
    Dernier message: 15/08/2006, 23h03
  3. [Modélisation] Cas d'utilisation et acteurs
    Par ftrifiro dans le forum Cas d'utilisation
    Réponses: 5
    Dernier message: 30/01/2005, 16h20
  4. cas d'utilisation
    Par Yveke dans le forum Cas d'utilisation
    Réponses: 7
    Dernier message: 23/12/2004, 11h27
  5. [corba] débutant : dans quels cas l'utiliser
    Par jmturc dans le forum CORBA
    Réponses: 2
    Dernier message: 10/10/2002, 09h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo