Et bien, quel débat passionant.
Pour ma part, je vois UML comme un outil pour projet important séparant Analyse, Conception et Développement.
Le but recherché, ou en tous cas, celui que je pense déduire d'UML, est la possibilité de faire une analyse par une personne et de fournir les résultats à une autre personne capable de les intepréter, d'en faire une deuxième étude en vue de la conception et de la proposition d'environnement technique.
Je ne vois pas vraiment l'utilité d'UML sur des projets de 2 - 3 personnes car les documentations normalement présente (Cahier des charges ...) sont suffisantes en général. Et puis, moins on est nombreux, moins on se prend la tête avec les docs, il faut bien se l'avouer, rédiger un cahier des charges après la développement est courant et honteux, mais pas toujours de notre ressort ...
Pour revenir sur UML, sur un gros projets avec des analystes, qui sont en contact avec les clients, puis des concepteur / developpeur qui développent les briques de l'application, il est indispensable d'avoir une modélisation standard, facile à comprendre afin d'appliquer immédiatement les modifications necessaires.
Imaginez le cas où l'on doit corriger un existant. UML sert d'une part à modéliser l'existant, mais aussi à l'analyser, le diagnostiquer et modeliser les modifications. Il est donc indispensable d'avoir cette documentation.
Juste pour revenir sur le MCD (leger équivalent du diagramme de classes pour UML), c'est le seul document systématiquement fait pour chaque projet, et c'est regrettable dans le sens où quand on arrive sur un projet existant, il nous manque souvent la logique de l'application, un simple diagramme d'activités ou d'états ou même de séquences peut nous éviter bien des problèmes de compréhension.
Donc oui, UML ca s'utilise, bien souvent c'est couplé à un logiciel permettant la génération automatique de code, et pour les projets enormes, ca sert de cahier des charges, de compte rendu de diagnostique etc...