Discussion :

[zin_rbt]

J'aimerais savoir si les innovateurs du langage UML étaient des développeurs ou bien des analystes concepteurs.

Merci d'avance pour votre réponse

[Hephaistos007]

Leur expertise était clairement centrée sur l'analyse et la conception.

[Vlade]

Je pense qu'il faut plus claire sur ce sujet et bien distinguer les rôles.
La norme UML a été faite par des spécialistes métiers et non des développeurs. Les outils UML ont été fait par des spécialistes métiers connaissant UML et des développeurs. Les outils de générations de code à partir d'un modèle ont été fait par des développeurs.

Les innovations peuvent avoir eu lieu à chacune des étapes du logiciels, que ce soit en conception métiers on en implémentation. Il n'y pas de meilleurs idées chez les uns ou les autres, tous doivent travailler en équipe et c'est cela la meilleur idée

[Hephaistos007]

J'ai pensé que par "innovateurs", zin_rbt faisait référence aux pères fondateurs d'UML. C'est sur cette hypothèse que j'ai répondu en tout cas ...

[Vlade]

Hephaistos007,

Parlons un peu des pères de l'UML alors
Avant 1996 il existait les méthodes Rumbaugh dite OMT, celle de Grady Booch dite OOD et celle de Ivar Jacobson dite OOSE. Une vrai pagaille toute ces méthodes, mais n'oubliont pas aussi la méthode meurise qui est une création française qu'a remplacé l'UML

OMT+OOD+OOSE ont mergé ensemble pour faire UML qui a vraiment été standardisé par l'OMG et Rational en 1996.
Les normes UML ont beaucoup bougées passant d'une version 1.0 en 96 à une version 1.5 en 2005. Avec la version 1.5 je pense qu'on a vécu l'age d'or de l'UML.
Arrive ensuite la période des disputes que l'OMG a eu tous les problèmes du monde a unifié et l'UML 2.0.
A ce moment un mouvement de fond émerge sous l'influence de certains pour parler d'interchangeabilité de model au niveau de la structure UML. Omondo a été le premier en 2004 a poussé la promotion d'un métamodel unique et a adopté la structure UML de Rationale comme metamodel interne. A ce moment les outils Rational et Omondo ont eu les même internes. Ensuite ont suivi les autres tel Togethersoft et maintenant tout le monde fait de même avec l'utilisation du framework GMF.
Le constat était que la transformation de modèle entre outil était quasi impossible et seul l'utlisation d'un même metametamodel ( le MOF) permettrait une vrai interchangeabilité. Après de longue bataille ont est arrivé à UML 2.2 en Mai 2008 et à ce moment un truc bizarre. Nous avons plusieurs père génétique pour le même enfant
Ben oui, Ed Merks et son équipe EMF ont crée le EMOF qui a servit de base pour créer la Structure UML 2 dite le metamodel UML, tandis que d'autre ont défini ce que devait être la Structure et le mécanisme interne de la Structure UML. La Structure UML a été validé et vraiment développé par Kenn Hussey (d'ailleurs que tout le monde a oublié pourtant c'est lui qui l'a faite ce metamodel UML 2 qui est aujourd'hui UML 2.2 dans les labo d'IBM à Toronto).
Voilà les papas d'UML d'un côté l'innovation initiale a surtout été en terme de présentation graphique et signification des graphes avec les 3 amigos (Rumbaugh, Booch et Jacobson) ensuite l'innovation a été plus sur les couches basses du MOF avec Ed Merks et Kenn Hussey et l'équipe R&d Marcello, Lena et les autres en grande parti brésilien du lab de Toronto.
Il y a bien sûre des Français comme Jean Brézivin et son équipe et d'autre projet open sources de l'Inria. Mais à part le projet de Jean et ATL les autres n'apportent pas vraiment d'innovation technologique et sont des suiveurs du projet GMF.

[Hephaistos007]

Je ne vois pas très bien ce que vient faire EMF dans cette histoire, pas plus que Omondo, ni aucun autre modeleur UML. Ce ne sont que des choix d'implémentation. Idem pour la transfo de modèle, qui n'est aucunement lié à UML, ni à un langage particulier (ex : tu cites ATL).

[bruno_pages]

Bonjour,

l'arrivée de Microsoft dans l'OMG va sans nul doute avoir des conséquences, surtout que cela vient semble-t-il après le départ de l'OMG de la plupart des personnes qui sont à l'origine d'UML, et quand on sait que de plus les outils 'poids lourd' de la modélisation UML le font sur Eclipse/Java ...

[Vlade]

Hephaistos007,

L'innovation est passé du côté graphique aux couches basses. Je veux parler de l'utlisation d'un métamodel standard et identique à tous les outils. Ceci a été rendu possible par EMF et par la transformation de modèle avec le projet ATL.

[Vlade]

Bruno,

Avec UML 2 ca été assez dure comme négociation et le départ de certains est une bonne chose. Ces barbus modeleur qui voulait faire du MDA et apprendre aux developpeur comment coder cela devenait fatiguant

L'OMG a donc été à l'écoute de tous et même de Microsoft qui a d'ailleurs un très beau projet. A vrai dire l'OMG est toujours plus ou moins controller par les anciens de Rational et donc par IBM. Un contre poids ne ferait sans doute pas de mal

[Hephaistos007]

L'innovation est passé du côté graphique aux couches basses.

Que veux-tu dire par là ?

Je veux parler de l'utlisation d'un métamodel standard et identique à tous les outils. Ceci a été rendu possible par EMF et par la transformation de modèle avec le projet ATL.

méta-modèle ou méta-méta-modèle standard ? Si c'est de ce dernier cas, alors on parle de MOF. EMF a proposé une implémentation Java du coeur de l'API du MOF de l'OMG, nommé ECORE. Merci aux contributeurs de ce projet, mais ils ne sont pas à l'origine des concepts du MOF. Moi aussi je peux d'ailleurs proposer ma propre implémentation du MOF demain si je veux.

Quant à la transformation de modèle, on sait la faire depuis longtemps soit de manière "programmatique", soit à travers des feuilles XSLT. Par contre c'est vrai que les nouveaux langages de transformations ont un bien meilleur pouvoir expressif. ATL n'est qu'un (bon) exemple parmis d'autre.

[Vlade]

L'innovation est passé du côté graphique aux couches basses.

Je veux dire que l'UML est d'abord un formalisme graphique. Les normes UML ont toujours et surtout été orientées sur la représentation graphique, maintenant que la représentation graphique est figée on regarde le mécanisme de synchronization entre le graphisme et la structure uml.

Je veux parler de l'utlisation d'un métamodel standard et identique à tous les outils. Ceci a été rendu possible par EMF et par la transformation de modèle avec le projet ATL.

MOF sert à défnir le language UML mais Ecore sert à sérialiser la structure UML. Donc Ecore est appelé avec humour par Ed Merks comme EMOF En parlant de l'UML moderne on ne peut donc oublié EMF car tous les nouveaux outils UML sont bati dessu.

Transformation de modèle c'est nouveau par son approche même si cela existe depuis longtemps. Disont que ATL est une industrialisation de ce processe en s'appyant sur EMF. Mais tu as raison il bien d'autre transformation possible et pour Omondo la meilleur transformation de modèle est "No Transformation" du tout grâce à l'approche native

[TheLeadingEdge]

le départ de certains est une bonne chose. Ces barbus modeleur qui voulait faire du MDA et apprendre aux developpeur comment coder cela devenait fatiguant

Pourquoi ?
Quant à moi c'était le (seul ?) point positif que je voyais dans l'entrée de MS dans l'OMG. Du vrai ModelDriven rendu possible par l'apparition d'un UML (modèles) directement exécutable.

(...) il [Steve Cook] critique vertement UML pour son universalité et son incapacité à produire des modèles exécutables. (...)

[Vlade]

Il y a 2 tendances dans UML qui sont complémentaires.
OMT, OOD et UseCase respectivement de Rumbaugh, Booch et Jacobson ont donné UML qui est aujourd'hui l'UML officiel de l'OMG et Shlaer-Mellor a donné l'UML exécutable.
L'UML exécutable n'a pas eu de vrai investissement ces dernières années.

On a un forum de modeleur de collègues anglais et autres pays qui parle de toutes ces questions relative au MDD. Regardé si vous avez le temps et inscrivez-vous pour poster aussi: http://www.modeldrivensoftware.net/
Vous aurez des réponses précises et l'enregistrement est libre.

[zin_rbt]

Merci a vous tous et pour ce flux d'informations.
je suis novice dans ce fabuleux monde de conception en UML et vous voila me submerger d 'infos toutes quasiment nouvelles pour moi . Merci de me compliquer la vie d'avantage ..
en fait, la question que j ai posée est pour savoir ,dans une conception en UML - et je parle bien de conception et non du développement - ou commence le travail d un analyste,ou ça se termine et ou commence celui du développeur.
surtout que UML est destiné en premier lieu a la modélisation.

[zin_rbt]

J'ai pensé que par "innovateurs", zin_rbt faisait référence aux pères fondateurs d'UML. C'est sur cette hypothèse que j'ai répondu en tout cas ...

C est exact

[Vlade]

zin_rbt,

Le développeur a souvent un bac+4 voir plus, je vois pas pourquoi ce développeur doit se considérez comme un codeurs et non comme une personne ayant la capacité de réflechir ? L'UML permet de se poser des questions d'architecture, de besoin clients, du pourquoi de la solution etc....et un développeur se doit de donner vie à cette demande.

L'UML doit donc être utlisé aussi bien en conception que durant le projet car si les développeur ne sont que des automates qui ne savent que coder alors je trouve que c'est une vue bien limité et un réel gachi du potentiel créatif de chacun !!

L'origine de l'UML a été de séparé les métiers avec soit disant des modeleurs et de l'autre côte des développeurs. Avec l'agile cette séparation est fini, tout développeur est un architect car l'approche objet le permet même si cela est au niveau des couches basses, tout modeleur est une personne travaillant ou comprenant le code. Donc l'innovation UML est aujourd'hui chez les développeur et l'approche agile. et non plus chez les barbus adept de la méthode RUP

[zin_rbt]

dans ta première intervention,Vlade ,tu as parlé de distinction de rôles ,pourquoi ne pas donc maintenir cette distinction surtout dans un projet d'une grande envergure.je ne sous estime pas les développeurs ,loin de la ,mais je veux que chacun se focalise sur le volet qui le concerne dans un travail d'équipe.
certes,le developpeur fait parti du projet mais cela ne veut pas dire son implication dans tout le processus d'études et de la conception que normalement un analyste mène directement avec les clients -utilisateurs-du prochain système.
a mon modeste avis,le développeur a se soucier des contraintes techniques et logicielles ,l'analyste lui ,recense les besoins métiers,les analyse, les interprètent moyennant les outils fournis par UML < merise, ou autre ...> ,élabore ses modèles qu'il communique au développement dans un environnement J2EE ,et ce même travail peut etre implémenté dans un environnent ASP.net.puisque le concepteur travaille loin de toute préoccupation technique et évite aux développeurs les contacts et les meetings directs et très souvent ennuyeux et durs avec les utilisateurs .

[Vlade]

Je ne dis pas que le développeur doit rencontrer le client mais qu'il doit utiliser son cerveau à autre chose que juste être un exécutant produisant du code.
Il doit avoir des réunions avec les chefs de projets qui eux doivent rencontrer les clients.

Lors de réunion de travail la communication passe par l'échange et l'impact visuel est important. C'est l'UML de premier niveau. Ensuite il y a la phase d'itération avec le premier délivery de l'équipe de codage, la revu avec le chef de projet qui va la montrer au client.
Là les demandes évoluent, les clients se rendent comptent sur maquette que leur demande peut être affiné etc....
L'UML prend en charge cette 2ème étape en permettant de mettre à jour diagramme et code grâce à l'approche MDD.
De nouveau les chef de projets et l'équipe de codage se réunisse et on refait une itération pour montrer un délivrable de test. Idem afin de ne pas tout recommencer l'UML sert à regénéré le code qui peut être modifier de cette façon. Et on recommence
Au bout de plusieurs itération le projet s'améliore, le client est de plus en plus satisfait et la cohérence est gardé par la modélisation à condition d'avoir un merge incrémentale bien sûr

Maintenant chacun fait comme il veut mais il est dommage de ne pas donner la possibilité aux développeurs de prendre de la hauteur afin d'améliorer la qualité du code grâce à l'utilisation d'UML. Sans compter l'aide au refactoring du projet grâce à l'assistance du modèle UML. Le développement Java est comme une pyramide, si on modifie tout en haut alors cela impact tout en dessou, et l'UML avec l'architecture orienté objet est une aide, ou on le fait à la ligne de code en bas, et là ca prend un temps fou.

[bruno_pages]

Bonjour,

enfin un avis non politiquement correct sur UML

d'abord il est bien évident que l'on peut faire de très bonnes choses sans UML, surtout lorsqu'on à de vieilles habitudes ce qui est à priori votre cas ... et le mien puisque je suis encore plus vieux que vous (49). On peut évidemment aussi faire de très mauvaises choses avec UML, bref UML n'est ni magique ni maléfique

cela n'engage évidemment que moi, mais en ce qui me concerne les deux principaux atouts apportés par l'utilisation d'UML sont

• faciliter l'établissement d'une architecture d'ensemble plus propre (avec tout ce que cela sous entend) grace à une vision moins au 'raz des pâquerettes'
• avoir une documentation à jour par rapport au code, je suppose ici que les deux sont produits à partir du modèle

mon utilisation d'UML reste donc très 'pragmatique' et limité, et je pense que la complexité que certains essayent de mettre derrière, et en particulier un MDA échevelé et surtout inutile, n'a pas de sens et risque tout simplement de tuer UML.

Il en est de même de la complexité et de la lenteur d'utilisation de certains modeleurs et la difficulté de générer le code qu'on veut sans y passer la journée.

Si la méthodologie et/ou le modeleur utilisé rendent les délais de spécification/développement non raisonnables alors il vaut mieux passer à autre chose.

Bref une machine à café qui demande une demi journée pour faire un café ne m'intéresse pas du tout, il en est de même si la machine remplie la moitié de la cuisine et qu'elle me coute 10000 euros

[nicorama]

J'étais à fond pour UML au début, et très clairement je rejoins le club du gribouillit au papier crayon. Je suis chef d'entreprise, concepteur, et developpeur du logiciel, et après avoir utilisé un bon paquet de logiciel UML, il faut bien constater que ca fait souvent perdre du temps.

A quoi sert ce logiciel ? A générer la Bdd ? A générer le code ? A chaque fois les conséquences ont étés pire que l'intérêt à court terme.

Je ne suis pas anti-génération : Matisse génère mes composants Swings (avec parfois des gros soucis, mais ca vaux le coup) et Netbeans génère mes EJB3 à partir de ma Bdd faite à la main.

C'est bien d'apprendre UML, ca permet de faire plus rapidement des schémas plus clair. Mais le tableau blanc effacable est plus efficace qu'un logiciel. Car au final le code sera écrit, modifié, refactorisé, supprimé avant que le concepteur ait parcouru trois sous-menus.