UML & Merise ne sont utilisés que pour faire de zolis diagrammes, uniquement MCD et MPD (et généralement obtenu par ingénierie inverse) côté Merise, uniquement diagramme de classe et cas d'utilisation côté UML.
Les personnes maîtrisant ne serait-ce que 10% de l'un ou l'autre sont bien trop rares pour utiliser l'ensemble des diagrammes et modèles disponibles.
J'aurais l'air bien fin avec mon diagramme statut/état, ou mon MCT. Aucun utilisateur ou collègue ne saurait le lire, et donc encore moins le valider. Bref, rien ne remplace l'explication de texte pour l'analyse.
Autre chose : la plupart du temps, ça ne sert qu'un temps. Soit au démarrage du projet, soit lors des refontes et que le besoin de doc se fait sentir.
Dernière chose : sur la plupart de ces outils (ArgoUML, Rational, PowerDesigner, ...), je passe plus des 3/4 de mon temps à mettre en forme, alors que j'ai déjà une idée très précise de ce que je veux.
Le temps de configuration est également fastidieux ; je me rappelle de demi-journées passées à paramétrer les PowerDesigner de mes collaborateurs pour que la librairie Java soit bien identifiée, que le pilote ODBC soit bien paramétré, etc.
En un mot, j'ai un usage super limité de tout ça. UML, je ne m'en sers plus (marre de faire de la pédagogie au lieu d'avancer dans le projet), et je ne fais plus que des MCD. Le reste utilise un formalisme maison qui jusqu'ici convient à tous mes interlocuteurs, et qui est essentiellement textuel, avec des maquettes d'écran, et quelques schémas, mais pas trop.
L'UML est un échec cuisant. Cela devait réconcilier l'informaticien et ses utilisateurs en fournissant un langage commun. Sauf qu'il n'est enseigné qu'aux informaticiens, et qu'on veut à tout prix en faire un outil de génération de code.
Ma conclusion tient en peu de mots : c'est de la merde en boîte, dès qu'on va au delà des outils de base (MCD, MPD, Diagramme de classe) et/ou qu'on s'en contente pour communiquer avec les utilisateurs.
[^] # Re: Merise / UML
Posté par Dring . En réponse à la dépêche MeriseAcide, un outil d'aide à la modélisation Merise. Évalué à 9.
UML & Merise ne sont utilisés que pour faire de zolis diagrammes, uniquement MCD et MPD (et généralement obtenu par ingénierie inverse) côté Merise, uniquement diagramme de classe et cas d'utilisation côté UML.
Les personnes maîtrisant ne serait-ce que 10% de l'un ou l'autre sont bien trop rares pour utiliser l'ensemble des diagrammes et modèles disponibles.
J'aurais l'air bien fin avec mon diagramme statut/état, ou mon MCT. Aucun utilisateur ou collègue ne saurait le lire, et donc encore moins le valider. Bref, rien ne remplace l'explication de texte pour l'analyse.
Autre chose : la plupart du temps, ça ne sert qu'un temps. Soit au démarrage du projet, soit lors des refontes et que le besoin de doc se fait sentir.
Dernière chose : sur la plupart de ces outils (ArgoUML, Rational, PowerDesigner, ...), je passe plus des 3/4 de mon temps à mettre en forme, alors que j'ai déjà une idée très précise de ce que je veux.
Le temps de configuration est également fastidieux ; je me rappelle de demi-journées passées à paramétrer les PowerDesigner de mes collaborateurs pour que la librairie Java soit bien identifiée, que le pilote ODBC soit bien paramétré, etc.
En un mot, j'ai un usage super limité de tout ça. UML, je ne m'en sers plus (marre de faire de la pédagogie au lieu d'avancer dans le projet), et je ne fais plus que des MCD. Le reste utilise un formalisme maison qui jusqu'ici convient à tous mes interlocuteurs, et qui est essentiellement textuel, avec des maquettes d'écran, et quelques schémas, mais pas trop.
L'UML est un échec cuisant. Cela devait réconcilier l'informaticien et ses utilisateurs en fournissant un langage commun. Sauf qu'il n'est enseigné qu'aux informaticiens, et qu'on veut à tout prix en faire un outil de génération de code.
Ma conclusion tient en peu de mots : c'est de la merde en boîte, dès qu'on va au delà des outils de base (MCD, MPD, Diagramme de classe) et/ou qu'on s'en contente pour communiquer avec les utilisateurs.