Le but d'UML, c'est de fournir un langage. Comme un langage de programmation, en fait. On pourrait donc écrire tout le comportement du logiciel en UML et donner ça à un compilateur qui en ferait un binaire.
L'avantage d'un langage comme UML, c'est qu'il est plus facile à lire que du code en C, par exemple. L'inconvénient, c'est qu'il est beaucoup plus compliqué à compiler et aussi peut-être trop subtil pour certaines choses.
Du coup on se retrouve avec des outils qui font au mieux la moitié du chemin (genre, transformer l'UML en un squelette d'application Java ou C++ qu'il faut compléter à la main) et du coup on ne peut pas automatiser complètement le processus.
Pour moi, la conclusion, c'est qu'on ne peut pas encore fusionner les spécifications et le code qui les implémente. L'un est lisible par les humains, l'autre par les ordinateurs. Et on ne parle pas encore la même langue.
[^] # Re: la spec, c'est le code
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 10.
Le but d'UML, c'est de fournir un langage. Comme un langage de programmation, en fait. On pourrait donc écrire tout le comportement du logiciel en UML et donner ça à un compilateur qui en ferait un binaire.
L'avantage d'un langage comme UML, c'est qu'il est plus facile à lire que du code en C, par exemple. L'inconvénient, c'est qu'il est beaucoup plus compliqué à compiler et aussi peut-être trop subtil pour certaines choses.
Du coup on se retrouve avec des outils qui font au mieux la moitié du chemin (genre, transformer l'UML en un squelette d'application Java ou C++ qu'il faut compléter à la main) et du coup on ne peut pas automatiser complètement le processus.
Pour moi, la conclusion, c'est qu'on ne peut pas encore fusionner les spécifications et le code qui les implémente. L'un est lisible par les humains, l'autre par les ordinateurs. Et on ne parle pas encore la même langue.
CommitStrip