Bonjour

Je vais donner quelques cours en UML l'année prochaine niveau licence. J'ai préparé une petite ébauche de conseils généraux. La liste n'est loin d'exhaustive ni complet. Simplement quelques réflexions bien réussir des diagrammes UML. J'aurais bien voulu vos commentaires ...

N'utilisez pas plus de 8 cas d'utilisation sur un diagramme pour faciliter la lecture. Ne faites pas croiser des lignes d'associations.

Dans EA: inclure les classes et les acteurs dans les packages fonctionnel ou dans un package à part?

Les associations entre objets peuvent êtres établis sans connaitre leur nature exacte. Il suffit d'apprendre leur existence dans un premier temps et approfondir votre connaissance de leur nature dans un deuxième temps.

Remarquez qu'il est facile de poser des cas d'utilisation, mais bien plus intéressant de poser les acteurs lié et déterminer les associations entre ceux-ci. C'est à ce moment là que l'on met en question la véracité du modèle.

N'hésitez pas à faire des commentaires textuelle (notes) et lister les taches et issues. Ceux-ci néanmoins doivent être moteur pour la mise en question du modèle et la création de éléments du modèle. Autrement le processus d'analyse doit rapporter sur le modèle.

N'hésitez pas a combiner différent types de diagramme selon votre besoin et même de dessiner les mêmes schéma avec plusieurs types de diagramme. Encore une fois cela amène à une clarté et une profondeur d'analyse.

Je pense qu'il est important sur un diagramme de ne pas avoir un élément non lié à d'autres.

Si un diagramme de packages peut être utile, il peut être moins facile a lire et les liens possibles entre acteurs et packages sont que des liens de dépendance ou réalisation non des association fortes. On peut alors recréer un diagramme de cas d'utilisation, chacun donnant sur un package, permettant ainsi une meilleur lisibilité.

Quel est le sens du lien 'dependency'. L'acteur dépend du package ou le package dépend de l'acteur?

Le tag 'abstract' est utilisé sur des cas d'utilisation pour des cas 'non réel' qui chapote leurs cas d'utilisation subsidiaires.

Parfois j'ai besoin / envie de changer un type de diagramme. Ex. j'ai représenté le détail par un diagramme de séquence et je trouve que le diagramme de séquence ne décrit pas suffisamment le cas d'utilisation. Alors je les descends un niveau sous un cas d'utilisation, pour en rajouter d'autre au même niveau.

Il est souvent convenable de mettre en place un cas d'utilisation candidat. C'est-à-dire le placer sur un diagramme et voir si des associations sont possibles et logique.

Je trouve inutile de multiplier les associations quand un schéma contient beaucoup de cas d'utilisations mais un seul acteur. Stipuler dans un note que tel est le cas.

Le nom d'un cas d'utilisation est important pour bien le décrire. Néanmoins n'y passez pas trop de temps. Choisissez un nom et voir comment ça se 'sent' en développant votre diagramme. Ex. 'Marketing' 'Sales et Marketing', 'Business Development', 'Promotions', 'Communications'. Si ces termes sont très proches, la question à se poser est 'quel sens voudrais-je donner aux activités? A un niveau stratégique on voit beaucoup d'argent dépenser en combinant sales avec marketing ou les dissocier.

Mettez en question votre modèle le plus souvent possible. A se demander si le modèle (et c'est bien un modèle, une représentation) représente bien la réalité. A quel point est-il proche de la vérité même S'il n'ya pas de vérité mais que des représentations les plus proches possibles.