Bonjour,
C'est hmmm.... comme un champs de tomates.
Il y a un bout de terrain, des graines, des agriculteurs, des engins agricoles pour les engrais, pour la cueille etc. Sauf qu'un champs de tomate on voit vaguement ce qui rentre en jeu, un programme peut être beaucoup plus complexe.
L'UML a pour moi un seul but. Donner une méthode à suivre pour l'élaboration de son cahier des charges.
Cela va de "Que doit pouvoir faire l'utilisateur avec le logiciel et quels sont les types d'utilisateurs ?" qui est le Use case. C'est le premier que l'on met en place afin de spécifier avec le client quels sont ses volontés en terme de fonctionnalités.
Exemple de Use case.
Il y a des diagramme de déploiement pour spécifier l'architecture matérielle à mettre en place. Des diagrammes d'état pour modéliser les automates. Et surtout (c'est le seul que j'utilise personnellement) le diagramme de classes.
Exemple Encore une fois cela sert à poser d'une manière normée l'architecture d'un programme. Les classes, les interfaces, les relations d'héritages, les relations entre les classes etc. (J'ai pris un exemple sans les membres et méthodes ça fait trop souillon après). En gros, c'est une photographie aérienne de la structure du programme. Dans mon entourage par exemple, tout le monde s'y est mis parce que c'est plus simple de tous utiliser la même représentation quand on veut expliquer ses idées. "Alors voilà, j'ai un objet, mes véhicules sont des objets mobiles, le camion est un véhicule qui possède aussi un objet benne à ordure qui est un container qui est un objet." Et bien on fait un diagramme rapide et d'un coup tout le monde voit exactement le truc parce que c'est un dessin et non du texte. Après, UML c'est simplement se mettre d'accord sur une représentation qui soit comprise par tout le monde.
Il y a dans mes souvenirs 13 types de schémas différents afin de schématiser des fonctionnalités au matériel et au classes mises en oeuvre (ou à mettre en oeuvre)
M.
