IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

UML Discussion :

Conseil Use case et diagramme d'activité


Sujet :

UML

  1. #1
    Membre habitué Avatar de touftouf57
    Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2007
    Messages
    362
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 362
    Points : 174
    Points
    174
    Par défaut Conseil Use case et diagramme d'activité
    Bonjour a tous,

    Pourriez-vous me donner votre avis concernant ce use case

    Je me demande si je dois inclure l'acteur développeur car il n'agit pas sur le système.C'est le systeme qui le contacte, mais lui en retour, il ne fait rien.

    Que pensez-vous de ce diagramme d'activité


    Je trouve bizarre comme modélisation. En fait cela représente le use case ModifierRegle qui est étendu par beaucoup d'autres. La post condition de ModifierRegle est que la règle est modifiée, logique. Les moyens de modifier une règle sont multiples, d'ou tous les extends du use case. L'auriez-vous modéliser de la sorte?

    Toute critique est la bienvenue. J'essaye de comprendre et d'apprendre. Là ou j'ai le plus de mal avec UML est la modélisation des use case et diagrammes d'activité. Après pour ce qui est des diagrammes de séquence, collaboration et état, j'ai beaucoup moins de mal car j'ai des objets et je vois comment vont s'enchainer les appels.

    Déjà si vous comprenez le "but" de cette application, c'est que je ne suis pas complètement à la ramasse.

    Merci pour vos critiques et remarques.

  2. #2
    Membre habitué Avatar de tonton16
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Novembre 2003
    Messages
    90
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2003
    Messages : 90
    Points : 185
    Points
    185
    Par défaut
    Bonjour,

    Les <<extend>> reliés au cas "Modifier un règle" sont faux car ils ne doivent pas représenter une décomposition fonctionnelle, ce sont des sous-fonctionnalités au cas "Modifier...". Il vaux mieux passer par un sous-diagramme. Dans Visual Paradigm, on crée un sous-diagramme en passant par la vue explorateur de modèles.

    Les 2 <<include>> qui vont vers le cas "Modifier un règle" sont également faux. Cela revient à dire que pour créer ou consulter une règle, il est obligatoire de modifier la règle .

    Si l'acteur "Développeur" n'agit pas sur le système, on le laisse à droite du système et éventuellement on modifie la navigabilité.

    Pour le diagramme d'activité, les barres noires (fork/join) signifient que les actions qui vont suivre vont se réaliser simultanément (threads). Dans votre cas, les actions se réalisent séquentiellement, dont on les relie entre elles directement dans l'ordre de réalisation et s'il y a une alternative (si/alors/sinon), on utilise des nœuds de décision/fusion (losange).

    Cordialement.
    Si vous pensez que ma réponse est utile pour vous et pour les autres utilisateurs du forum, pensez à voter.

  3. #3
    Membre habitué Avatar de touftouf57
    Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2007
    Messages
    362
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 362
    Points : 174
    Points
    174
    Par défaut
    Merci tonton16 pour ta "critique", mais elle soulève d'autres questions.

    Citation Envoyé par tonton16 Voir le message
    Les <<extend>> reliés au cas "Modifier un règle" sont faux car ils ne doivent pas représenter une décomposition fonctionnelle, ce sont des sous-fonctionnalités au cas "Modifier...". Il vaux mieux passer par un sous-diagramme. Dans Visual Paradigm, on crée un sous-diagramme en passant par la vue explorateur de modèles.
    Je ne comprend pas trop ce que tu veux me dire.
    Dis-moi si je me trompe. Il faudrait que je fasse un sous diagramme de use case à "Modifier une Règle"?
    J'aurais donc comme acteur, toujours mon administrateur et comme use cases, ceux qui était en extend de "Modifier une règle", exact?

    Citation Envoyé par tonton16 Voir le message
    Les 2 <<include>> qui vont vers le cas "Modifier un règle" sont également faux. Cela revient à dire que pour créer ou consulter une règle, il est obligatoire de modifier la règle .
    Parfaitement d'accord, le include est de trop.

    Citation Envoyé par tonton16 Voir le message
    Si l'acteur "Développeur" n'agit pas sur le système, on le laisse à droite du système et éventuellement on modifie la navigabilité.
    Navigabilité?? Là, je ne vois pas du tout de quoi tu parles? En termes UML, si un acteur n'interragit pas sur le système, il n'a rien à faire dans le use case? Je prend l'exemple d'une bibliothèque. Si les demandes des Abonnés se font à la bibliothécaire. Il n'y aura que la bibliothécaire comme acteur et aucun <<acteur>>Abonné.

    Citation Envoyé par tonton16 Voir le message
    Pour le diagramme d'activité, les barres noires (fork/join) signifient que les actions qui vont suivre vont se réaliser simultanément (threads). Dans votre cas, les actions se réalisent séquentiellement, dont on les relie entre elles directement dans l'ordre de réalisation et s'il y a une alternative (si/alors/sinon), on utilise des nœuds de décision/fusion (losange).
    Exactement, je ne sais pas ce que j'ai foutu là!
    Mais si je suis ton idée de sous diagramme, dans l'éventualité ou j'ai bien compris ce que tu disais, ce diagramme d'activité est-il toujours correct?

    Encore merci

  4. #4
    Membre habitué Avatar de tonton16
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Novembre 2003
    Messages
    90
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2003
    Messages : 90
    Points : 185
    Points
    185
    Par défaut
    Citation Envoyé par touftouf57 Voir le message
    Je ne comprend pas trop ce que tu veux me dire.
    Dis-moi si je me trompe. Il faudrait que je fasse un sous diagramme de use case à "Modifier une Règle"?
    J'aurais donc comme acteur, toujours mon administrateur et comme use cases, ceux qui était en extend de "Modifier une règle", exact?
    C'est exact.

    Citation Envoyé par touftouf57 Voir le message
    Navigabilité?? Là, je ne vois pas du tout de quoi tu parles? En termes UML, si un acteur n'interragit pas sur le système, il n'a rien à faire dans le use case? Je prend l'exemple d'une bibliothèque. Si les demandes des Abonnés se font à la bibliothécaire. Il n'y aura que la bibliothécaire comme acteur et aucun <<acteur>>Abonné.
    Pour la navigabilité, en gros c'est que l'association est représentée sous forme de flèche (--->) vers l'acteur (sur VP, mettre "non défini" pour la navigabilité du côté du use case).
    Par convention, on met les acteurs principaux à gauche et ils représentent les acteurs qui interagissent directement avec le use case et les acteurs secondaires (de second plan) à droite pour ceux qui participent au cas d'utilisation mais qui ne le déclenchent pas.

    Citation Envoyé par touftouf57 Voir le message
    Exactement, je ne sais pas ce que j'ai foutu là!
    Mais si je suis ton idée de sous diagramme, dans l'éventualité ou j'ai bien compris ce que tu disais, ce diagramme d'activité est-il toujours correct?
    Ben, je ne comprends pas exactement le processus de modification d'un règle, mais je n'aurais pas mis de fork/join. Peux-tu décrire le scenario de ton cas d'utilisation ?

    Citation Envoyé par touftouf57 Voir le message
    Encore merci
    De rien.
    Si vous pensez que ma réponse est utile pour vous et pour les autres utilisateurs du forum, pensez à voter.

  5. #5
    Membre habitué Avatar de touftouf57
    Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2007
    Messages
    362
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 362
    Points : 174
    Points
    174
    Par défaut
    Le scénario nominal de "modifier une règle":
    1. L'administrateur sélectionne un règle
    2. Le système affiche la règle
    3. L'administrateur modifie la règle
    4. Le système affiche la règle modifiée

    .....


    Ok! en écrivant cela, je crois comprendre ou tu voulais en venir. Il n'existe pas de "scénario nominal" pour ce use case.
    En fait la post condition de modifier est tout simplement que la règle est ...modifiée mais pas encore sauvegardée, enregistrée, persistée.

    C'est exactement la même chose qu'un fichier excel que l'on vient de créer et que l'on a modifié (saisie de valeur, mise en forme, insertion de colonne,...) sans avoir encore fait de sauvegarde.

    Les extends devraient donc plutôt être des spécialisations, exact?

  6. #6
    Membre habitué Avatar de tonton16
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Novembre 2003
    Messages
    90
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2003
    Messages : 90
    Points : 185
    Points
    185
    Par défaut
    Citation Envoyé par touftouf57 Voir le message
    Le scénario nominal de "modifier une règle":
    1. L'administrateur sélectionne un règle
    2. Le système affiche la règle
    3. L'administrateur modifie la règle
    4. Le système affiche la règle modifiée
    Le scénario qui m'intéresse ici, en fait, c'est ce que tu fais dans ton 3. Si on prend ton premier diagramme, tu parles de lignes, de colonnes et de cellules.

    Les 2 premières lignes peuvent être considérées comme une pré-condition, le règle créée est une post-condition.

    Citation Envoyé par touftouf57 Voir le message
    Ok! en écrivant cela, je crois comprendre ou tu voulais en venir. Il n'existe pas de "scénario nominal" pour ce use case.
    En fait la post condition de modifier est tout simplement que la règle est ...modifiée mais pas encore sauvegardée, enregistrée, persistée.
    Il existe forcément un scénario nominal pour un cas d'utilisation, des scénarios alternatifs et des scénarios d'erreur. Exemple fictif :
    1. l'acteur créé une ligne
    2. L'acteur créé une colonne
    3. l'acteur modifie la 1ère cellule...

    En fait on décrit les interactions séquentielles entre l'acteur du cas d'utilisation et le système représenté pas ce cas d'utilisation.

    Citation Envoyé par touftouf57 Voir le message
    C'est exactement la même chose qu'un fichier excel que l'on vient de créer et que l'on a modifié (saisie de valeur, mise en forme, insertion de colonne,...) sans avoir encore fait de sauvegarde.
    A ce niveau, on se fiche un peu de la façon dont on gère la persistance. A la limite, ce qui nous intéresse c'est que l'acteur fait l'action de d'enregistrer la règle.

    Citation Envoyé par touftouf57 Voir le message
    Les extends devraient donc plutôt être des spécialisations, exact?
    Non.
    Après réflexion, ce ne sont pas forcément des cas d'utilisation, car ils n'apportent un plus-value métier à l'acteur. A priori, ils représentent plutôt des lignes de tes scénarios.

    Recherche sur le net comment rédiger correctement des scénarios.
    Si vous pensez que ma réponse est utile pour vous et pour les autres utilisateurs du forum, pensez à voter.

  7. #7
    Membre habitué Avatar de touftouf57
    Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2007
    Messages
    362
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 362
    Points : 174
    Points
    174
    Par défaut
    Citation Envoyé par tonton16 Voir le message
    Le scénario qui m'intéresse ici, en fait, c'est ce que tu fais dans ton 3. Si on prend ton premier diagramme, tu parles de lignes, de colonnes et de cellules.
    Et bien dans mon 3 je fais soit:
    • Ajouter une colonne
    • Ajouter une ligne
    • Modifier la valeur d'une cellule
    • ....

    En fait un des <<extends>> de "Modifier une Regle".

    Je cherche à avoir le même comportement qu'excel. Comment modéliserais-tu le diagramme use case d'excel?

    Citation Envoyé par tonton16 Voir le message
    Il existe forcément un scénario nominal pour un cas d'utilisation, des scénarios alternatifs et des scénarios d'erreur. Exemple fictif :
    1. l'acteur créé une ligne
    2. L'acteur créé une colonne
    3. l'acteur modifie la 1ère cellule...
    Je suis d'accord, mais vu le nombre de combinaisons possibles
    • {ajouter ligne, ajouter colonne,...}
    • {ajouter colonne, ajouter ligne,...}
    • {ajouter colonne, Modifier type colonne,...}
    • ...

    Il n'y a pas un réel scénario nomimal. Qu'est ce qui ferait que {ajouter ligne, ajouter colonne,..} soit plus nominal que {ajouter colonne, ajouter ligne,...}?

    Citation Envoyé par tonton16 Voir le message
    A ce niveau, on se fiche un peu de la façon dont on gère la persistance. A la limite, ce qui nous intéresse c'est que l'acteur fait l'action de d'enregistrer la règle.
    Je sais bien que l'on se fiche de la façon de gérer la persistence, c'était juste pour préciser le comportement, avec un exemple connu. En fait la modification est "temporaire". Elle ne sera effective que lorsque l'utilisateur enregistrera la Regle.

    Citation Envoyé par tonton16 Voir le message
    Recherche sur le net comment rédiger correctement des scénarios.
    J'ai trouvé ceci. En aurais-tu un autre à me conseiller?

Discussions similaires

  1. conseils use case
    Par PiNkjeLLy dans le forum Cas d'utilisation
    Réponses: 24
    Dernier message: 08/02/2013, 17h01
  2. passage de uses case au diagramme de séquence
    Par mwalia dans le forum Cas d'utilisation
    Réponses: 1
    Dernier message: 31/10/2012, 10h51
  3. Réponses: 4
    Dernier message: 04/08/2010, 14h14
  4. Diagramme d'activité : détail des Use Case ?
    Par Kevin12 dans le forum Cas d'utilisation
    Réponses: 6
    Dernier message: 29/11/2008, 14h23
  5. [UML] Use cases - Votre avis sur un diagramme.
    Par atome dans le forum Cas d'utilisation
    Réponses: 8
    Dernier message: 10/10/2006, 19h22

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