Tutoriel UML

Bonjour,

Après vérification dans la liste des tutoriels en cours de rédaction et après avoir vérifier le besoin dans la liste des idées de tutoriel proposé par la communauté j'ai décidé de me lancé dans l'écriture d'un tutoriel sur le langage UML.

J'aurais alors voulu dégrossir avec vous ce que vous auriez comme attente ou comme idée à propos de ce tutoriel qui est quand même assez vaste.

J'avais comme idée un plan de ce type :

1. Une introduction
   • Présentation des différents types de diagramme (ceux traités dans le tutoriel et les plus connus, sans rentré dans le détail des diagramme très spécifique a certains domaine).
   • L’intérêt de faire des diagramme dans un travail d'équipe mais aussi dans un projet personnel.
   • Explication sur la méthode de lecture de ce tutoriel
2. Différentes parties, une par diagramme
   • Explication du diagramme : son but, sa logique et son origine
   • Exemple concret (ici je compte prendre deux à trois projets collé sur chaque cas de manière a avoir toujours plusieurs chance de comprendre la nuance)
3. Une petite parties assez courte sur les différents outils de modélisation UML que l'on peut trouver facilement
   • Présentation de l'outils et de son éditeur afin de le télécharger
   • Description de son domaine particulier si il en a un (tout les outils ne font pas tout)

La troisième partie irai à la fin sous forme d'annexe, puisque le tutoriel inciterai à l'usage d'une feuille de brouillon et d'un crayon.

J'aurais surtout voulu savoir :

Je suis bien entendu intéresser par tout ce que vous pouvez m'apporter d'autre!

Salut Sanoc,
pour le plan, je n'aurais pas mis les points de deuxième niveau dans cet ordre.

J'utiliserai plus un plan comme ça :

1. Une introduction
   • L’intérêt de faire des diagramme dans un travail d'équipe mais aussi dans un projet personnel.
   • Présentation des différents types de diagramme (ceux traités dans le tutoriel et les plus connus, sans rentré dans le détail des diagramme très spécifique a certains domaine).
   • Explication sur la méthode de lecture de ce tutoriel
2. Différentes parties, une par diagramme
   • Présentation de l'exemple (ou des exemples)
   • Explication du diagramme : son but, sa logique et son origine
   • Retour sur l'exemple concret
3. Une petite parties assez courte sur les différents outils de modélisation UML que l'on peut trouver facilement
   • Présentation de l'outils et de son éditeur afin de le télécharger
   • Description de son domaine particulier si il en a un (tout les outils ne font pas tout)

Et pour les questions :

Quel diagramme conseilleriez vous pour ce tutoriel, quels sont ceux que vous utilisez personnellement ou que vous lisez régulièrement ?

J'utilise le diagramme de classes (ou d'objet) en grande majorité. Après à savoir ceux que je conseillerais… Je dirais que cela dépend des types de projets (mais le diagramme de classes peut s'appliquer pratiquement partout)

Quels sont pour vous les points essentiel à ne pas rater

Sans UML, c'est bien. Avec, c'est mieux

Le soucis, c'est que l'UML c'est pas très normalisé de mémoire. Et suivant les entreprises, les écoles, les pays, il n'est pas demandé la même chose (ça change dans la forme principalement).

Quel diagramme conseilleriez vous pour ce tutoriel, quels sont ceux que vous utilisez personnellement ou que vous lisez régulièrement ?

Pour ma part j'utilise en majorité le diagramme de classe (avec en moindre quantité le diagramme de séquence) ainsi que le diagramme de déploiement pour mieux comprendre un système.

UML est bien normalisé : normalisation UML 2.5
Seul certains points sont parfois flou. Le problème vient plutôt du faite que peu de personne respecte la norme, ou des versions différentes d'UML, qui évolue trop.

Je ne suis pas sûr de comprendre dans le détail. Tu souhaite présenter l'exemple comme le ferais n'importe qui sans UML, présenter l'outil et ensuite représenter l'exemple mais avec UML pour bien saisir tout ce que nous apporte la notation? Si c'est bien cela ça peut effectivement être intéressant.

Effectivement il existe une écriture normalisé, qui comporte comme tout langage des espace de flou. Le problème que j'espère relevé est le fait d'arriver a présenter facilement et le plus complètement possible les différences d'écriture possible.

Beaucoup de personnes influente font encore des erreurs d'écriture UML, mais leurs notoriété rend leurs erreur une réalité du terrain de part le nombre qui la recopie…

Puis même sans parler des erreur de notation, il y a aussi énormément de gens qui simplifie l'écriture dans sa logique comme on peut le voir avec les flèches des diagrammes de classe "contient" et "est formé de" qui sont respectivement blanche et noir.