Du bon usage de l'abstraction (2 Les difficultés liées à UML)

Peut on définir le niveau d’abstraction d’un modèle ? Quels sont les écueils à éviter dans la modélisation UML ? Comment susciter l’adhésion d’une entreprise à une démarche basée sur UML ? Comment combler les lacunes d’UML ? L’initiative MDA versus l’approche par DSL. Tels sont quelques-uns des thèmes abordés.

Du bon usage de l’abstraction (2)

Les difficultés liées à UML

Quiconque a un jour dispensé une formation UML sait à quel point il est difficile de transmettre, à des esprits vierges de tout concept objet, les notions d’ "objet métier", de "cas d’utilisation" ou encore "d’activité". Pourquoi ? Tout simplement car ces concepts sont par essence ambigus. Tout du moins si on les compare à la rigueur axiomatique qui convient au fondement d’autres formalismes comme la géométrie ou à l’algèbre par exemple.

En effet, on ne peut véritablement définir ce qu’est un « objet métier ». En revanche, à force d’exemples et en écoutant les avis autorisés des experts, on pourra s’y habituer ! Et après une ou deux tentatives, le novice parviendra, lui aussi à placer « objet métier » à bon escient dans une conversation avec ses pairs ou dans les réunions en clientèle. Ensuite il devra s’attaquer à la notion de « service » plus difficile encore à cerner qu’ objet métier ! On voudra bien me pardonner un zeste d’ironie…

Pour autant, faut-il rejeter ces concepts ? Nullement ! Le flou conceptuel qui enrobe ces termes en garanti précisément leur utilité. Il en va d’ailleurs comme pour le langage naturel, lui aussi non axiomatisable. Les linguistes connaissent bien cette difficulté, qui s’y sont cassé les dents depuis des lustres en essayant, en vain, de construire des systèmes experts de traduction universels. Si ce problème d’axiomatisation était résolu il y a belle lurette que nous aurions la compagnie de machines qui pensent,  parlent, créent des algorithmes, de la poésie ou se mettent en grève.

Cependant, voilà que je m’égare… Revenons donc sur Terre et

4 Responses to “Du bon usage de l'abstraction (2 Les difficultés liées à UML)”


  1. 1 ropib 03/03/2008 à 17:34

    La difficulté de la modélisation d’une interface ne vient-elle pas justement du fait qu’il ne s’agisse pas vraiment d’une abstraction et que nous manipulions plus ou moins directement des instances, même généralisées ?

  2. 2 plem 04/03/2008 à 09:33

    Je suis assez d’accord avec ta remarque, ropib, les widgets d’une IHM sont, par nature, concrets et leur manipulation devrait être de nature ‘graphique’ ce que permettent d’ailleurs les bon IDE (Visual Editor pour Eclipse p.ex.). Devant la pléthore de technos pour les IHM web, je vois mal dans un avenir proche une standardisation s’opérer sur la définition d’UN langage un d’une notation IHM universel. Cependant, le besoin de modélisation demeure pour d’autres aspects de l’IHM comme la logique de navigation, les différents contrôles de surface à effectuer qu’ils soient syntaxiques ou de cohérence. Un formalisme simple à cet effet m’apparaît souhaitable et réalisable même en UML avec quelques stéréotypes bien pensés et des diagrammes de séquence. Je tâcherai de mettre en ligne une proposition dans ce sens dans les prochaines semaines.

  3. 3 jc-Qualitystreet 05/03/2008 à 11:09

    Le principe de l’utilisation du visuel pour communiquer est certes un principe prôné par UP (Unified Process, dont le RUP est une instantiation) mais vouloir tout modéliser avec UML me paraît dangereux… L’utilisation du visuel, et notamment des diagrammes UML doit toujours être pensée selon les projets, les contextes, les contraintes et surtout les destinataires. Produire de la doc si elle n’a aucune valeur ne sert à rien!
    C’est aussi l’esprit de la modélisation agile: juste ce qu’il faut, tant que cela reste simple, compréhensible, et que cela guide la mise en oeuvre. Scott Ambler (expert dUP de chee, et du RUP) évangélise maintenant depuis pas mal d’années la dessus ( http://www.agilemodeling.com/). Il faut modéliser mais à bon escient. Il me paraît important de rappeler aussi que dans le cadre du QUOI, d’une description des besoins fonctionnels par cas d’utilisation (on peut le faire autrement, par user stories par exemple), le diagramme des cas d’utilisation n’est qu’une toute petite partie du boulot (10%), utile je le reconnais, pour la vue d’ensemble et la vue sur les relations entre acteurs et cas qu’il procure. Mais un cas d’utilisation est avant tout textuel, et c’est même plutôt la démarche d’analyse, progressive, qui compte le plus (90 % du boulot). J’en parle ici: http://www.qualitystreet.fr/?2007/1… Dans cet esprit, je n’ai jamais eu de problèmes quand je présentais, sensibilisais ou formais à la démarche des cas d’utilisation. Sur la question du web, encore une fois, un choix doit être fait parmi l’éventail de diagrammes qu’UML met à disposition, et même dans ce cadre là toujours avec modération. Le livre de Pascal Roques, un expert du domaine, est sur ces questions très pertinent; je vous le recommande: http://www.eyrolles.com/Informatiqu… Pour ce qui est de l’ergonomie des interfaces et des enchaînements d’écrans, ma spécialité, UML propose des choses (Pascal Roques les décrit très bien). Elles ne sont selon moi pas des plus pertinentes, et je ne les utilise pas dans ma pratique quotidienne (contextes de développement d’applications informatiques,web ou autres).
    Enfin selon moi, UML n’est qu’un formalisme qui n’est pas indispensable à une démarche d’industrialisation.

  4. 4 plem 05/03/2008 à 22:06

    Pour "jc-Qualitystreet" : Je suis d’accord avec la remarque "tout modéliser avec UML me paraît dangereux…". C’est justement qu’UML possède des lacunes et ce en dépit de sa vocation initiale qui se voulait clairement universaliste. Il serait intéressant que tu exprimes quels sont selon toi les principaux dangers que tu vois. J’ai exprimé ce que j’en pense: l’absence de définition claire de niveaux d’abstraction qui est la principale source de confusion et de réticence. Il va sans dire qu’UML n’est pas un but en soi, et donc modéliser pour faire des jolis dessins est naturellement vide de sens, d’accord là dessus. Ta remarque sur le fait que définir les UC représente 20% du travail d’accord aussi. Pour moi c’est une première partition de l’espace des besoins et surtout l’identification des acteurs accompagnés obligatoirement d’une description textuelle (selon un canevas précis) et au besoin facultativement de diagrammes d’activités lorsqu’un aspect chronologique doit être décrit. En ce qui me concerne, chez PSA, les 80% restant du temps sont utilisé pour définir le modèle des objets métiers au niveau de l’analyse et pour identifier les principaux services. Je suis toutefois surpris que tu n’ai jamais rencontré de problèmes dans l’explication de ce qu’est par exemple un cas d’utilisation. C’est quand même un des concepts les plus fumeux inventés par l’informatique ! Même s’il a une certaine utilité. Des livres de centaines de pages on été consacré à ce sujet (des UC). Selon moi, non pas parce que ce concept est profond ou difficile mais simplement parce qu’il est (trop) vague. Enfin, pour ce qui est des références sur UML, le meilleur livre, tout à fait subjectivement, reste celui de Pierre-Alain Muller : Modélisation objet avec UML. C’est un livre écrit au début de la vague UML et une époque ou les auteurs prenaient le temps d’expliquer dans une langue d’une exemplaire clarté les concepts de bases. Par la richesse et la précisions du langage utilisé, certains lui reprocheront son caractère universitaire, selon moi c’est que qui fait son intérêt.


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s




Mises à jour Twitter

Erreur : Twitter ne répond pas. Veuillez patienter quelques minutes avant d'actualiser cette page.

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64 124 hits

%d blogueurs aiment cette page :