J'ai suivi des cours de conception de logiciels au cours des derniers semestres, et même si je vois l'avantage de beaucoup de formalisme, j'ai l'impression que cela ne me dit rien sur le programme lui-même:
- Vous ne pouvez pas dire comment le programme va fonctionner à partir de la spécification de cas d'utilisation, même s'il explique ce que le programme peut faire.
- Vous ne pouvez rien dire sur l'expérience utilisateur à partir du document d'exigences, même s'il peut inclure des exigences de qualité.
- Les diagrammes de séquence décrivent bien le fonctionnement du logiciel en tant que pile d'appels, mais sont très limités et donnent une vue très partielle du système global.
- Les diagrammes de classes sont parfaits pour décrire la façon dont le système est construit, mais ils sont totalement inutiles pour vous aider à comprendre ce que le logiciel doit être.
Où se situe le fond de tout ce formalisme: à quoi ressemble le programme, comment fonctionne-t-il et quelle expérience il donne? N'est-il pas plus logique de concevoir à partir de cela? N'est-il pas préférable de comprendre comment le programme devrait fonctionner via un prototype et de s'efforcer de le mettre en œuvre pour de vrai?
Je sais que je souffre probablement de l'enseignement du génie par des théoriciens, mais je dois demander, font-ils cela dans l'industrie? Comment les gens peuvent-ils déterminer ce qu'est réellement le programme, et non à quoi il devrait être conforme? Est-ce que les gens prototypent beaucoup ou utilisent-ils principalement des outils formels comme UML et je n'ai pas encore compris comment les utiliser?