on m'a dit qu'il y a un problème

**emmesse** · 30/04/2025, 09h20

Bonjour,

pouvez-vous m'indiquer les problèmes de ces UCs ? Nom : uml.jpg
Affichages : 174
Taille : 79,8 Ko

quelqu'un a une idée?

**bruno_pages** · 30/04/2025, 10h57

Je m'attendais à revoir le diagramme de votre autre discussion mais peu importe.

Un UC décrit la réaction d'un système à un stimulus externe, et une façon simple et naturelle de décrire une (ré)action est d'utiliser au moins un verbe. Une bonne partie de vos UCs ne contiennent pas de verbe dans leur nom, rien que cela me permet de dire que ceux-ci ne sont pas des UCs, même si je ne vois rien d'autre les concernant.

Un UC doit être activable directement ou indirectement par un acteur, quand vous avez UC1 ---<<include>>---> UC2 et qu'UC2 n'est pas activé directement par un acteur et n'est inclus par aucun autre UC qu'UC1 alors cela veut dire qu'UC2 n'est pas un UC en tant que tel et n'est qu'une partie d'UC1. Décomposer ce que fait un UC en le découpant en plusieurs UCs juste pour le montrer dans un diagramme n'est souvent pas une bonne chose. Un UC ce n'est pas de l'implémentation, cela ne suit pas les mêmes règles de décomposition, cela ne sert à rien de les décomposer pour qu'ils correspondent à des traitements simplistes. Même remarque en ce qui concerne la décomposition en plusieurs UCs via héritage.

Un UC comme d'ailleurs les autres éléments composant une modélisation UML, ce n'est pas que ce que l'on peut voir dans un "dessin", une modélisation UML ne se réduit pas qu'à une liste de diagrammes point barre, d'ou le fait que par exemple plantuml n'est pas du tout un outil de modélisation UML. Un UC est "résumé" par son nom qui doit donc être bien choisi, mais il n'est pas réduit qu'à celui-ci, les vraies informations le concernant sont dans sa description associée, qui indique ce que fait le système, les éventuelles pré/post conditions etc. Lorsque vous faites un <<extend>> n'oubliez pas de donner le point d'extension.

Un acteur correspond à un rôle, pensez-vous par exemple qu'autre joueur est un nommage informatif sur le rôle supporté par cet acteur ?

Quand deux acteurs sont reliés par des UCs c'est qu'il y a un acteur primaire et un acteur secondaire, par convention pour qu'on sache rapidement qui est qui dans un diagramme d'UC on place l'acteur primaire à gauche et le secondaire à droite, même si cela ne fait pas parti de la norme UML.

Un diagramme doit rester simple pour être lisible, les personnes et en particulier les étudiants ont souvent tendance à faire des diagrammes compliqués en cherchant par ailleurs à utiliser un maximum de type d'éléments/relations pour montrer qu'ils les connaissent. Dans un diagramme comme en programmation il faut chercher la simplicité ... même si c'est difficile à atteindre. Vous n'êtes pas limité à un unique diagramme devant tout montrer, et un diagramme n'est pas qu'une liste arbitraire d'éléments représentés. Un diagramme doit avoir un but associé, dans le cas d'un diagramme d'UCs il y a d'ailleurs le sujet pour le montrer explicitement, dessiné via un rectangle contenant les UCs correspondants.