Discussion :

[Matthieu Brucher]

Developpeur depuis de nombreuses années, en service integré ou en SSII en PME/PMI, je n'ai jamais vu un projet integralement UML. J'entend par intégral, de l'analyse à la génération du code (au moins les carcasses).

Dans 90% des cas d'usages, cela se borne à la realisation de MCD, le plus souvent parce que cela permet de déterminer la nature des relations des tables. Dans d'autres cas, à un usage un peu plus étendu, sur la partie conception générale, la plupart du temps pour donner le change (du style, nous aussi on fait de l'UML), et/ou pour être dans la tendance du moment. La partie conception detaillée restant proche du langage naturel.

J'ai l'impression que l'usage d'UML en France en tous cas, dans le monde des PME/PMI relève plus du phénomene marketo/mode que du besoin réel. Même si je ne doute pas de l'usage d'UML sur les (trés ?) gros projet, je mettrais UML dans la même bassine que SOAP, CORBA, et dans une certaine limite JAVA (pour les applications clientes). Je sais que je viens de mélanger torchons et serviettes, UML étant un language de modélisation plus qu'une technologie.

Je ne souhaite pas lancer un troll, juste profiter de ce forum pour avoir d'autres points de vue de développeur.

Est-ce que vous avez déja utilisé UML, de A à Z dans des projets moyens ?

D'autres part, je cherche justement, ce type de dossier. Des analyses de systemes d'informations avec UML dans des contextes de gestions 'simple'. Gestion commerciale, gestion des achats, ou autres. J'ai beau chercher sur google, et je n'ai rien trouvé.

Pour finir. Je suis un developpeur qui a 18 ans d'expérience mais pas de diplômes. Je souhaitais profiter d'une période de chômage pour user mes jeans sur les bancs d'école mais je m'aperçois que l'UML est aujourd'hui omniprésent dans la plupart des cours liés à l'analyse, que ce soit au niveau de formations privés comme des formations publiques type CNAM, AFPA.

La question que je me pose, est-ce que ca vaut le coup d'apprendre l'UML si finalement son application dans le millieu du travail est rare.

Voir aussi : Cours et tutoriels pour apprendre UML

[Cian]

Developpeur depuis de nombreuses années, en service integré ou en SSII en PME/PMI, je n'ai jamais vu un projet integralement UML. J'entend par integral, de l'analyse à la génération du code (au moins les carcasses).

Pourtant cela existe De nombreuses entreprises font ainsi.

Dans 90% des cas d'usages, cela borne à la realisation de MCD,

Sauf qu'il n'y a pas de MCD dans UML... A moins que tu ne veuille parler du diagramme de classes? Mais saches que c'est très différent!

Dans d'autres cas, à un usage un peu plus étendu, sur la partie conception générale, la plupart du temps pour donner le change (du style, nous aussi on fait de l'UML), et/ou pour etre dans la tendance du moment. La partie conception detaillée restant proche du langage naturel.

C'est un jugement un peu sévère je trouve... Certaines entreprises ne font pas clairement un choix d'utiliser UML. Dans ce cas, qqfois les individus choisissent d'utiliser ce langage pr éviter de représenter sous Powerpoint. Mais sans formation... Ce qui peut amener à des résultats très moyens.

J'ai l'impression que l'usage d'UML en France en tous cas, dans le monde des PME/PMI releve plus du phénomene marketo/mode que du besoin réel.

Je n'ai pas de données sur la pertinence de l'utilisation d'UML dans le contexte PME/PMI. Mais au prix d'une licence Rose ou de tt autre outil permettant de générer du code, je pense que ceux qui choisissent cette stratégie en général l'applique... surtout ds un contexte PME/PMI...

Même si je ne doute pas de l'usage d'UML sur les (trés ?) gros projet, je mettrai UML dans la même bassine que SOAP, CORBA, et dans une certaine limite java (pour les applications clientes). Je sais que je viens de melanger torchons et serviettes, UML etant un language de modélisation plus qu'une technologie.

Toutes ces technos ont au moins un point commun : le standard. Ce sont toutes des standards. Pourquoi connaissent-elles du succès ? Au delà de l'effet de mode, pour faire communiquer les mondes il faut des interfaces standarisées.
UML fait partie de cette notion puisqu'il permet une communication standard entre des individus de background différents.

D'autres part, je cherche justement, ce type de dossier. Des analyses de systemes d'informations avec UML dans des contextes de gestions 'simple'. Gestion commerciale, gestion des achats, ou autres. J'ai beau chercher sur google, et je n'ai rien trouvé.

A part des exemples tirés d'étude de cas pour les étudiants, tu ne trouveras rien d'autres. Pourquoi ? Parce qu'on évite de publier les architectures des systèmes qu'on développe sur le net. Ce serait du suicide...

La question que je me pose, est-ce que ca vaut le coup d'apprendre l'UML si finalement son application dans le millieu du travail est rare.

Tu as un préjugé faux : son utilisation n'est pas rare. Et même si tu ne pouvais pas l'appliquer de suite, ce sera tjrs un bon moyen de t'ouvrir l'esprit aux technos de modélisation. Si on ne devait apprendre que les trucs dont on compte se servir immédiatement... on apprendrait jamais rien...

[chess]

Developpeur depuis de nombreuses années, en service integré ou en SSII en PME/PMI, je n'ai jamais vu un projet integralement UML. J'entend par integral, de l'analyse à la génération du code (au moins les carcasses).

Pourtant cela existe De nombreuses entreprises font ainsi.

Certes, on travaille peut etre pas dans le même pays, et peut etre, ne fait-on pas le même metier ? Plus serieusement, j'ai questionné d'autres collegues, à differents postes, de DI à developpeur débutant. Ce sondage n'est pas réellement significatif dans la mesure où le nombre de personnes consultées etait d'environ 10 personnes, la majorité travaillant en SSII, mais il permet au moins de comprendre mes interrogations sur l'usage d'UML.

Sauf qu'il n'y a pas de MCD dans UML... A moins que tu ne veuille parler du diagramme de classes? Mais saches que c'est très différent!

Ok, on va parler purement UML. Peut etre l'expression de diagramme de classes des entités serait plus appropriée, enfin plus ressemblante ?

C'est un jugement un peu sévère je trouve... Certaines entreprises ne font pas clairement un choix d'utiliser UML. Dans ce cas, qqfois les individus choisissent d'utiliser ce langage pr éviter de représenter sous Powerpoint. Mais sans formation... Ce qui peut amener à des résultats très moyens.

Voila ce qu'il ressort de mon micro-sondage :
Dans les SSII concernées, UML est perçu comme une source de dépenses supplémentaires non justifiées, tant au niveau de l'analyse que pour la conduite du projet. Ce que je viens de decrire, c'est le message qui circule à l'interieure des SSII, la parole officieuse. Reste le client, qu'il faut séduire, et qui n'est pas nécéssairement un informaticien. Lui à lu, entendu (mais jamais utilisé) que l'UML apportait une grande aide dans l'analyse du future SI, mais également des solutions pour la conduite du projet, et voudra donc voir de l'UML dans le cahier des charges. Alors on sort visio, object builder, ou d'autres d'outils afin de mettre la pincée d'UML necessaire dans le cahier des charges. J'en connais même qui font du reverse UML, pour cracher les diagrammes d'aprés le code objet existant et qui le glisse dans le dossier.

Je n'ai pas de données sur la pertinence de l'utilisation d'UML dans le contexte PME/PMI. Mais au prix d'une licence Rose ou de tt autre outil permettant de générer du code, je pense que ceux qui choisissent cette stratégie en général l'applique... surtout ds un contexte PME/PMI...

Ca me parait important pourtant. Il y a environ 5,5 millions de PME/PMI en france, ca represente la plus grande part des entreprises. C'est aussi sous cette forme que l'on retrouve la majeure partie des SSII. Maintenant, je ne sais pas combien de licence Rational Rose se sont vendues.

Au delà de l'effet de mode, pour faire communiquer les mondes il faut des interfaces standarisées.
UML fait partie de cette notion puisqu'il permet une communication standard entre des individus de background différents.

Quel standard ?. Celui de la diversité des JVM, de la théorique portabilité de Java, de la pauvreté des services réellement implémentés sur Corba, du réelle usage de Corba, de l'impossibilité de faire communiquer 2 corba issus de deux 'fabriquant' différents, et de l'inexistance de SOAP sur le marché. Je crois que le mot standard en informatique n'a guere de sens.
Quant aux succés, hormis Java dans le cadre de developpement de serveur, pour les autres ca reste des succés d'estime pour etre gentil.
Il ne faut pas confondre les articles de presse et la vrai vie.

A part des exemples tirés d'étude de cas pour les étudiants, tu ne trouveras rien d'autres. Pourquoi ? Parce qu'on évite de publier les architectures des systèmes qu'on deeveloppe sur le net. Ce serait du suicide...

Mouais. Tout en informatique ne relève pas de la haute technologie ou d'informatique de pointe. Ce dont je parle là, c'est de gestion. Je ne vois pas en quoi il serait 'suicidaire' de publier un cahier des charges autour par exemple d'une gestion commerciale, mais version UML. J'en ai monté environ 4 durant ma carriere (non UML), et il n'y a rien qui releve de l'innovation technologique. Ce sont des cahiers des charges comme bien d'autres SSII en sont rédigés.

Tu as un préjugé faux : son utilisation n'est pas rare. Et même si tu ne pouvais pas l'appliquer de suite, ce sera tjrs un bon moyen de t'ouvrir l'esprit aux technos de modélisation.

Attention, c'etait pas un préjugé, mais juste une question. Dans le cas contraire, je n'aurais pas fait de post sur ce forum. Aprés, sur l'utilisation de l'UML en entreprise, trés franchement, hormis mon micro sondage, je n'ai absolument aucun chiffre, d'où ma question.
Le fait que l'UML soit présent dans les cours de l'AFPA, du CNAM ou en université n'est pas trés significatif non plus. Il y a toujours eu un gros écart entre l'education et le monde du travail en tout cas pour la partie que je connais le mieux, c'est dire le développement informatique.

^Si on ne devait apprendre que les trucs dont on compte se servir immédiatement... on apprendrait jamais rien...

Je pense que tu es soit universitaire, prof, chercheur ou consultant pour dire une telle chose. Dans la vraie vie, et ce, quelque soit la taille de l'entreprise (SSII ou pas), on apprend toujours parce que l'on va en avoir besoin immédiatement.

Ce qui m'etonne également quand on regarde l'ensemble des forums 'developpez', c'est le peu de post que l'on retrouve dans la section UML et modélisation en rapport des autres forums 'developpez'. C'est un signe ?

Je vais arreter d'etre caustique. Plus serieusement, pour avoir lu 2 ouvrages sur UML, et cherché des infos sur le web, je pense en avoir compris la demarche et l'utilité, et ce n'est pas ça dont je doute. En revanche, ce que je sais moins, c'est par exemple, quel est le delta de travail que demande un cahier des charges version UML, quel cout cela implique. A-t-on un recul, des chiffres, des statistiques, enfin bref, a-t-on reussi à quantifier l'efficacité d'UML.

Quoiqu'il en soit, je te remercie pour ta réponse. En esperant que plus de personnes participent dans le thread.

[jacma]

Quoiqu'il en soit, je te remercie pour ta réponse. En esperant que plus de personne participe dans le thread.

Pour répondre à tes voeux
J'ai essayé de me mettre à UML, pour l'instant sans gros résultats. Peut-être est-ce dû au fait que :
- j'essaye seul (enfin dans ce forum ou équivalent et 3 ou 4 bouquins de base),
- que je trouve assez peu d'aide qui me soit compréhensible,
- et que les exemples glanés de ci de là ne correspondent en rien à ce que je souhaite mettre en oeuvre et sont trop parcellaires.

Je traite comme toi de ce qui tourne autour de la gestion/ comptabilité/ facturation... et j'aurais aimé trouver un exemple simple et complet concernant une facturation. En effet, je ne peux vraiment apprendre que sur du concret, qui de plus correspond à ma préoccupation.

Je retrouve dans UML, tout au moins dans les cas d'utilisation (je ne suis pas allé plus loin pour l'instant) une démarche générale d'organisation que l'on connaissait à mon époque sous le terme de QQOQC (qui, quoi, ou, quand, comment) sans le formalisme et la complication affichés dans les bouquins UML.
Idem d'ailleurs pour les diagrammes de séquences.

D'une façon générale, j'ai fortement l'impression que, comme pour beaucoup d'autres sujets (informatiques ou autres), la démarche universitaire (ses clans, ses chapelles..), relayée par la démarche marketing et l'effet de mode, a souvent pour résultat de compliquer (théoriser?) énormément les choses. Pour un universitaire, c'est peut être satisfaisant, mais pour le quidam moyen :
Bref, j'ai trouvé l'emploi des cas d'utilisation très compliqués et très lourd, et je me demande comme toi si cela apporte véritablement quelque chose de plus au niveau d'une analyse.

Je ne remets pas en cause l'utilité de l'analyse elle même, mais seulement celle de l'outil employé. Quand à mettre en avant un autre outil, j'en suis incapable, étant par trop empirique en la matière. A vrai dire, le seul point qui m'intéresse vraiment, et pour lequel j'ai quelque compétence, est plutôt la partie métier d'une application.
Ceci étant, il faut sans doute relativiser ma position, car je ne suis pas informaticien de métier, seulement un utilisateur disons "averti" et j'ai appris le peu que je sais au fil des 30 années passées. Et ce que je sais d'UML ou rien, c'est pareil.
Pour finir, je suis également étonné du peu d'activité du forum, compte tenu de l'intérêt affiché partout pour UML. Ceci n'enlève rien au travail réalisé par ses animateurs Et comme je n'en sais pas assez, ni pour contribuer, ni pour renouveler mes questions, je me contente de lire régulièrement les contributions. Peut-être cela me fera-t-il progresser, voire changer d'avis sur UML.
Pour finir, UML pour moi et pour l'instant peut-être, c'est plutôt ULM

[miel_pops]

Personnellement je trouve qu'U.M.L est assez simple contrairement à ce que tu dis Chess. C'est vrai que je n'utilise que peu de choses : diagramme de classes, cas d'utilisation, diagramme de séquence et diagramme d'état. Si les schémas pris de haut semblent complexes en les regardant de prêt le principe est très simple. Bon à la rigueur il y a O.C.L qui est un peu compliqué mais une bonne phrase en français décrit tout aussi bien des contraintes.
Je pense qu'U.M.L est une boite à outils, tu prends ce que tu veux et tu t'en sers à ta guise.

Maintenant pour ce qui est de l’utilité c’est à chacun de voir, effectivement les pme/pmi n’ont pas forcément besoin de Rational rose, mais U.M.L est un langage d’analyse et tu peux très bien faire toute ton analyse avec un papier et un crayon. Une analyse détaillée permet de situer et de comprendre chaque élément de ton programme. On peut toujours s’en passer mais dès que le projet devient complexe je crois que ça fait plus gagner de temps et d’argent que ça n’en fait perdre (oui c’est une affirmation gratuite qui n’engage que moi, je n’ai pas vraiment de preuve à l’appui mais c’est mon intime conviction ).

J’ai fait un stage il y a quelques mois où j’ai repris le travail de quelqu’un, ce n’était pas un énorme projet mais il n’était pas ridicule… je peux te dire que quand j’ai appris qu’il n’y avait pas d’analyse faite (à part un MCD pour la BDD qui ne correspondait pas à ce qui avait déjà été codé) j’ai un peu pleuré...
Pourtant la personne codait clairement, de jolis noms de fonction, des commentaires clairs mais pour comprendre ce qu’il a voulu faire. :S
Résultat j’ai dû recoder la moitié de ce qu’il avait fait (hé oui car il y avait des choses qui ne marchaient pas du tout, d’autres à moitiés et d’autre enfin tournaient correctement… il était beaucoup plus rapide pour moi de recoder ces morceaux que de faire des batteries de tests et de faire la maçonnerie par dessus ce qu’il avait fait).

Si tu veux reprendre un programme, que ce soit le tien ou celui de quelqu’un d’autre rien ne vaut une bonne analyse U.M.L quand même. Ne ce serait ce que pour la maintenance c’est très utile.
Ca prend du temps l’analyse, mais tu en gagnes lors du codage : tu sais où tu vas, tu cafouilles moins et je suis persuadé (attention deuxième assertion gratuite ) qu’au final ton application est beaucoup mieux pensée et donc moins buguée.

Maintenant je comprends les gens qui n’ont pas envie de prendre le temps de faire cette analyse pour coder directement. Et j’ai même envie de dire que les programmeurs chevronnés sont probablement capables de faire une application structurée impeccable pour un projet de taille raisonnable. Reste que le jour où ils partent, ce ne sera pas facile quand même si tu dois y retoucher.

PS : Au passage j'ai fait mes études en DUT et pour le moment je suis assez loin du monde du travail.

[chess]

Pour Jacma :
Merci pour ton apport. Je suis un peu comme toi, dans l'attente d'un cahier des charges full UML sur un 'bête' exemple en gestion commerciale. C'est vrai qu'une analyse pour une facturation, c'est le dosage recherché. Pas trop complexe mais pas trop simpliste non plus. Ca serait top pour comprendre et comparer par rapport à une analyse exprimée 'classique'.

Pour Miel_pops
Attention. Je ne remet pas en cause une analyse. Surtout pas. Je peux te dire que si j'avais à retenir une lesson pendant ces années de travail, c'est celle de ne JAMAIS bacler une analyse, quitte à te battre avec ta direction si necessaire (c'est du vécu ).
La question est : Quel est l'interrêt de la rediger avec UML. Pour ma part, j'ai toujours fait cela en français, en ajoutant des diagrammes simples (forme basée sur les organigrammes) et avec des MCDs.

Pour Cian
Un petit mot que j'ai oublié sur mon dernier méssage. Je voulais juste dire
bravo pour la FAQ -> "les toutes premières questions que UML2.0 soulève" , je l'ai trouvé vraiment trés bien.

[Anthony78]

perso je ne suis pas adepte de modélisation, limite ca me saoule de le faire.

pourtant ... je suis assez adepte d'UML, qui comparativement a merise est beaucoup plus souple, complet, precis, etc...
surtout, grace a UML 2 (a voir si ca se confirme sur une utilisation) la modélisation devient tres claire et encore plus précise.
et grace a MDA, le gain de productivité est enorme si l'on a les outils qui vont bien...

et pour répondre au sujet initial : l'entreprise ou j'ai fait mon stage l'an dernier modélisait beaucoup en UML (classe + séquence, voire quelques diagrammes d'états), et généraient le code ou le reversait (reverse engeneering).

[n.patricia]

Dans la vraie vie, et ce, quelque soit la taille de l'entreprise (SSII ou pas), on apprend toujours parce que l'on va en avoir besoin immédiatement.

C'est bien le problème d'UML. Beaucoup de personnes veulent faire de l'UML parce que c'est à la mode. Il y a donc formation à la va vite pour en faire tout de suite et forcement ca ne marche pas ou c'est très mal utilisé.

Rien que d'entendre ce genre de phrase qui revient trop souvent : "nous utilisons la méthode UML pour ....", c'est très significatif. UML n'est qu'un formalisme et il faut avoir une méthodologie associée.

UML est associé à l'objet et ca ne s'apprend pas du jour au lendemain. Il faut du temps pour intégrer les concepts. Par contre, une fois intégré, ca devient très naturel et il est possible de l'utiliser de A à Z et sur n'importe quel projet.

Je pratique l'objet depuis la fin de année 80, les méthodes objets depuis le début des années 90 et UML depuis le milieu des années 90. Ca ne me pose aucun problème de l'utiliser sur n'importe quelle taille de projet. Bien entendu, il faut adapter l'effort suivant la taille du projet.

D'autres part, je cherche justement, ce type de dossier. Des analyses de systemes d'informations avec UML dans des contextes de gestions 'simple'. Gestion commerciale, gestion des achats, ou autres. J'ai beau chercher sur google, et je n'ai rien trouvé.

Même avis que Cian. Tu ne trouveras jamais un exemple complet d'un projet dans le type que tu recherche. Tu trouvera des calculatrices ou ce genre de chose qui ne t'apporte pas grand chose.

La question que je me pose, est-ce que ca vaut le coup d'apprendre l'UML si finalement son application dans le millieu du travail est rare.

Il n'est pas rare de rencontrer UML sur différents projets en entreprise.

Par contre, il y a généralement une structure apte à développer la culture objet et UML pour que cela marche vraiment.

Le problème d'UML est que bien souvent, tous les acteurs d'un projet ne le maitrise pas. Le "L" d'UML veut dire Language et comme tout langage il est nécessaire que tout le monde le parle pour ce comprendre.

Au sein d'une même société, quand tu fais des Use Cases pour faire valider à une MOA qui n'a jamais entendu parler d'UML, ca ne passe pas bien.

Le problème est le même dans la relation ssii/client. Tu peux dire que tu fais de l'UML, si le client ne connait pas c'est très mal engagé.

D'autre part, il vaut mieux miser sur ce qui est rare mais pas inexistant. Ca rapporte beaucoup plus que ce qui est très courant et saturé

[ChristopheH]

Personnellement, Je pense qu'UML est un formidable outils de communication. Il permet de faire le point sur le code. Mais il ne faut pas s'engluer dans l'administratif. C'est aussi un bon language pour apprendre les techique avancée de programmation objet. C'est peu être pour ca que les universitaires aiment tellement UML.

Je viens de terminer le livre de Creg Larman sur les pattern GRASP et les design patterns (je vous le recommande à tous il est mieux qu'UML en action). Je sais ca reste très théorique. Mais j'ai plus appris en lisant ce livre sur l'architecture qu'en codant 20 applications.

Par exemple ca faisait longtemps que je voulais savoir comment fonctionnent les mécanismes d'évenements dans les API Swing et AWT de java. Il a suffit de trois pages de diagramme UML et un peu de justification pour que le principe de partten Observeur devienne limpide. Grace à UML et aus design patterns decrits en UML, mes programmes ressemblerons moins au plat de nouille que je faisait avant. Si si! On peu faire des spagettis en programmation objet.

C'est grace à UML qu'on peut expliquer des concept de réutilisation de classe. Bon, c'est sur, c'est un language. Il faut l'apprendre. Mais moi, je pense que c'est indispenssable si on travaille en équipe ; c'est très utile quand on travaille seul et c'est un outils didactique très efficace.

[Galevsky]

Ma petite participation :

UML est un formalisme........ donc utile car ça simplifie et aide la modélisation. C'est un outil, tel un marteau qui aide le charpentier à enfoncer des clous. Par contre si le charpentier n'a pas de savoir de charpentier, ce n'est pas le marteau qui va l'aider !

En revanche je trouve personnellement l'uml trop jeune et incomplet. Pour ma part, il manque pas mal d'outils spécifiques, comme des bouclages temporels etc.... et ça nuit à la finalité, car si un formalisme a des manques, cela introduit une part non formalisée dans l'application => ce n'est plus formalisé dans l'ensemble .

Mais espérons qu'il va évoluer et devenir un package complet au service de la modélisation objet. Mais le plus important pour moi, et le fait qu'il s'agit un ensemble d'outil à disposition de tous, qui doit être utilisé de façon différente pour chaque personne, car l'uml s'adapte très bien à n'importe qu'elle procédure, ou démarche de modélisation et ce quelle que soit la culture de l'entreprise.

[ChristopheH]

UML est un formalisme........ donc utile car ça simplifie et aide la modélisation. C'est un outil, tel un marteau qui aide le charpentier à enfoncer des clous. Par contre si le charpentier n'a pas de savoir de charpentier, ce n'est pas le marteau qui va l'aider !

[/list]
Je vois UML plutôt comme un plan. C'est Grady Booch qui fait ce parallèle avec la construction d'une maison ou d'un immeuble. Il suffit d'imagimer un enterpreneur qui veuille vendre des maisons sans recourir aux services d'un archiecte. Il va dire : ce n'est pas grave, on sait construre des maison. Je pense que cette attitude est aussi inconciente que celle du développeur qui saute sur son clavier sans même avoir fait un schema. Dans le meilleurs des cas, il peut construire une niche au chien ou une cabane à oiseau, mais ceratainement pas une maison, un immeuble ou un pont.
Le plan ne sert pas à embetter les massons ou à donner de l'argent à un architecte. C'est un outils de communication et il à interet à être bien fait. Car c'est lui qui va permettre d'aller au bout du projet, de cohordonner les different corps de metiers (developpeurs, experts BDDR, experts IHM etc..). L'interet en informatique, c'est qu'avec une approche de processus unifé comme RUP, le plan change regulièrement. C'est inconcevable pour un constructeur.

[Cian]

UML est un formalisme

Juste pour corriger même si c'est couramment dit UML n'est pas un formalisme. UML est langage semi-formel.

[quilo]

(Bon courage pour lire cette réponse)

Pour répondre un peu à toutes ces affirmations :

UML n'est rien sans une méthode. Le problème avec UML est que les vieux routards ne savent pas vraiment comment l'aborder et que les nouveaux venus croient tout savoir car il est à la mode. Je fais plutot partie de ces derniers, je l'avoue. Mais les vieux routards restent un peu bornés sur Merise en se disant qu'UML définit la même chose que Merise c'est-à-dire un langage et une méthode. J'ai entendu un de mes profs m'affirmer que UML était une méthode mais il ne savait pas comment l'appréhender. Mais je l'ai également entendu dire que l'objet ne servait qu'à mieux ordonner les bibliothèques de méthodes. Je pense que tout ça vient d'un manque d'infos ou d'un manque de curiosité envers ces "nouvelles technologies". C'est toujours faire ce que l'on faisait avant mais autrement se disent-ils. Ce qu'il faudrait faire c'est ajouter une méthode derrière UML (le nom). Ainsi on pourrait avoir U.M.L.-U.P. par exemple et là les vieux routards ne s'attarderaient pas qu'à UML mais aussi à une méthode. Le marketing ferait s'intéresser les vieux routards à une méthode qui pourrait aller avec UML. Le problème est que l'on peut prendre plusieurs méthodes dans lesquelles est intégré UML. Mais c'est peut-être pas facile à saisir pour des personnes qui ont toujours utilisé un langage lié uniquement à une méthode et vice versa.
Même au cours on apprend UML comme on apprenait Merise en pensant que la méthode y est intégrée. L'intitulé des cours devrait être "Processus Unifié et UML".
Dans les PME et SSII, ce sont ces vieux routards qui décident des formations à suivre, des formalismes à utiliser, etc... alors que ces ont peut-être les moins bien reseignés. Les formations offertes par les entreprises sont de trop courtes durées pour avoir un réel impact. Il faudrait un suivi des formateurs sur plusieurs mois.

Encore une chose : Je pense que l'on comprend mieux le monde objet, les GRASP et les design pattern avec UML. Et plus on avance et plus l'utilisation d'UML semble évidente lorsqu'on fait de l'objet alors qu'au début les réactions sont toujours les mêmes : on est perdu devant tant et si peu d'informations et de désinformations alors le meilleur moyen pour moi : acheter "Le processus unifié de dévellopement informatique" et "UML par la pratique" (ou un autre du même genre) et faire des petits projets perso en java, en C# ou encore en C++ ou encore mieux dans deux de ces langages. L'analyse métier sera toujours la même mais on pourra s'amuser du côté de la conception.

Je ne sais pas si j'ai été vraiment clair mais j'ai au moins participé au post en tous cas

[Mascotte]

UML n'est rien sans une méthode.
[...]
Ainsi on pourrait avoir U.M.L.-U.P.

J'adhère totalement à ces propos. Pour avoir dû présenter UML à mon vieux routard de chef de projet, je le vois totalement récalcitrant à UML. Par contre il a été emballé par 2UP. J'ai été surprise ! Faut dire que je n'arrête pas de lui dire : "l e plus important, c'est la démarche UP, UML n'est qu'un langage" (pour ne pas l'effrayer encore plus). Et ça marche !

acheter "Le processus unifié de dévellopement informatique" et "UML par la pratique"

Même démarche... mais dur dur de faire UML par la pratique tout en pratiquant direct dans le grand bain avec un projet grandeur nature

Je ne sais pas si j'ai été vraiment clair mais j'ai au moins participé au post en tous cas

Moi j'ai tout compris ! mais c'est parce que ça sentait le vécu

Je ne connais pas Merise, donc je ne peux pas faire de comparaison. Pour moi, le plus important est de pouvoir modéliser, de faire un cahier des charges bétonné où on s'est poser un maximum de bonnes questions et de pouvoir formaliser tout ça (tant que ce n'est pas formalisé, on ne peut pas être sur qu'on a bien réellement compris le cahier des charges). Pour avoir essayé récemment 2UP et UML, je suis assez satisfaite et mon client est carrément enthousiaste !

[silvermoon]

UML est associé à l'objet et ca ne s'apprend pas du jour au lendemain. Il faut du temps pour intégrer les concepts. Par contre, une fois intégré, ca devient très naturel et il est possible de l'utiliser de A à Z et sur n'importe quel projet.

J'en doute, tout dépend du projet il ne s'adapte pas forcément à tous, j'ai essayé de l'utiliser avec l'application que j'ai actuellement j ai laissé tomber beaucoup trop lourd.

Même avis que Cian. Tu ne trouveras jamais un exemple complet d'un projet dans le type que tu recherche. Tu trouvera des calculatrices ou ce genre de chose qui ne t'apporte pas grand chose.

Pourquoi ?
je ne pense pas être un concurrent de chess
mais je bosse également sur des appli du même type.
Actuellement il y a des projets en cours opensource qui n'avance pas beaucoup certe mais qui doivent être fait en uml au niveau analyse il suffit d'attendre.

Par contre ce que ce que je ne comprend pas bien ce sont les personnes qui parlent de l'uml comme d'un remplaçant à Merise.

Je n'y vois aucun rapport, seulement un complément.
Merise pour les bases de données, je l'utilise en permanence.
UML pour le code, je ne l'utilise pas mais bon peut être que je devrais passer un cap pour sa.

Mais ce n est pas pour autant que je n'ai pas d'analyse.

Comme plusieurs l'on dit je pense que l'uml est une mode, tout comme le java, c est beau, sa plait aux clients sa montre que l'on est à la dernière mode. Mais franchement est ce que le code générer par les logiciels UML sont propre, j'en ai vu c est un peu le bordel.
Je lis pas mal de journaux sur l'évolution de l'uml et beaucoup disent qu'il y a encore du boulot de se coté là. Donc peut etre que l'on vite pour l'analyse mais si on doit reprendre le code derrière pas grand interet pour le moment mais je ne dis pas que dans l'avenir l'uml ne sera pas incontournable comme merise.

un pti aparté ceux qui ont touché aux bases de données et fait des shémas par exemple dans access ou autre et qui pensaient ne pas avoir utiliser Merise ils se trompent ils viennent de l'utiliser sans le savoir

[PsychicStorm]

J'en doute, tout dépend du projet il ne s'adapte pas forcément à tous, j'ai essayé de l'utiliser avec l'application que j'ai actuellement j ai laissé tomber beaucoup trop lourd.

Je pense qu'il faut simplifier ou créer différents diagrammes à différents niveau. Si tu dois tout décrire c'est clair que tu risques de passer toute ta vie . Sinon c'est vrai qu'il faut s'habituer à ne pas écrire une seule ligne de code pendant plusieurs jours. J'ai beaucoup de mal parce que ça me frustre je pense où j'ai pas l'impression d'avancer.

Comme plusieurs l'on dit je pense que l'uml est une mode, tout comme le java, c est beau, sa plait aux clients sa montre que l'on est à la dernière mode. Mais franchement est ce que le code générer par les logiciels UML sont propre, j'en ai vu c est un peu le bordel.

Il faut voir dans le projet car la conception représente 60% du temps pour développer un logiciel donc ça donne l'impression à ton client que tu n'as pas glandé pendant 50% du temps . Le but des logiciels comme rational rose ou autre, c'est de pouvoir permettre au client de tester le logiciel. Il vaut mieux faire les correctifs d'architecture avant le codage qu'après.

Avis perso : je n'ai jamais trouvé un interêt quelconque à Merise à part construire un MCD mais jusqu'à présent je fais le MLD direct .
Avec Merise, je ne peux pas décrire les objets, leurs interactions, etc... Par contre UML me le permet mais c'est un LANGUAGE !!! sans technique de conception c'est comme si tu te retrouvais avec un outil sans savoir t'en servir.

[Mascotte]

Comme plusieurs l'on dit je pense que l'uml est une mode, tout comme le java, c est beau, sa plait aux clients sa montre que l'on est à la dernière mode. Mais franchement est ce que le code générer par les logiciels UML sont propre, j'en ai vu c est un peu le bordel.

Oups ! Sglurp ! Qu'est-ce qu'il ne faut pas lire ! Tu mélanges outils et langages ! Il ne faut pas critiquer l'UML parce que Rational Rose ou Together font un mauvais travail de conversion de diagrammes de classe vers du code.

1/ ça ne concerne qu'un type de diagramme il ne faut pas réduire UML à ses diagrammes de classe
2/ J'ai fait quelques conversions Together / JBuilder en Java et le squelette du code était correct. Il reste aux développeurs à écrire encore leur code.

[bibiodp]

Etant un jeune développeur, j'utilise surtout les outils que l'on m'a enseignés. Et pour le développement logiciel, j'utilise une méthode très récente : MACAO. MACAO est une méthode "concurrente" à MERISE qui s'appuie sur l'objet et UML. Alors oui je me sers d'UML mais il est vrai que suivre tout le formalisme de tels méthodes et langage pour le développement de petites applisn'est pas toujours la solution la plus simple. En tout cas, UML est très présent pour la phase de conception du logiciel.

[Cian]

UML est certes porté par de gros investisseurs qui savent jouer du marketing. Toutefois son succès ne peut pas se résumer à un bon coup marketing. Nous savons tous que les effets de mode passent. Or UML a été crée il y a presque 10 ans. C'est donc plus que de l'effet de mode.
C'est seulement que les gens y trouve leur compte.
Pourquoi ?
- parce que quand on est impliqué dans de gros projets avec de la complexité, il faut manager cette complexité. Penser aujourd'hui qu'un homme peut tout avoir en tête et tout maîtriser sur un projet est illusoire et représente un gros risque.
- parce que les différents intervenants d'un projet ( maitrise d'oeuvre, sub, fournisseurs, client) cherchent un même langage de communication et que le langage textuel est source de trop d'ambuguités, que les schémas de chacun sous powerpoint suivent des règles personnelles...
- enfin, parce que les activités qui coutent le plus sont les tests et qu'on ne peut plus se permettre de se tromper lorsqu'on fait une architecture de systèmes de systèmes. Alors on essaye de miser sur le design en se dotant d'outils.

Alors bien sûr appliquer toute la méthode, utiliser tous les diagrammes, cela peut-être un peu lourd. C'est pour cela que nous martelons que UML doit être associé à un processus. Ce processus peut être un processus existant mais en réalité nombre d'entreprise adapte un processus existant à leur manière de travailler. C'est une boîte à outils : il faut donc choisir
le(s) meilleur(s) en fonction de ce qu'on fait.

Concernant la génération de code, il faut faire une distinction entre la techno et les outils. Certains outils sont plus performants que d'autres.
De tte maniere, je ne me fais aucun souci. Avec toute l'utilisation qui est faite de la génération auto de code dans des industries comme le téléphone portable, il y aura des progres non négligeables en la matière dans un moyen terme.
La génération de code auto etait une chose maitrisée dans d'autres langages de modélisation, cela a été éprouvé et utilisé.
Il faut juste attendre que les concepts UML soient assez formel pour que cela puisse se faire. Cela avance avec UML2.0 qui va déjà permettre de faire de la simulation.

En ce qui concerne la disponibilité sur le net de projet en UML, je peux vous assurer que n'importe lequel d'entre vous qui proposerait à sa hierarchie de diffuser un modèle sur le net, se verrais présenter une moue significative. Pourquoi ? Parce qu'avec un modèle votre concurrent dispose de votre architecture. ET donc a d ebonnes indications pour faire ce que vous faites. Certes c'est caricatural. Mais si on reprend la comparaison des architectes (de maison) on comprend de suite : les architecte proposent des plans sur le net mais se sont souvent des plans bateaux, ou un exemple de leur savoir-faire. Mais pas tout leur catalogue!
Et sur le net, bien sûr, on est suceptible de trouver n'importe lequel de ses concurents... Après bien sûr en ce qui concerne la communauté open source le débat est différent.

[ericlemoustic]

Bonjour,

J’ose me mêler à la conversation.

Je travaille dans l’administration qui a une très forte culture merisienne.

J’ai suivi les cours du CNAM. J’ai entre autre eu une unité de valeur sur UML.

Pour ma part , je pense que Merise ou UML sont équivalent.

Comme disait Quilo, UML n’est rien sans méthode. C’est pareil pour Merise.

Pour mon expérience, je dirais que UML est plus simple à mettre en œuvre que Merise. Merise ne s’adresse qu’à des informaticiens (essayer de montrer un MCD à un MOA).

Avec Merise, on n'utilise que le MCD. Je n'ai pas vu de projet entièrement fait avec les autres diagrammes (MCT par exemple). Ou alors avec des projets qui s'étalent sur 20 ans comme les propjets du ministère des finances et qui ne sont pas encore terminées LOL.

Tandis qu’avec UML il est possible, en expliquant les principaux concepts (les Uses Cases et les diagrammes de séquences) pour la MOA, de dialoguer avec elle. De plus avec UML, on peut plus ou moins complexifier les diagrammes.

Ensuite, en partant des mêmes diagrammes, on peut les compléter et faire les autres diagramme pour l’équipe informatique.

Enfin, Merise est destiné uniquement à la modélisation d'un système d'information (faite attention, un système d'information n'est pas un système infirmatique comme beaucoup de personne le croient). UML modélise tout ou partie d'un système d'information, d'où une certaine confusion.

Mais attention, une analyse ne peut être faite uniquement avec des diagrammes (UML ou Merise) ou uniquement avec du texte.

Il faut les deux : un diagramme qui montre que l’on a bien compris le sujet (synthèse) et un texte pour décrire en détail son fonctionnement.
Pour ce qui est des exemples de CdCF en UML, effectivement il y en a peu.

Personnellement, je commence avec un ami agriculteur un projet (Osiris) pour faire une gestion d’une ferme d’élevage. Ce projet sera fait en UML et en Java.

Vous pourrez voir son évolution sur le site Gna. Peut-être que cela aidera notre ami Chess.

Ce projet a aussi pour vocation à montrer à mes camarades du CNAM que l’on ne peut pas tout faire avec UML ou Merise, mais qu’il est nécessaire d’avoir une méthode pour utiliser Merise ou UML.

Car ne l’oublions pas, Merise et Uml ne sont que des outils.