Je pense que les diagrammes UML ne peuvent être utiles que s'ils expriment quelque chose à un niveau d'abstraction plus élevé que votre code .
Écrire UML juste pour écrire UML devient une bureaucratie inutile et rend le projet et le code moins adaptables aux changements sans aucun avantage.
Par exemple, un diagramme de classes UML montrant toutes les classes d'un package, avec tous leurs attributs et méthodes - quelque chose qui peut être facilement généré automatiquement - ne fournit aucune valeur: il est au même niveau d'abstraction que votre code . De plus, le code sera très certainement une meilleure source pour ces informations car il sera toujours à jour, et il sera probablement documenté et organisé de manière à ce qu'il soit plus facile de savoir quelles méthodes / attributs / choses sont plus importantes.
D'un autre côté, si vous avez des concepts d'un niveau d'abstraction plus élevé que ce qui peut être exprimé exprimé dans le code, les documenter sur un diagramme peut être une bonne idée.
Par exemple, un diagramme montrant les modules abstraits de niveau supérieur sur un système complexe, avec leurs dépendances et peut-être une petite description de leurs responsabilités et le package / espace de noms auquel ils mappent dans le code source peut être vraiment utile pour un nouveau membre de l'équipe qui doit être introduit dans le projet, ou peut également être utilisé pour déterminer où une nouvelle classe / fonctionnalité doit être lancée.
Un autre exemple de diagramme utile pourrait être un diagramme de séquence montrant les étapes de haut niveau à effectuer dans un protocole de communication. Peut-être que chaque étape a ses petites bizarreries et complexités, mais c'est probablement suffisant pour les décrire dans le code lui-même. Le diagramme de niveau supérieur peut aider un programmeur à comprendre facilement la «vue d'ensemble» des choses sans avoir à se soucier de la complexité de chaque interaction.
Quoi qu'il en soit, ce ne sont que quelques exemples; il existe de nombreux cas où un schéma simple peut être très utile. N'oubliez pas que vous ne devriez les faire que lorsque vous ne pouvez pas exprimer quelque chose dans le code lui-même. Si vous vous retrouvez à utiliser des diagrammes UML pour expliquer le code source lui-même, rendez plutôt le code soruce plus auto-documenté.
Enfin, certaines des règles générales qui s'appliquent au code peuvent également s'appliquer aux diagrammes: évitez de vous répéter, restez simple, ne craignez pas de changer les choses (ce n'est pas parce qu'un document est documenté sur un diagramme UML qu'il ne peut pas être changé) et pensez toujours à qui lira / maintiendra ces diagrammes à l'avenir (probablement votre futur) lors de leur écriture :)