Conseil Use case et diagramme d'activité

Version imprimable

03/12/2012, 02h06
touftouf57

Conseil Use case et diagramme d'activité

Bonjour a tous,

Pourriez-vous me donner votre avis concernant ce use case
http://www.developpez.net/forums/u203794-a399-i1349.png
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é
http://www.developpez.net/forums/u203794-a399-i1347.png

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.
03/12/2012, 10h08
tonton16

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 :aie:.

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.
03/12/2012, 11h49
touftouf57

Merci tonton16 pour ta "critique", mais elle soulève d'autres questions.

Citation:

Envoyé par tonton16

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

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 :aie:.

Parfaitement d'accord, le include est de trop.

Citation:

Envoyé par tonton16

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

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à! :fessee:
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
03/12/2012, 12h49
tonton16

Citation:

Envoyé par touftouf57

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

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

Exactement, je ne sais pas ce que j'ai foutu là! :fessee:
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

Encore merci

De rien.
03/12/2012, 21h47
touftouf57

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

.....
:weird:

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?
05/12/2012, 00h16
tonton16

Citation:

Envoyé par touftouf57

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

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

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

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.
05/12/2012, 09h04
touftouf57
Citation:

Envoyé par tonton16

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

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

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

Recherche sur le net comment rédiger correctement des scénarios.

J'ai trouvé ceci. En aurais-tu un autre à me conseiller?