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.
C'est toujours mieux que rien. Je lis beaucoup de gens ici se plaindre d'avoir à écrire du code boilerplate et franchement écrire le squelette d'une classe, ce n'est justement que ça.
Personnellement, j'ai travaillé il y a une quinzaine d'années sur un projet où la spécification détaillée a été écrite en utilisant des diagrammes de cas d'utilisation, des diagrammes de classes et des diagrammes de séquences.
Finalement, le client, un automaticien reconverti en chef de projet, a trouvé le document très clair et cherry on the cake, on utilisait le même modèle UML pour générer l'ossature du code C++ ainsi que remettre les diagrammes à jour depuis le code ensuite.
Alors, ce n'est pas parfait mais pour moi, le code n'est que la conséquence de la conception et la conception est l'image de la compréhension du problème. UML fournit un langage qui permet de représenter rapidement l'image qu'on se fait du problème.
Du coup, pPlonger dans le code directement introduit les biais issus de la conception du langage et obscurcit par la même occasion le problème.
Au passage, aux dernières nouvelles, le code C++ généré (en partie) fonctionne toujours.
[^] # Re: la spec, c'est le code
Posté par Blackknight (site web personnel, Mastodon) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 5.
C'est toujours mieux que rien. Je lis beaucoup de gens ici se plaindre d'avoir à écrire du code boilerplate et franchement écrire le squelette d'une classe, ce n'est justement que ça.
Personnellement, j'ai travaillé il y a une quinzaine d'années sur un projet où la spécification détaillée a été écrite en utilisant des diagrammes de cas d'utilisation, des diagrammes de classes et des diagrammes de séquences.
Finalement, le client, un automaticien reconverti en chef de projet, a trouvé le document très clair et cherry on the cake, on utilisait le même modèle UML pour générer l'ossature du code C++ ainsi que remettre les diagrammes à jour depuis le code ensuite.
Alors, ce n'est pas parfait mais pour moi, le code n'est que la conséquence de la conception et la conception est l'image de la compréhension du problème. UML fournit un langage qui permet de représenter rapidement l'image qu'on se fait du problème.
Du coup, pPlonger dans le code directement introduit les biais issus de la conception du langage et obscurcit par la même occasion le problème.
Au passage, aux dernières nouvelles, le code C++ généré (en partie) fonctionne toujours.