Dans le domaine de l'embarqué critique (certifié comme tu l'as précisé) à ma connaissance on utilise très peu l'orienté objet, bien que certains ( Rhapsody http://modeling.telelogic.com/modeling/products/rhapsody/ind(...) ) essayent d'explorer cette voie. En tout cas le "model based design" a le vent en poupe, des trucs comme SCADE ( http://www.esterel-technologies.com/products/scade-suite/ ) sont fréquemments utilisés dans le domaine. L'idée c'est d'aller jusqu' à la génération du code embarqué avec des compilateurs qualifiés. Sans être du fonctionel, le language est purement déclaratif et a toutes les propriétés qui vont bien ( basé sur LUSTRE, il doit y avoir des compilos libres disponibles http://www-verimag.imag.fr/~synchron/index.php?page=lang-des(...) ) pour l'embarqué critique.
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.
# Pas le bon outil ?
Posté par Obi MO (site web personnel) . En réponse au journal Conception de logiciel et UML. É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.