Discussion :

[mim933]

Bonjour à tous, j'ai un projet à faire pour une école

La mise en place d'un service de cours accessible par toute l'école. J'explique vite faire le principe.

L'école veut mettre à la disposition des élèves des cours. Voila les possibilité

Utilisateur quelconque

Consulter les cours

Utilisateur enregistré

Commenter les cours

Noter les cours

Rédacteur

Créer un cours

Modifier un cours

Faire une demande de publication

Rédacteur en chef

Accepter une demande de publication

Administrateur

Supprimer un utilisateur

Modifier les droits d'un utilisateur

Donc j'ai fait un diagramme de cas d'utilisation. Je voudrais savoir ce que vous en pensez et si cela vous semble être correct.

[bruno_pages]

Bonjour,

il va falloir que quelqu'un crée un smiley pour indiquer cela plus rapidement car à force de le répéter cela devient lassant : l’authentification n'est pas un UC inclus mais un UC don't l'exécution est un prérequis pour d'autres, car il n'y a pas de contrainte temporelle au niveau de l'inclusion or l’authentification doit évidemment être faite au début.

vos autres inclusions ne sont pas non plus valides, par exemple ce n'est pas parce qu'un cours doit exister pour pouvoir être modifié que l'UC de création est (forcément) exécuté dans l'UC de modification

[mim933]

Tout d'abord je te remercie de t'être penché sur mon post.

Donc ce que je dois comprendre c'est que l'authentification n'est pas une fonctionnalité en soit mais juste une nécessité. Par contre non pas que je veuille remettre en question ce que tu me dis, mais sur plusieurs livres sur UML, il y a bien un cas d'utilisation "S'authentifier" qui n'est pas directement relié à un acteur mais à un autre cas d'utilisation par le biais d'une inclusion. Sans compter mon prof d'informatique qui a un peu la même approche. M'aurait on menti ? Enfin tu me dis que mes autres cas d'inclusion ne sont pas bons. Dans quel cas utiliser alors "include" parce que je me sens un peu perdu tout à coup et beaucoup moins sûr de moi même.

[bruno_pages]

l'authentification est un bien un UC, mais il n'est pas inclus, son exécution est un pré requis (préalable) à d'autres, cela ce dit dans la description textuelle les UCs en question. L'erreur le concernant est classique.

UC1 ---<<include>>---> UC2 veut dire que l'UC2 est obligatoirement appelé pendant l'exécution de UC1, par contre on ne sait pas quand, d'où le problème avec authentification qui doit être faite avant / au début et non n'importe quand pendant

li y a des cours/tutoriels UML sur ce site, levez les yeux pour voir les boutons en partie haute de la page

[mim933]

l'authentification est un bien un UC, mais il n'est pas inclus, son exécution est un pré requis (préalable) à d'autres, cela ce dit dans la description textuelle les UCs en question. L'erreur le concernant est classique.

UC1 ---<<include>>---> UC2 veut dire que l'UC2 est obligatoirement appelé pendant l'exécution de UC1, par contre on ne sait pas quand, d'où le problème avec authentification qui doit être faite avant / au début et non n'importe quand pendant

li y a des cours/tutoriels UML sur ce site, levez les yeux pour voir les boutons en partie haute de la page

Justement les tutoriaux ne donnent pas plus de solutions et nous induisent en erreur. Par exemple http://ego.developpez.com/uml/tutoriel/casUtilisation/ explique bien l'erreur qui est commise avec l'inclusion, mais ne donne pas d'exemple concret et le petit diagramme UC suivant :

nous induit en erreur parce que finalement nous ne savons pas si il est un exemple d'inclusion ou un exemple d'erreur à ne pas commettre.

[kiza44]

Bonjour,

Si je comprends bien, l'authentification serait donc un sous-cas d'utilisation à gérer à part, l'acteur devient alors un "utilisateur authentifié" ? C'est bien ça ?

[bruno_pages]

bonjour,

je ne sais pas trop ce que vous voulez dire par 'sous-cas', l’authentification est un cas d'utilisation que vous pouvez montrer dans un diagramme avec un acteur client-non-authentifier (ou simplement client si vous préférez) et dans les autres cas correspondants à votre diagramme ci-dessus l'acteur devient effectivement client-authentifié (ou seulement client qui est plus facile à lire, le tout étant de ne pas avoir le même nom d'acteur avant et après authentification)

[Philippe Bastiani]

C'est qu'en même bizarre cette manie de vouloir inclure l'authentification dans chaque UC ! Et, pourquoi pas AUSSI inclure les UCs de configuration dans chaque UC ?

On comprend bien
- qu'il ne faut pas systématiquement "créer un compte" à chaque fois que l'on veut "faire un publication"
De même
- qu'il ne faut pas systématiquement "s'authentifier" à chaque fois que l'on veut "faire un publication" (A moins d'être une exigence, tu ne vas qu'en même pas forcer X authentifications si tu publies X documents).

=> avoir créé un compte et s'être authentifié sont donc des préalables à l'exécution de l'UC "faire une publication"

Posez-vous toujours les questions:
- est-ce que l'exécution de UCxx est nécessaire à l'exécution de mon UC ?
- est-ce que l'exécution de UCxx doit être exécutée pendant l'exécution de mon UC ?

C'est vrai... beaucoup de tutos et livres sont trompeur sur ce sujet. Pour reprendre le cas de l'automate classique:
- pour pouvoir retirer une ou plusieurs fois de l'argent
et / ou
- pour pouvoir consulter une ou plusieurs fois son compte
il faut s'être authentifié un seule et unique fois... c'est donc une condition préalable !

Cdlt,
Philippe

[kamylex]

bonsoir,

j'ai lu sur un site "Introduction à la modélisation orientée objets
avec UML
Olivier Sigaud
Edition 2005-2006" que la relation (include) est employé quand deux use case ont en commun une même fonctionnalité et que l'on souhaite factorisé celle-ci en créant un sous-cas ou un cas intermédiaire, afin de marquer les différences d’utilisation. est-ce que cette définition est correct?

[bruno_pages]

Bonjour,

oui, c'est correct, reste à l'utiliser à bon escient

[montesq]

En ce qui me concerne, je ne mets jamais le cas "s'authentifier" dans un diagramme de cas d'utilisation.
C'est une position discutable, mais:

1° cela allourdit grandement le diagramme car quasiment tous les cas d'utilisations sont reliés à "s'authentifier"

2° on comprend bien qu'a priori s'il y a différents acteurs, il doit y avoir à un moment ou à un autre un moyen d'authentification...

3° je considère que c'est une "fonctionnalité technique" (par opposition à une fonctionnalité métier) donc cela n'a pas sa place dans ce diagramme dont la vocation est de présenter une vision globale du système.

Par contre, il est bien sûr nécessaire que l'authentification se retrouve dans les descriptions des cas d'utilisation.

Je ne conseille d'ailleurs pas non plus d'utiliser les relations d'include et d'extend car elles apportent souvent peu à la compréhension d'autant plus qu'elles sont en général mal utilisées/mal comprises. Encore une fois, ces "détails" doivent nécessairement apparaître dans la description des cas d'utilisations.

[bruno_pages]

Je ne conseille d'ailleurs pas non plus d'utiliser les relations d'include et d'extend car elles apportent souvent peu à la compréhension d'autant plus qu'elles sont en général mal utilisées/mal comprises. Encore une fois, ces "détails" doivent nécessairement apparaître dans la description des cas d'utilisations.

déjà que le diagramme d'UC ne montre pas grand chose, le limiter ainsi est vraiment discutable, et cela ressemble à une position extrême dont la logique abouti à l'absence totale de diagramme puisque de toute façon tout doit apparaître dans leur description.

[montesq]

déjà que le diagramme d'UC ne montre pas grand chose, le limiter ainsi est vraiment discutable, et cela ressemble à une position extrême dont la logique abouti à l'absence totale de diagramme puisque de toute façon tout doit apparaître dans leur description.

Au contraire, le diagramme de cas d'utilisation est pour moi le plus utile et le plus incontournable! Il permet de synthétiser les besoins auxquels doit satisfaire le système en répondant aux questions :
Qui (doit utiliser le système)?
Quoi? (=quelles fonctionnalités doit proposer le système?)
A ce titre, ce diagramme s'utilise à la manière d'un préambule/introduction ou d'un sommaire de ce qui va ensuite être la description de la solution via l'écriture détaillée des cas d'utilisation. Et donc, décrire un système avec UML et sans diagramme de cas d'utilisations, c'est comme écrire un livre sans plan : bon courage
Il doit donc être compréhensible par tous les acteurs du projet. Or, les subtilités des termes <include> et <exclude> sont peu parlants pour des intervenants métiers (en tout cas pour ceux que j'ai rencontré). De plus ces principes sont mal maîtrisés par de nombreux membres de ce forum comme le montre le cas présent.

D'autre part, la partie description des cas d'utlisation (=description de la solution) répond à la question:
Comment (l'utilisateur agit pour exécuter un cas d'utilisation)?
Or, en ajoutant les relations <include> <exclude>, on commence justement à répondre cette fameuse question "comment?" et donc on empiète sur l'expression de la solution, alors que le diagramme doit rester au niveau besoin (qui? quoi?)

[bruno_pages]

Or, en ajoutant les relations <include> <exclude>, on commence justement à répondre cette fameuse question "comment?" et donc on empiète sur l'expression de la solution

Ceci est totalement faux, on reste toujours au niveau des besoins lorsqu'on utilise ces relations, d'ailleurs si tel n'était pas le cas pourquoi feraient t-elles parti de la norme et pourquoi les offrions nous dans les modeleurs UML ?

[montesq]

Ceci est totalement faux

Si c'est totalement faux, je te laisse donc le soin de nous proposer un contre-exemple dans lequel les UC utilisant les relations <include> ou <extend> ne suggèrent pas comment l'UC doit s'exécuter.

Si on prend le premier exemple fourni par google (http://laurent-audibert.developpez.c...rs-UML011.html) et en particulier le diagramme 2.3.2, je préfère que les UC "s'authentifier" et "vérifier solde" ne se trouve pas sur ce diagramme d'UC mais uniquement dans un diagramme d'activité/séquence afin d'expliquer comment s'exécute le cas d'utilisation "effectuer un virement".
En supprimant les "UC" "s'authentifier" et "vérifier solde", on ne change pas les besoins auxquels doit répondre le système mais on occulte seulement certains détails qui seront nécessairement détaillés dans la description de l'UC.

[bruno_pages]

bigre diantre, désolé mais ce que vous dites n'a vraiment aucun sens

Si c'est totalement faux, je te laisse donc le soin de nous proposer un contre-exemple dans lequel les UC utilisant les relations <include> ou <extend> ne suggèrent pas comment l'UC doit s'exécuter.

Mais ces relations, comme le reste de la description des UCs ont justement pour but de décrire comment s'exécute les UCS, mais dans le sens du 'quoi', pour ce qu'ils font et évidemment pas dans le sens du comment ils s’implémenteront.

Encore une fois s'ils font parti de la norme ce n'est pas pour être contraire à l'esprit de la norme

Si on prend le premier exemple fourni par google (http://laurent-audibert.developpez.c...rs-UML011.html) et en particulier le diagramme 2.3.2, je préfère que les UC "s'authentifier" et "vérifier solde" ne se trouve pas sur ce diagramme d'UC mais uniquement dans un diagramme d'activité/séquence afin d'expliquer comment s'exécute le cas d'utilisation "effectuer un virement".

Premièrement ce n'est pas en disant que quelque chose n'existe pas (pas présent dans le diagramme d'UC) dans un livre qui n'est pas la norme que l'on prouve quelque chose. La norme est décrite dans la norme ou des articles écrits par des personnes ayant participé à celle-ci.

Deuxièmement une activité ou une interaction sont des très bon supports pour décrire (entre autre) un UC, toujours dans le sens du 'quoi' bien-sûr.

En supprimant les "UC" "s'authentifier" et "vérifier solde", on ne change pas les besoins auxquels doit répondre le système mais on occulte seulement certains détails qui seront nécessairement détaillés dans la description de l'UC.

Comme vous dites on 'occulte', et l'occultation ne va pas dans le sens de la clarté ! Si la norme défini des notations graphiques destinées à afficher certains éléments du modèle c'est bien pour qu'on puisse les utiliser

Pourquoi l'authentification ou la vérification d'un solde seraient des cas d'UC particuliers qui ne devraient pas apparaître ?, encore une fois tout cela n'a vraiment aucun sens, réfléchissez globalement à tête reposée et non en bâtissant une pseudo compréhension basée sur des seuls exemples.

Cordialement

[montesq]

Je considère que la définition des besoins se résume à deux questions:
1° Qui?
2° Veut faire quoi?

Dès lors que l'on se pose la question du "comment?" on passe dans la description de la solution (fonctionnelle et/ou technique).

Pour des raisons méthodologiques, JE (ça n'engage que moi et ce n'est pas écrit dans la norme) préfère que le diagramme d'UC se limite à la synthèse du besoin. La solution fonctionnelle est alors uniquement explicitée via la description des UC.
Pour reprendre l'exemple du virement, le client se contrefiche de comment va s'effectuer son virement et en particulier si le système va vérifier son solde ou non! Le client il veut faire son virement via le système, point barre : c'est là son unique besoin!

Bien qu'elles aient leur utilité (en particulier pour des problématiques de factorisation), JE considère que les relations inter UC sont des notations "nice to have" de puristes. En effet, dans la mesure où les vrais UC (ceux rattachés directement aux acteurs) sont identifiés et que ceux-ci sont correctement documentés (ce qui est dans tous les cas nécessaire), alors ces relations n'apportent pas de valeur ajoutée au modèle, d'autant plus que ces relations sont en général mal utilisées par les rédacteurs et souvent incomprises par les relecteurs en particulier "métier".
D'ailleurs, dans la sacro-sainte norme (http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF), au chapitre du diagramme d'UC, les relations sont bien entendues décrites, mais dans les exemples fournis de diagrammes d'UC (p614 et 615), aucune de ces relations n'apparaît dans les diagrammes. Or l'exemple p615 est exactement celui du cours signalé auparavant...

Ce sera mon dernier post pour confirmer que:
OUI les relations existent dans la norme
OUI les relations peuvent avoir un intérêt et donc être utilisées MAIS le rédacteur (a fortiori débutant) devrait plutôt se concentrer à écrire la description de ses UC plutôt que perdre son temps à vouloir à tout prix chercher des relations entre UC...

Pour bien te former :

Cours et tutoriels pour apprendre UML : http://uml.developpez.com/cours/
Cours complet pour apprendre UML 2.0, une série de tutoriels par Laurent Audibert : http://laurent-audibert.developpez.com/Cours-UML/
La FAQ UML : http://alm.developpez.com/faq/

[analyste_en_herbe]

Je considère que la définition des besoins se résume à deux questions:
1° Qui?
2° Veut faire quoi?

Dès lors que l'on se pose la question du "comment?" on passe dans la description de la solution (fonctionnelle et/ou technique).

Pour des raisons méthodologiques, JE (ça n'engage que moi et ce n'est pas écrit dans la norme) préfère que le diagramme d'UC se limite à la synthèse du besoin. La solution fonctionnelle est alors uniquement explicitée via la description des UC.
Pour reprendre l'exemple du virement, le client se contrefiche de comment va s'effectuer son virement et en particulier si le système va vérifier son solde ou non! Le client il veut faire son virement via le système, point barre : c'est là son unique besoin!

Bien qu'elles aient leur utilité (en particulier pour des problématiques de factorisation), JE considère que les relations inter UC sont des notations "nice to have" de puristes. En effet, dans la mesure où les vrais UC (ceux rattachés directement aux acteurs) sont identifiés et que ceux-ci sont correctement documentés (ce qui est dans tous les cas nécessaire), alors ces relations n'apportent pas de valeur ajoutée au modèle, d'autant plus que ces relations sont en général mal utilisées par les rédacteurs et souvent incomprises par les relecteurs en particulier "métier".
D'ailleurs, dans la sacro-sainte norme (http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF), au chapitre du diagramme d'UC, les relations sont bien entendues décrites, mais dans les exemples fournis de diagrammes d'UC (p614 et 615), aucune de ces relations n'apparaît dans les diagrammes. Or l'exemple p615 est exactement celui du cours signalé auparavant...

Ce sera mon dernier post pour confirmer que:
OUI les relations existent dans la norme
OUI les relations peuvent avoir un intérêt et donc être utilisées MAIS le rédacteur (a fortiori débutant) devrait plutôt se concentrer à écrire la description de ses UC plutôt que perdre son temps à vouloir à tout prix chercher des relations entre UC...

Bonjour,

Désolé de redémarrer cetet discussion mais je trouve que les points soulevés sont importants particulièrement dans mon cas ... D'un côté, je suis d'accord avec vous pour limiter l'identification des cas d'utilisation aux besoins métiers (je considère même que le UC n'est pas une fonction mais plutôt un objectif d'interaction : j'interagis avec le UC pour retirer de l'argent et non le UC me permet de retirer de l'argent) ... Néanmoins, il se peut que les besoins métiers aient besoin d'être structurés pour maintenir une certaine cohérence à l'abstraction ... je m'explique : en retirant l'argent il se peut que je souhaite payer mes factures ... À ce moment, il me semble que la relation "extend" soit appropriée plus qu'une autre association ...

Par contre, je me demande justement pourquoi ne pas regrouper par exemple 'retirer argent', 'payer des factures' et 'vérifier solde' dans un seul UC 'gérer compte' et les définir comme des instances de ce UC ... Certes, la problématique se pose au niveau de la description textuelle du cas ... Dans un sens, les UCs doivent définir un modèle et donc une représentation limitée et structurée de tous les besoins et d'un autre côté la description textuelle fait en sorte que le UC soit assimilé à une fonction ... J'ai de la difficulté à fixer une frontière