Le blog d'UmlGuru

V2.1.1 avec la participation d'Alcatel et de France Télécom, très intéréssé par l'approche MDA

Bonjour Pascal,

Je constate que l'essentiel des diagrammes du metamodele a ete revu (avec un outil qui n'est plus Rose d'ailleurs,...), et que les niveaux de conformite (L1, L2,...) ont ete redefinis.

Outre ces changement qui ont l'air d'etre de la consolidation, y-a-t-il des modifications plus importantes (je n'ai pas vraiment eu le temps de faire une analyse approfondie,...) ?

Est-ce reellement le MDA qui motive cette evolution ?
D'autre part, qu'est devenue l'idee de certifier les outils pour leur implementation d'UML ? Je n'en ai pas encore trouve qui respecte totalement la norme.

Enfin, est-ce que tu penses que l'on aura un jour un action language propose largement par les editeurs d'outils avec le support d'un editeur moderne (syntaxe, completion,...) ?

Eric.

Il s'agit effectivement de consolidation, entamée avec la récente version 2.1.
Un détail par exemple : le message de création dans le diagramme de séquence est en pointillés avec une flèche ouverte (comme le return ?!). Je n'ai pas encore regardé en détail le reste, mais vu qu'on est juste passé de 2.1 à 2.1.1, ça ne doit pas valoir le coup !
La 2.1 apportait des nouveautés au niveau de la définition des profils (opérations dans les stéréotypes, etc.), mais tu as raison, aucun outil ne respecte vraiment la norme ...
Pour le langage d'action qui existait dans la 1.5, il a été remplacé par une définition de plus de 50 types d'acions dans le méta-modèle 2.0, donc la réponse me semble être non !

Pascal

Honnêtement, si le RAD n'a plus grand chose à prouver, je suis sceptique lorsqu'on me parle de MDA et de génération de code. UML est un formidable langage de communication. Mais en grandissant et en grossissant de plus en plus, il risque de se renfermer sur lui même. De mon point de vue, UML constitue le meilleur moyen de communiquer actuellement. S'il peut générer en plus du code pour ne pas avoir à retaper ce qu'on a modélisé, tant mieux. Mais pour le reste... c'est une légende urbaine entretenue pas une horde de commerciaus de SSII diverses et de consultants en quête de reconnaissance.

je vois qu'un débat s'amorce, intéressant.

Come le précédent intervenant j'éprouve un sentiment de mal être vis à vis des approches MDA. Mais pas un mal être pessimiste, mais plutôt le sentiment que quelque chose ne va pas.

Les faits sont simples: les outils de modélisation sont complexes à maîtriser.
D'un autre côté en tant que développeur on nous demande de faire des développements de plus en plus sophistiqués en de moins en moins de temps. Il est donc clair qu'il faudra bien en sortir un jour de l'approche artisanale actuelle.

Artisanale parce que, pattern ou non, une fois le code écrit on en perd la maîtrise. Nous savons tous que reprendre un code, fut t'il écrit très bien, est difficile, pour pas dire plus. Même du code que l'on a écrit soi même peut être un challenge.

Les éditeurs promettent à chaque version de leur outil des gains de performance fabuleux, mais des gains de perfomance sur des choses où la question ne se pose de toute façon pas. On passe plus de temps à relire du code, qu'à en écrire du nouveau. Résultat pour maîtriser une appli que l'on n'a pas écrit il faut toujours des semaines si ce n'est des mois et cela n'a jamais changé depuis des années. Si ce n'est que l'on n'a jamais des semaines ou des mois devant soi ce qui ne contribue pas vraiment à la qualité de la maintenance.

Je pense que les raisons sont simples: tant que le code est le seul outil disponible pour analyser une appli on ne sortira pas de ce problème.

On n'a besoin d'une approche différente pour appréhender le code, mais aussi ce qui va autour comme sa doc ou ses présuposés techniques.

Autre problème, on invente de beaux pattern, on créé de beaux framework. Mais comment contraindre des développeurs à utiliser ces patterns, que souvent ils ne connaissent pas, comment les contraindre à se servir du framework plutôt que de code "maison". Rien que le bon vieux modèle 3 tiers est déjà totalement inconnu de pas mal de développeurs.

Est-ce que les outils n'auraient pas justement un rôle à jouer la dedans?

C'est tout cela que je demande aux nouveaux outils de MDA.
Mais que je ne vois pas les choses venir tant que ça. D'où ma désillusion, sans compter le risque d'une balkanisation des outils et des approches si d'une certaine façon ces outils ne se normalisent pas.

UML ou autre chose? Je ne sais pas. Est-ce le débat d'ailleur.

Voila ma petite contribution

Je profite de la réponse prérédente pour rebondir et préciser ce que j'ai écrit plus haut :

1) oui, il faut modéliser. La modélisation est essentielle. Mais il ne faut pas modéliser pour modéliser. Il est nécessaire de confronter ses modèles à d'autres personnes pour les adapter et les corriger et faire adhérer les intéressés. C'est en cela qu'UML est puisant.

2) Oui, le développement ne se simplifie pas. Plus l'état de l'art avance, plus les fonctionnels sont gourmands et plus les "modèles" à coder sont complexes. Les applications sont de moins en moins linéaires et de plus en plus transversales. Bref, j'ai tout de même de bons exemple prouvant qu'en changeant de mode de programmation, on peut gagner pas mal de temps. C'est le cas des produits webMethods. Le passage de l'environnement de développement de la gamme Enterprise à la gamme Integration Server a permis de gagner 50% sur les temps de réalisation. Un autre bon exemple est le plugin Matisse de NetBeans pour la réalisation d'interfaces graphiques en Swing. Ce que je veux dire par là est que je ne suis pas encore convaincu qu'UML soit la bonne solution pour aller vers ceci. UML est performant dans la modélisation. Ensuite, il doit fournir des passerelles vers des outils spécialisés. Et là, on attaque le format XMI...

C'est un débat qui dure déjà depuis pas mal d'années ...

Craig Larman, par exemple, est farouchement opposé à l'idée d'utiliser UML pour coder (MDA), mais partisan d'une modélisation "agile" : UML en mode esquisse.

Je vous conseille de regarder les présentations qu'il a faites sur le sujet aux Valtech Days, disponibles gratuitement sur www.valtech-tv.com. Ca vaut le détour !

Pascal

"UML en mode esquisse" est-elle une technique (ou la façon de la manier) suffisamment agile? UML pour la modélisation ou "Agile Draw"?

Agile Draw est une initiative qui consiste en un ensemble de principes et de styles de dessin, restreint à un minimum d'éléments, pour créer des modèles simples et efficaces.

Le couplage des deux formalismes est-il intéressant? D'une part nous cumulons deux formalismes différents; d'autre part, nous bénéficions d'un langage très simple, fortement épuré et facile à utiliser et à comprendre pour les différentes parties impliquées. Et c'est le but:
"Your goal is to build a shared understanding, it isn’t to write detailed documentation" (S. Ambler)

Sur le site de l'agile draw préconise l'utilisation de l'agile draw pour les activités conceptuelles et UML pour les descriptions techniques.
Qu'en pensez-vous?

Source : www.agiledraw.org

Je ne vous étonnerai sans doute pas si je réponds que je ne suis pas d'accord !
J'utilise depuis de nombreuses années UML pour des activités conceptuelles sur projet, et j'essaie d'enseigner comment on peut utiliser UML pour l'analyse, voire la modélisation métier ...

Il est clair qu'il est facile de perdre un lecteur non averti en utilisant toute la puissance d'UML, et qu'il faut se forcer si l'on souhaite rester à un niveau conceptuel. Mais c'est cela être agile !!

Donc pourquoi pas Agile Draw, mais pour ma part je vais continuer à utiliser UML, en m'efforçant d'être au bon niveau d'abstraction, avec le bon point de vue, en fonction de mes objectifs et de mon auditoire.

En tout cas, merci pour le lien, je ne connaissais pas cette initiative. :)

Une bonne connaissance des concepts tels que les Use Case, ainsi qu'une vulgarisation en language 'commun' de ces concepts (comme l'on retrouve dans votre livre "UML par la pratique") peut faciliter la compréhension.

Donc, on ne parle plus ici d'outils (de dessin) mais bien de qualités humaines. Effectivement c'est être Agile : Individuals and interactions over processes and tools.