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 ?
Journal Conception de logiciel et UML
24
nov.
2007
# Doxygen n'est pas fait pour la conception
Posté par ecyrbe . Évalué à 10.
Cependant, faire de l'UML pour la conception c'est bien, mais faire de l'UML pour de la maintenance de code, c'est lourd, comme tu l'as bien exposé.
Ce que tu devrais faire, c'est utiliser un logiciel UML qui fasse de la rétro-ingienérie de code. Il y en a plein qui font celà, dont le célèbre rational rose. Ce que tu dois faire, c'est faire ton refactoring sur papier en concertation avec l'équipe de dev, ensuite tu modifies directement ton code, et là tu le passe à la moulinette dans ton outils de rétro-ingénierie UML pour garder tes diagrammes à jours. En plus, documente ton code au format doxygen, comme ça tu as à la fois l'UML et la documentation. C'est pourtant simple et logique, non?
# main()
Posté par Christophe Chailloleau-Leclerc . Évalué à 7.
Ceci dit, si on veut rester à fond dans l'objet, il me semble qu'un main devrait ressembler à :
int main(int argc,char *argv[])
{
MonApplication app;
app.go/run/main/execute/...(argc,argv);
}
C'est en général le genre de code que l'on voit, par exemple, pour des interfaces en Qt.
Il n'est dans ce cas pas nécessairement critique d'avoir une véritable modélisation de cette méthode ! Ton vrai point d'entrée est alors une méthode de ta classe "principale"...
# Quelques vérités sur UML
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
Pour ce qui est de la génération automatique des diagrammes de classe à partir du code, n'importe quel bon logiciel fait ça (Umbrello, Rationale Rose ...).
Les parties réellement utiles d'UML pendant la conception AMHA, ce sont les diagrammes permettant d'illustrer les cas d'utilisation, toute la partie fonctionnelle. Utiliser UML pour générer du code est (toujours AMHA) une erreur, car il est beaucoup plus long de faire le diagramme de classes que de l'écrire (seulement le squelette, en laissant les méthodes vides).
Le rôle d'UML est (encore AMHA) de fournir un moyen de communication entre les utilisateurs (compréhensible facilement lorsque les diagrammes sont bien faits, même sans trop de connaissances), ceux qui font les spécifications, et ceux qui développent.
[^] # Re: Quelques vérités sur UML
Posté par Gniarf . Évalué à 9.
# Mes deux cents (trolls)
Posté par outs . Évalué à 8.
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)
Posté par emanjo . Évalué à 1.
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).
# UML oui, génération de code non
Posté par laurent laffont (site web personnel) . Évalué à 4.
Maintenant toutes les intégrations d'UML avec le code que j'ai essayé (Together, Rational, ...) ne m'ont jamais convaincu:
- c'est lourd
- le code généré n'est parfois (voire souvent) pas ce qu'on aurait écrit
- le travail en équipe n'est pas facilité, intégration avec les outils de versionning assez difficile
- dur de former les gens
- et puis quand on doit faire de la mise au point sur sa machine (je travaille en info indus.) et qu'on doit faire vite, c'est quand même plus simple de taper directement dans le code.
Je pense qu'il faut garder UML comme un outil d'analyse et de communication entre les développeurs. Les outils de génération enlèvent toute la souplesse d'UML.
Pour la qualité du code, de la doc. et du gain de temps, moi je pense qu'il vaut mieux dépenser son énergie à mettre en place une bonne politique de tests unitaires et d'intégration continue avec des outils comme CruiseControl, xUnit, ... et garder UML pour l'analyse et la doc.
# La conception est différente de la réalisation !
Posté par Cédric Brun (site web personnel) . Évalué à 3.
>- le logiciel d'édition UML est lourd à utiliser (utilisation >mémoire, licence,...)
Le projet Topcased fournit un modeleur UML plus que correct directement au sein d'Eclipse. Cela facilite le passage code/modèle modèle/code car tout est intégré dans le même environnement.
http://www.topcased.org/
> - impossible de faire des diff entre 2 versions
EMF compare permet de le faire directement depuis Eclipse,, qu'elle que soit le type de modèle.
http://www.eclipse.org/modeling/emft/?project=compare#compar(...)
> - 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)
Des outils comme Acceleo (et plus particulièrement la version pro) permettent de faire ce genre de round-trip : je renomme ma classe générée, l'outil me propose de mettre à jour le modèle et de re-générer.
>- 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.
Là le problème est plus lié à l'utilisation d'UML. Le modèle doit rester un modèle de conception et par conséquent abstrait. Tout ce qui est technique est très bien dans le code source mais n'a rien à faire dans le modèle. Ainsi utiliser UML avec un outil de génération qui va faire : "une classe UML" => "une classe CPP" incite à l'utiliser comme cela, mais la plus value est alors quasi-nulle. On pourrait utiliser une retro-ingénierie java vers UML (comme en propose Topcased) ou autre et on a le même résultat : un diagramme représentant le code source. Cela n'aide pas à la compréhension, et le modèle était alors fait de nombreuses classes techniques sa modification est ardue.
Vive les modèle UML qui restent abstrait, et où chaque élément modélisé provoque la génération de 4 ou 5 fichiers !
Il y'a plusieurs démonstrations sur le site Acceleo avec des modèles UML dont les éléments sont stéréotypés "métier", "écran" et qui permettent ainsi de générer une architecture de grande qualité pour les frameworks actuels.
PHP : http://www.acceleo.org/pages/module-uml2-vers-php
CSharp : http://www.acceleo.org/pages/module-uml-vers-csharp/
JEE : http://www.acceleo.org/pages/module-uml2-vers-jee-java-strut(...)
# Code puis UML
Posté par Jiba (site web personnel) . Évalué à 2.
[^] # Re: Code puis UML
Posté par Joc M . Évalué à 5.
Combien de briques logiciel j'ai vu, qui tentaient désespérément de régler un problème en laissant la moitié des cas d'utilisation dans un comportement dégradé car le véritables concepts métier n'était pas bien identifiés.
L'UML, c'est très bien pour abstraire un comportement. Alors si il faut utiliser UML pour tenter de représenter un choix d'implémentation dicté par les disponibilités techniques et les délais au moment du développement du logiciel, c'est sûr que ça va paraître inapproprié.
[^] # Re: Code puis UML
Posté par emanjo . Évalué à 3.
On peut discuter de ce que concevoir signifie, mais si l'on considère que Spécifier consiste à définir ce que le logiciel doit faire, on peut imaginer que concevoir consiste à définir comment le logiciel va le faire.
Donc concevoir, pour faire court, c'est poser une hypothèse d'architecture organique et allouer les exigences fonctionnelles, ou les exigences issues de l'architecture fonctionnelle.
Dans cette activité, les divers diagrammes d'UML permettent de représenter par affinages successifs la construction de cette architecture.
# UML ?? bof, des schemas simples au tableau oui
Posté par tanguy_k (site web personnel) . Évalué à 9.
Donc tu dessines tes schemas UML au tableau avec toute l'equipe, tu prends une photo du schema et tu l'upload sur ton SVN/CVS.
Inconvenient: on ne peut pas laisser un schema au tableau car celui-ci est regulierement efface (avantage: refaire le schema au tableau permet de bien voir si l'un des dev de l'equipe a bien tout compris)
[^] # Re: UML ?? bof, des schemas simples au tableau oui
Posté par Pierre Tramonson . Évalué à 4.
[^] # Re: UML ?? bof, des schemas simples au tableau oui
Posté par windu.2b . Évalué à 3.
POur éviter cela, un simple mot sur le tableau "Prière de ne pas effacer !!!" suffit amplement.
Et puis sinon, faudrait vérifier le contrat passé avec l'agence d'entretien, mais péter les 2 jambes de la femme de ménage doit sans doute être toléré.
====>[]
[^] # Re: UML ?? bof, des schemas simples au tableau oui
Posté par pyrollo (site web personnel) . Évalué à 1.
Maintenant, il y a ça : http://fr.wikipedia.org/wiki/Tableau_blanc_interactif
Idéal pour ce genre de chose, mais encore trop cher pour en avoir ailleurs qu'au service commercial...
[^] # Re: UML ?? bof, des schemas simples au tableau oui
Posté par BAud (site web personnel) . Évalué à 2.
cf. http://fr.wikipedia.org/wiki/Tableau_blanc#Tableau_blanc_.C3(...)
et http://wiki.jabberfr.org/Tableau_blanc liste plus complète de logiciels le gérant.
[^] # Re: UML ?? bof, des schemas simples au tableau oui
Posté par guignome (site web personnel) . Évalué à 2.
# Pas le bon outil ?
Posté par Obi MO (site web personnel) . Évalué à 2.
Donc out le formalisme vague d'UML, on peut parler de haut niveau et d'architecture, et dans le même formalisme descendre jusqu'au code embarqué. Les diffs sont gérés au niveau sémantique (pour la notation graphique)
Pour répondre à tes trois dernières questions:
>- comment faites-vous votre conception logicielle ?
J'utilise SCADE pour l'embarqué. ocaml + ocamldoc pour ce qui ne l'est pas.
>- quelles sont les limites des systèmes du genre de Doxygen ?
En interne on travaille sur ce type d'outils (ocamldoc), et on retrouve l'idée du "model-based": un seul "document", central, et tout est généré à partir de ça. Dire que ton code commenté comme il faut est le modèle, et générer docs, tracabilité, executable, schémas d'architecture, ça roxe. Attention au problèmes de granularité des fichiers cependant, la gestion de conf peut vite poser problème.
>- que pensez-vous d'UML ?
Bullshit ? Non, sans rire, c'est sympa pour s'échanger trois crobards, discuter au tableau et "brainstormer". Les préliminaires quoi. Quand on passe aux choses sérieuses, ça peut encore servir de feuille de route, mais rien de contractuel/officiel. Ensuite en rétro-documentation + retouche manuelle pour avoir quelque chose de présentable, ou pour plonger dans un gros projet qu'on ne connâit pas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.