On sent venir dans certains domaines de développement informatique la mode du formalisme UML. Le domaine que je connais est l'informatique industrielle (aéronautique, spatial,...), où les logiciels doivent être qualifiés, c'est-à-dire développés selon des méthodes permettant d'avoir un certain niveau de confiance dans le logiciel.

Dans les méthodes habituelles on trouve toujours une étape de conception du logiciel, qui permet de donner une architecture au logiciel en le découpant en briques, chacune en charge de fonctionnalités différentes. Et pour cette étape on utilise de plus en plus les diagrammes de classes UML.

Dans nos développements, nous utilisons un logiciel d'édition de classes UML, qui génère des squelettes de code C++ ou Java. A l'intérieur de ces squelettes nous écrivons le code manuellement, et il faut constamment garder une cohérence parfaite entre les classes UML et le code (cohérence des prototypes de méthodes, etc.). Ce mode de travail a les avantages suivants :
- on a une bonne vision de l'architecture du logiciel grâce à l'organisation en paquetages et aux schémas (les diagrammes de classes)
- on peut générer un document HTML qui permet de visionner cette architecture

Mais cela pose aussi de lourds problèmes d'inertie de développement :
- le logiciel d'édition UML est lourd à utiliser (utilisation mémoire, licence,...)
- impossible de faire des diff entre 2 versions
- changer un prototype de méthode demande d'abord de faire le changement dans le modèle UML, puis regénérer le squelette de code (travail manuel)
- le logiciel UML s'interface mal avec des bibliothèques externes déjà existantes, ce qui ajoute du travail manuel, comme par exemple ouvrir une fenêtre de dialogue pour spécifier un type particulier, ou inclure un fichier header .hpp au bon endroit.
- etc.

Et évidemment ces problèmes d'inertie ont un impact négatif direct sur la qualité du code développé puisqu'à chaque modification de structure de classe, on ne fait pas ce qui serait le mieux, mais ce qui est le plus simple à prendre en compte dans le modèle UML.

Au-delà de ces problèmes de bas-niveau, j'ai constaté qu'UML est un formalisme fourre-tout qui n'est pas spécialement adapté pour faire la conception de logiciels.
- L'exemple le plus évident est le "main" (branche principale d'exécution) : tous les logiciels en ont un, mais en UML non.
- On trouve facilement d'autres exemples, puisque UML est juste un formalisme vague pour faire des schémas, et par exemple des relations d'aggrégations seront interprétées différemment par différentes personnes.

Pour résumer ma pensée, UML est à la mode, on veut l'utiliser absolument, parfois on veut migrer d'anciens formalismes vers UML, mais beaucoup de gens ne se rendent pas compte qu'on y perd en clarté, qualité et efficacité.

En voyant des documentations Doxygen (j'ai vu mais pas utilisé), j'ai pensé qu'on pourrait s'affranchir du logiciel d'édition UML : on taperait tranquillement le code, et ensuite Doxygen (ou autre système similaire) génèrerait les beaux schémas. On gagnerait énormément de temps, on gagnerait en qualité de code, et on aurait d'aussi beaux schémas qu'avec un logiciel UML.

En vue de ces petits inconvénients je fais appel à vos retours d'expérience :
- comment faites-vous votre conception logicielle ?
- quelles sont les limites des systèmes du genre de Doxygen ?
- que pensez-vous d'UML ?

> Lire le journal (18 commentaires, moyenne: 4,3).