Discussion :

[Vlade]

Nicorama,

Je dois bien l'avouer que tu as raison
On a fait de grosses erreurs en UML et bien plus que d'apporter des solutions on a souvent compliqué la vie des développeurs. En créant Omondo en 2001 j'ai crû y arriver mais force a été de conctater qu'en 2005 EclipseUML a plus été destructeur de projet que aggrégateur de valeur.
Depuis cette date je me demande pourquoi nous avons raté l'utilisation de Java et de l'UML. Sans arrêt depuis 4 ans je me demande la même question et cela nous a amené à notre nouvelle soultion EclipseUML 2008. Et bientôt EclipseUML 2009.

Il faut bien distinguer ce qu'on veut faire avec UML. Soit un UML facile et puissant orienté design avant tout et là des outils comme Boum sont parfait, soit un UML qui va plus loin et là EclipseUML 2008 pourrait être la solution.
Je ne sais pas si on a enfin trouver la solution, car nous n'auront les retours qu'en 2010 sur les projets déployers mais une chose est certaines c'est qu'on sait qu'on s'est trompé et qu'on a changer. Tout le monde sans doute connait l'histoire douloureuse d'Omondo, mais la quête du "Saint Grâle" de l'UML est le prix à payer aujourd'hui.

[Hephaistos007]

Trois ans d'inscription pour écrire ce message

C'est ce qu'on appelle une intervention mûrement réfléchie.

[Floréal]

A mon humble avis, parce qu'il ne faut pas prendre UML comme une méthode mais comme un langage. Merise par exemple est une méthode, on part de très haut dans des concepts abstraits et on trouve en suite des solutions techniques pour concrétiser les sus-cités concepts.
Alors qu'avec UML on parle immédiatement de classe, d'Objet, de méthodes, et on n'a pas cette abstraction de départ que l'on a avec Merise (ou tout autre méthode!).

Attention je ne critique pas UML, et au contraire je passe mon temps à m'en servir... mais seulement après avoir bien réfléchi à la problématique que je souhaite traiter.
Pour moi L'UML me sert juste à inventorier mes classes (Diagramme de classe), les interactions qu'elles peuvent avoir entre elles (Diagramme de séquence), et les interactions entre le système que je veux concevoir et son environnement (Use case).

Pour ma part je trouve UML déjà très bien, et qu'il rempli bien le rôle que je lui attribut.

[bruno_pages]

Alors qu'avec UML on parle immédiatement de classe, d'Objet, de méthodes, et on n'a pas cette abstraction de départ que l'on a avec Merise (ou tout autre méthode!).

toi peut être, mais UML n'incite vraiment pas à cela, ta vision des choses est vraiment incroyablement réductrice

[Hephaistos007]

Merise par exemple est une méthode, on part de très haut dans des concepts abstraits et on trouve en suite des solutions techniques pour concrétiser les sus-cités concepts.
Alors qu'avec UML on parle immédiatement de classe, d'Objet, de méthodes, et on n'a pas cette abstraction de départ que l'on a avec Merise (ou tout autre méthode!).

Pas compris. Qu'est-ce qu'un concept abstrait dans Merise ?

[Floréal]

Je vais essayer de vous répondre à tous les deux:
Avec UML, j'ai vraiment l'impression d'être d'emblée très proche de quelque chose de logique, structurel, et tangible. J'ai la sensation de devoir prendre pas mal de recul, et d'envisager mon développement sans penser aux contraintes techniques dans un premier temps (ce que je voulais illustrer par "concept abstrait"), le MCD et le MCT en somme. "Qu'est-ce que je veux faire?", ce n'est qu'après avoir répondu à cette question que que je me lance dans dans une approche plus logique ("Comment puis-je y parvenir?"), c'est à ce moment là que j'entame mes ébauches de Use Case, que je définis mes premiers packages.

[Hephaistos007]

Tu prend l'exemple du MCD qui est effectivement un bon exemple, car indépendant de toutes contraintes techniques. Mais on ne s'arrête pas là : je te rappelle que le MCD est ensuite raffiné en MLD puis raffiné en MPD. Chaque raffinement diminue le niveau d'abstraction et se rapproche des détails techniques. La technique de raffinement est explicitement dictée par Merise, ainsi qualifiée de méthode.

UML permet de faire des choses équivalentes au combo MCD/MLD/MPD, à travers trois diagramme de classes différents, sauf que la technique de raffinement n'est pas explicitée. Pourtant, on a :
MCD <==> un diagramme de classe focalisant sur les classes et leurs associations (majoritaire dans l'enseignement UML).
MLD <==> en fonction des multiplicités, on introduit des classes "structure de données" au diagramme (appris dans certaines universités)
MPD <==> en fonction de la technologie cible, on renomme les éléments du diagramme pour suivre les éventuelles conventions de nommage, et on affecte les véritables types/classes offert l'API cible.

La génération automatique de "code informatique", comme par exemple d'un MCD Merise à des instructions de création de table sous PostGresSQL, ou encore d'un diagramme de classe UML (niveau MCD) vers du code Java, ne sont que des cas particulier de raffinement d'un seul trait, qui masquent volontairement les différents niveaux intermédiaires.

[Shaidak]

Pour l'instant, ayant essayé à plusieurs reprises l'UML (toujours en étant convaincu que ça allait m'être utile) ... mais malheuresement, la même conclusion revenait à chaque fois : aucun intérêt pour moi et toujours plus productif sur ma feuille de papier avec mes crayons et mes feutres ...
Alors je ne sais pas, peut-être que c'est dû à une mauvaise utilisation, mais pour le moment, ni au travail ni personnellement je n'en fait usage.

[Hephaistos007]

mais malheuresement, la même conclusion revenait à chaque fois : aucun intérêt pour moi et toujours plus productif sur ma feuille de papier avec mes crayons et mes feutres ...

C'est fort possible. Mais qu'est ce que vous faites sur votre feuille de papier avec vos crayons ? que représentez vous précisément ?

[Floréal]

UML permet de faire des choses équivalentes au combo MCD/MLD/MPD, à travers trois diagramme de classes différents, sauf que la technique de raffinement n'est pas explicitée. Pourtant, on a :
MCD <==> un diagramme de classe focalisant sur les classes et leurs associations (majoritaire dans l'enseignement UML).
MLD <==> en fonction des multiplicités, on introduit des classes "structure de données" au diagramme (appris dans certaines universités)
MPD <==> en fonction de la technologie cible, on renomme les éléments du diagramme pour suivre les éventuelles conventions de nommage, et on affecte les véritables types/classes offert l'API cible.

Et c'est en effet ce qui me pousse à dire que Merise (ayant son propre langage de modélisation) est une Méthode et UML est un langage de modélisation.

[bruno_pages]

... UML est un langage de modélisation.

mais personne n'a dit le contraire !
et il n'est pas dit non plus qu'UML doit s'utiliser sans méthode associée, ce qui est également vrai lorsqu'on utilise un tableau quoi qu'on y dessine

[Floréal]

Il me semblait qu'il y avait un amalgame au début du débat. J'ai peut être mal interprété ce qui était écrit. Bref je devais pas bien être réveillé, va falloir que je me mette au café.

[bruno_pages]

Il me semblait qu'il y avait un amalgame au début du débat. J'ai peut être mal interprété ce qui était écrit. Bref je devais pas bien être réveillé, va falloir que je me mette au café.

sans trop de sucre, sinon cela va être un autre type d'amalgame

plus sérieusement, messieurs les adeptes du tableau, deux questions (pas) anodines :

• lorsque par exemple vous élaborez vos classes et commencer à les dessiner, comment vous faites pour les décaler afin d'avoir quelque chose de lisible, ou comment les réduire parce qu'il n'y a plus de place pour en ajouter une ?
• une fois que vous avez fini, vous faite une photo pour garder la chose, ou vous changer de tableau et vous les gardez tous dans la cave, ou vous écrivez 'merci de ne pas effacer' (et on sait tous ce qui s'en suit ... ou s'essuie) ?

[nicorama]

sans trop de sucre, sinon cela va être un autre type d'amalgame

plus sérieusement, messieurs les adeptes du tableau, deux questions (pas) anodines :

• comment vous faites pour les décaler afin d'avoir quelque chose de lisible ?
• vous faite une photo pour garder la chose ?

• Je ne met jamais plus de 10 classes dans mon schéma. En général 5-6.
• Je code avec le tableau à coté, puis j'efface. Si c'est assez important pour être conservé, j'utilise un logiciel après avoir confronté le modèle avec la réalisation du code.

Globalement, passer des heures sur la modélisation puis coder me fait perdre trop de temps. Logique, je suis une équipe réduit à moi-même

Mais lorsque j'ai travaillé en équipe, les deux concepteurs (qui savaient aussi coder) faisait des gribouillis, passaient au tableau puis faisait du bel UML, générait la bdd, puis supervisaient les codeurs.

Je pense qu'on peut gagner du temps en générant assez rapidement une base de donnée imparfaite. Puis on passe aux programmeurs les résultats du tableau mis sur une feuille, on supervise, on revient au tableau, etc. Un joyeux bordel Faut pas être trop nombreux, et avoir les mêmes locaux.

[Shaidak]

que représentez vous précisément ?

En fait, pour faire court, je pense que je pars d'une base uml (pour mes projets personnels, au travail je pars directement du cahier des charges), mais qui deviens rapidement un mix entre uml, algorithme et cahier des charges .
Pour être honnête, je pense que l'uml est utile sur de gros projets, mais quil implique également une rande rigueur et beaucoup de temps ... chose que malheuresement nous n'avons pas forcémet en tant que développeur ... enfin, je parle pour moi. Ainsi, le choix est souvent vite fait (je sais, ce que je vais dire, c'est le mal absolu ) : on préfèrera faire des erreurs de conception pour avoir un produit qui marchouille et corriger par la suite plutôt qu'un produit finit et qui fonctionne mais qui n'aura pas été livré dans les délais

Si cela ne tenait qu'à moi, je ferais autrement, mais je ne suis ni le client, ni le le patron, alors je fais ce qui arrange tout le monde .

PS : Bien qu'en entreprise j'ai mis de côtés assez souvent mes principes du "je code proprement" ou autres, je les applique pour mes projets personnels puisque je n'ai de comptes à rendre à personne ...

[Alec6]

Ah ! La passion d'UML

Est ce que quelqu'un dans la salle est chargé de la capture fonctionnelle et de l'analyse métier ? Ca serait interessant d'avoir un retour d'expérience.

Savez vous que UML commence à etre utilisé par d'autres acteurs que les informaticiens, c'est à dire par les clients.

On en trouve dans
- l'architecture d'entreprise pour d'écrire qui fait quoi ou quand comment...
- en assurance qualité pour décrire des process et HACCP
- un peu en compta
- on y vient en bio
- etc...

Faire du diagramme c'est vieux comme le monde.

Ce qui est magnifique c'est quand le client parle le UML (et il a vite fait d'en comprendre les bases: diagramme de classe voir d'objets, use case, et d'activité). Pour les states ca va si on a affaire à des techniques.

Dans ce cas lui il parle et nous on dessine. Et ce petit dessin lui il est formel, comme une équation mathématique (exemple: Ton salaire=Brut*0.77 c'est bien claire . C'est la mise en place du diagramme d'Analyse métier qui est géniale. Après le cycle logiciel se déroule facilement, sans paradoxe, et sans surprise.

La deuxième étape est celle de la conception (architecture du logiciel). J'utilise ca aussi pour la communication en équipe. En restant grossier, c'est juste histoire et produire des spécifications.

L'UML au niveau développement j'ai jamais vu. Dans les grands compte sans doute, pour des projets ultra documentés.

Il ne faut donc pas oublié que UML c'est un langage inter humain de communication. Et comme il est formel il peut etre transcrit pour code.

La réussite d'un projet informatique c'est surtout la maitrise de deux facteurs:
- la communication
- la complexité (diviser pour mieux reigner)

UML améliore la communication quand il est bien utilisé.

[zin_rbt]

Salut à tous,

UML par définition est un langage donc fournit des outils et des moyens pour modéliser, et c'est à nous de mettre en place une méthode - régie par la nature du projet, contrainte du temps, des études préalablement faites, ressources disponibles – et si ça marche pas ,il faut revoir votre méthode au lieu de reprocher le langage .

Je pense que c’est un continuel débat entre concepteurs et développeurs, et à mon modeste avis – trouver un compromis ne serait pas une tache simple. Les concepteurs veulent stabiliser leurs modèles le mieux possible avant de passer au développement, puisque tout développement en dépendra et modifier le modèle par la suite, peut terriblement impacter le code chose qui ne sera pas tellement appréciée par les développeurs et ‘Shaidak ‘ dans sa dernière intervention a bien exprimé l’avis des développateurs.

Un projet c est tout d’abord une gestion, entre autre, une gestion de la contrainte du temps et des ressources .stabiliser le modèle le mieux possible , ne veut pas dire attendre que la conception soit achevé pour commencer les développement, mais veut dire, préparer un travail pour le développement après avoir stabilisé son modèle et continuer le reste. Un modèle stable n’est jamais la fin du travail d’un concepteur

[ypicot]

Une erreur que je rencontre souvent, c'est le mélange UML (langage) avec UML (l'outil, que ce soit Together, Rose ou n'importe quoi d'autre).

L'utilisateur se pose davantage de question sur "comment mettre la bonne flèche" que sur "pourquoi relier ces deux classes". Il est ainsi prisonnier d'un outil qu'il maitrise mal, et donc il est dominé par l'outil.

En fait (mais c'est peut-être mon coté formateur de développeur, donc au contact avec des personnes qui ont peu/pas d'expérience en modélisation), je proposerai une approche en 3 temps.

1) Apprendre à modéliser, à s'abstraire du code, penser en terme de service rendu par l'appli plutôt que
L'outil : le papier et le crayon, avec un formalisme plus ou moins inspiré par UML ou un de ces ancètres. On est dans l'approche de cf1020, qui envoie paître le UML pur beurre.

2) Faire des petits dessins ou des analyses dans son coin, c'est bien, mais dès qu'il faut communiquer (ou reprendre ses notes, sachant que dans l'intervalle on a pu changer sa manière de dessiner), ça pose pb. Et c'est là où UML arrive sur son blanc destrier, proposant un langage *commun*.
on continue cependant avec le papier et le crayon.

3) Le papier et le crayon font des dessins "pas propre" (mais très rapides), et qu'on a du mal à les envoyer par mail.
C'est à ce moment-là *et pas avant* qu'on peut commencer à utiliser un logiciel, quel qu'il soit.

Bien souvent, passer directement à l'étape 3 conduit directement à la catastrophe. Un peu comme un enfant qui voudrait courir alors qu'il ne sait pas encore marcher à quatre pattes.

Bien sûr, il existe toujours des gens très intelligents qui comprennent la différence entre composition et agrégation rien qu'en utilisant Papyrus, mais ils ne constituent pas la majorité de l'espèce.

Yvan
qui utilise encore le papier et le crayon (ou plus exactement la fiche A5 cartonnée)

[Hephaistos007]

Relié au point 3), il y a également le fait qu'il faut rendre numérique la modélisation pour pouvoir l'exploiter informatiquement (e.g, vérifications et génération de code). Ce serait dommage d'avoir une modélisation complète d'un système sans pouvoir en retirer le moindre bénéfice lors de son développement non ?

[Vlade]

Avec les nouvelles méthodologies agiles l'UML a complétement changé ces dernières années. Les allez retours permanent entre les donneurs d'ordre et les équipes impose une redefinition de la façond'utiliser l'UML dans un projet.

L'approche UML traditionnel est ce qu'on appel une approche top down. Une définition en amont suivi d'une génération de code en fin du cycle de modélisation. Le problème est qu'aujourd'hui souvent les idées viennent petit à petit et ne sont pas encore claire au début du projet. Donc la phase d'itération devient un incontournable et l'UML doit le prendre en charge.
Un UML agile doit donc permettre de faire des itérations entre les équipes de développement et les donneurs d'ordre tout en gardant les valeurs qui ont fait l'UML.