| « N'oubliez pas de vous inscrire à la journée SysML du 27/11 ! | Artisan Software rachète Brass Bullet et renforce son offre en modélisation UML/SySML » |
Grady Booch on Design Patterns, OOP, and Coffee ...
Une interview à lire d'un des amigos : Grady Booch.
Quelques extraits qui m'ont interpellé sur UML rejoignant un sujet à la mode, la modélisation agile :
When Jim, Ivar, and I began our journey that became manifest in the UML, we never intended it to become a programming language. I think that there's a fairly narrow domain for which model-driven development makes sense but that we should return to the roots of the UML, which was to be a language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system—in short, a graphical language to help reason about the design of a system as it unfolds. Most diagrams should be thrown away, but there are a few that should be preserved, and in all, one should only use a graphical notation for those things that cannot easily be reasoned about in code. As I've also often said, the code is the truth, but it is not the whole truth, and there are things such as rationale, cross-cutting concerns, and patterns that cannot easily be recovered or seen from code.... These are the things for which a graphical notation adds value, and any such notation should be used only if it has predictive power or reasoning power (meaning, you can ask questions about it).
Adresse de trackback pour cet article
2 commentaires
L'UML s'est avant tout un language graphique et le MDD dans une démarche agile est peu recommendé.
En parlant de MDD je veux dire le "model driven development" dans lequel le model génère de façon programique un code qui est aussi appelé squelle de l'application. On doit dans ce code généré ensuite rajouter les cocuhes persistence et présentation et aussi rajouté à la main les règles métiers codé dans des méthodes afin de montrer un déployable au client. Par contre une fois qu'on a touché à la moain le code le MDD et le model est cassé sauf si on a une approche meta modeling incrémentale.
On arrive aujourd'hui à la conclusion que le MDD sert à rien et il a fallu attendre 7 ans et je donne rendez-vous dans 5 ans pour que tous finissent par admettre que seul la seule façon de modéliser en agile c'est le metamodeling et non pas les transformations de modèles qui sont comme des petits poux qu'on doit enlever des cheveux sinon on contamine les autres :-)
Je vis en Agnletterre depuis plusieurs années et dans mon Bac j'ai eu que 2 en Français. Toutefois les maths m'ont sauvé car c'était un Bac C. Mais bon c'est pas une raison même en étant émigré d'Europe de L'Est éduqué en France, et je faire essayer de faire moins de faute la prochaine fois.
Ce que voulais dire mon poste est que je crois pas au MDD et que la génération de code à partir du modèle pourri trop les projets pour être recommendé. L'UML est un beautifer du code en donnant des vues que l'on ne peut coder car les languages n'ont jamais prit ces besoins. En plus on peut rajouter une dimension fonctionnelle et modélisation à un projet java tout en restant dans un projet java sans faire de transformation ni même généré de code.
Je veux dire que la modélisation UML et Java doivent être ensemble dans le même projet pour ensuite faire des itérations entre les équipes de développement et les modeleurs sans jamais perdre le modèle, le code, les requirements tout le long de la vie du projet. Le MDD casse cette itération à cause de la transformation du modèle UML en code sans merger les Id du modèle avec les Id Java et ensuite sans merger les modifications du projet faite en couche basse avec les Identifiant du modèle. On a donc 4 modèles et non pas un seul. Je veux dire qu'on a un modèle graphique, un modèle UML, un modèle de transformation et enfin un modèle Java or en metamodeling on a un seul modèle pour tout faire. Un projet UML très complexe devient un jeu d'enfant en metamodeling.
Flux de commentaires pour cet article