Pour bien expliquer cela, nous avons besoin d'une courte leçon d'histoire. Aux débuts du génie logiciel, une analogie souvent utilisée était la construction d'une maison. Un architecte et un ingénieur en structure discutent des plans avec un client et élaborent une conception. Les constructeurs suivent ensuite cette conception pour construire la maison réelle. L'écriture de code était considérée comme l'équivalent de la construction de la maison actuelle. Ainsi, il y avait un besoin perçu de conception initiale avant que cette construction puisse avoir lieu. Divers outils de conception graphique ont été créés, dont UML en fait partie.
L'idée à l'origine avec UML était que l'on concevrait entièrement un système avec UML, puis le confierait aux codeurs pour traduire cette conception en code. En réalité, cela ne fonctionne tout simplement pas et a conduit à des années de programmeurs considérés comme des «exécutants» plutôt que des «concepteurs», les projets étant en retard, les conceptions devant constamment changer après qu'elles étaient censées être terminées, etc.
La raison est simple. Le codage, c'est le design . Avec l'analogie de la maison, le code est les dessins de l'architecte. Le compilateur est le constructeur qui prend ces conceptions et construit un programme à partir d'eux. Cette réalisation a ensuite conduit à la naissance de techniques agiles, TDD etc.: des outils pour améliorer la qualité de la conception de ce code.
Tout comme un architecte peut produire des croquis préliminaires pour l'aider, elle et son équipe, à visualiser la conception globale, un développeur peut utiliser UML ou d'autres outils pour aider à visualiser la conception nécessaire. Tout comme ces esquisses ne sont pas suivies aveuglément, l'UML ne doit pas être suivi aveuglément. La conception du code devrait évoluer à partir d'itérations agiles et à l'aide de TDD. De même, tout comme un architecte peut construire un modèle de maison pour l'aider, elle et son équipe, à visualiser les dessins, UML peut être utilisé pour aider à visualiser la structure du code.
Comme le dit l'oncle Bob, vous ne pouvez pas valider l'UML, vous pouvez uniquement valider le code. Par conséquent, le code est la documentation de conception principale et UML, s'il est utilisé, est uniquement une documentation secondaire.