UML est une modélisation. Les diagrammes sont des outils pour décrire les données et les traitements du système au niveau conceptuel et logique. Le projet peut consister à produire un système "from scratch" ou a reprendre un existant. Selon le type de projet, l'ordre d'exécution des diagrammes ne sera pas le même.
Le diagramme de cas d'utilisation s'utilise essentiellement en phase d'analyse pour documenter les scénarii d'utilisation du système. On définit alors le périmètre fonctionnel du système.
Les cas d'utilisation sont affinés à l'aide de diagrammes de séquences. Les diagrammes d'état-transistion et d'activités modélisent les changements d'état à la manière d'un logigramme. Le diagramme de classe décrit les données du système.
Certains diagrammes modélisent l'organisation physique et logique du système final : diagramme de composants et diagramme de déploiement (en pratique, rarement utilisés)
Pour ma part, les diagrammes importants sont, dans l'ordre d'utilisation : le use case, le diagramme de séquence et le diagramme de classe. Le diagramme de séquence n'est pas bien adapté à la modélisation des scénarii alternatifs et des boucles (lacune comblée dans UML 2.0). Le diagramme de séquence décrit l'enchaînement des opérations qui concourrent à la réalisation du scénario type d'un cas d'utilisation. Le diagramme de classe est indispensable pour décrire et critiquer un choix d'architecture logiciel.
Quelque soit le diagramme que tu souhaites mettre en oeuvre, demande toi ce que tu veux décrire et quel est le diagramme le plus adapté pour le faire. Il ne faut pas qu'UML guide ta conduite mais que tu adaptes le choix des diagrammes à ce que tu veux faire.
UML est comparable à des plans d'architecte : ils ne te disent pas comment construire la maison mais décrivent la solution retenue.
Message édité par slash33 le 14-05-2006 à 10:58:42