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 ?
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).
Vous avez demandé le commentaire #884868.
Run by 
Cette page a été générée par Templeet en 0.0419s (dont 0.0051 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Mes deux cents (trolls)
Franchement personne n'a encore la réponse définitive à cette question. Et tant que ca sera le cas on trouvera une clause de non garantie du résultat dans la plupart des licenses de logiciels. Pour le moment cela n'a l'air de déranger personne mais imaginez vous achetez un four à mirco-onde ou une voiture sans garantie de fonctionnement ?
Si j'ai bien compris tu veux que doxygen te fournisse des schémas. Ca cera forcement limité car dans un schéma l'auteur essayer de communiquer des propriétés importantes en faisant des abstraction du systeme. Il peut aussi ajouter des information qui n'apparaisse pas dans le code.
Le grand problème avec cette question c'est que personne n'a la même vision d'UML. En majorité quand quelqu'un dit UML ca veut dire diagrame statique de classe. Or ce diagramme c'est une toute petite portion d'UML.
En plus c'est uniquement un standard de représentation de bubulles et de fleches mais il n'y marqué nul part quelle est la sémantique de ces choses là. Alors on crois qu'on parle une langue universelle alors que personne ne dit la même chose.
Bref UML un gros buzzworld pour faire croire qu'on a une méthode de travail dans le logiciel alors que tout le monde continue comme avant. D'ou l'aspect fourre tout de la norme puisque la normalisation ne c'est faite qu'en surface.
[^]Re: Mes deux cents (trolls)
L'erreur fondamentale consiste à croire qu'UML est une méthode.
UML est un langage et rien d'autre. De plus c'est un langage de MODÉLISATION par d'implémentation, on peut toujours le vendre pour ça, mais ça reste faux.
En amont, et comme pour toute activité d'ingénierie, il faut commencer par définir un processus de développement, puis une méthode pour chacune des activités du processus et enfin un outillage. L'outillage peut être un référentiel de document traditionnels, un modèle ou ce que l'on veut dans la mesure ou il accepté par toutes les parties prenantes.
Je trouve que l'utilisation d'UML est adapté lors de la phase de capture d'exigences et notamment pour définir et contractualiser le fonctionnel, ou comportemental, du logiciel, particulièrment dans l'embarqué. Cela permet de remettre le logiciel dans son contexte matériel ou système.
Finalement je te rejoins sur le fait qu'UML est peut être trop généraliste, SysML est sur ce point une avancée intéressante puisque clairement on ne s'oriente plus implémentation (au sens logiciel, c'est à dire codage).