[HS] Uml, conception et implémentation (était : tail recursivity

Post by bruno modulix
NB : xpost et fu2 fr.comp.objet. On devient vraiment HS ici...
NB2 : Tout ce que j'énonce dans ce post ne saurait être qu'un avis
personnel, et comme seuls les imbéciles ne changent pas d'avis, je me
réserve le droit de me contredire à l'avenir. Vous voilà prévenus !-)

:-) de mon côté je suis globalement d'accord avec toi, nous n'utilisons
peut être pas exactement le même vocabulaire mais le fond est
sensiblement égal, donc je ne cherche pas à chipoter juste à préciser là
où mon point de vue (et cela n'est qu'un point de vue) diverge
légèrement. enfin, je tiens à préciser que je ne suis pas un fan d'uml
(sauf pour faire des croquis sur un tableau blanc et phosphorer).

Post by bruno modulix
UML et les langages de programmation ont tout de même bien de plus de
point communs, que ce soit dans le formalisme ou dans les finalités,
qu'un langage informatique (quelqu'il soit : programmation, requete,
description, conception etc) et un langage 'naturel'.

nous sommes d'accord

je suis toujours d'accord, bien que je remplacerait conception par
spécification somme tu le faisais au début de ce paragraphe.

La frontière entre les deux est ténue. Très ténue.

tout à fait et cette frontière doit varier d'un point de vue à un autre
(ce qui ne me pose pas de problème)

Post by bruno modulix
Mais je n'oppose pas les deux... Certains modèles "de conception" n'ont
guère de sens quand le langage fournit déjà le support nécessaire. Relis
attentivement le pattern Visiteur dans le GoF, les auteurs précisent en
toutes lettres que ce pattern n'a aucun sens en CLOS qui fournit
nativement le multidispatch. De même, si on prend la description du
pattern Etat, on voit que ce pattern n'a pas lieu d'être en Python où
l'on peut très simplement changer la classe d'un objet à l'exécution.
Encore un: les décorateurs de fonction Python : idiome ou pattern ? Et
les itérateurs ?
En fait, une grande partie des modèles présentés dans le GoF ont pour
finalité d'introduire un peu de dynamisme dans des langages statiques,
et ce n'est certainement pas un hasard si la plupart sont illustrés par
des exemples en C++, et seulement quelques uns en Smalltalk.

je ne pense qu'il soit uniquement question d'introduire du dynamisme
(mais je suis plus familier des patrons structurels en général). il est
aussi question (et j'ai l'impression qu'il est surtout question) de
capitaliser. les exemples en c++ et autes ne sont que des exemples,
alors que les patrons me semblent surtout important pour réfléchir et
surtout échanger avec les autres.

quelque soit l'implementation, lorsque tu dis patron état je vois tout
de suite de quoi tu parles alors que je pourrais être un développeur c++
et toi un développeur python. je te suis aussi sur la remarque sur CLOS,
toutefois ici encore lorsque tu dis visiteur je sais de quoi tu parles
même si les implementations peuvent varier (voire s'écarter du patron):
tu me cites un principe. la version langage de programmatin ne devient
alors qu'une traduction dans un auter formalisme (qu'uml).

idiomes et patrons de conception sont deux choses distincts à
deux niveaux différents.

Pas tant que ça... Quoi qu'en pensent certains, il n'y a pas de

mince je dois être en partie dans les certains ;-)

Post by bruno modulix
frontière claire entre conception et implémentation, et l'idée même
qu'une conception puisse être *totalement* indépendante du langage
d'implémentation me semble parfaitement surréaliste. <AMHA>Au mieux, on
aura une conception suffisament générique pour pouvoir être implémentée
avec plus ou moins de bonheur dans un nombre fini de langages</AMHA>.

je suis d'accord avec ton totalement (surtout mis en valeur). toutefois,
la conception est une étape d'un processus de développement qui peut se
faire en plusieurs itérations (et je garde des frontières floues pour ne
pas suggérer que l'on peut mettre des boîtes partout) et donc la
conception pourra être dans un premier temps relativement abstraite
(donc le plus indépendante possible de la technologie sous jacente) puis
se concrétiser de plus en plus en intégrant des détails relatifs à la
technologie cible.

ce que je trouve important ici, c'est de souligner que l'objectif est un
utilisateur dans un domaine d'activité. et globalement c'est la priorité
de prendre en compte les besoins et contraintes de cet utilisateurs
avant les "contraintes" de la technologie de mise en oeuvre. et c'est
pourquoi les première réflexions relatives à la conceptions devraient
être le plus indépendant de la technologie que possible. (je vais
revenir sur ce point par la suite dans Case vs MDA)

et UML n'est pas fait pour exprimer des
idiomes,

je suis d'accord avec ta remarque. mais est ce un résultat ou une
motivation? oui certains idiomes correspondent aux patterns et
réciproquement, mais il me semble dommage de considérer que
l'utilisation d'uml devrait être limité à ça. lorsque tu dis itérateur,
ici encore je vois de quoi tu parles, même si je ne connaissait pas python.

c'est pour cela que la
comparaison UML / langage de programmation me surprend.

Personnellemnt, je la trouve évidente. Ce sont (ou ce devraient être)

si on avait exactement le même point de vue ce ne serait pas intéressant :-)

Post by bruno modulix
des niveaux d'abstraction successifs, et c'est toute l'histoire de

là par contre on est tout à fait d'accord. et comme je vois une
complémentarité je ne comprend pas la comparaison (dans le sens
comparaison à un même niveau).

Post by bruno modulix
l'informatique. Le problème étant ici que (toujours AMHA), UML est trop
empêtré dans un modèle spécifique à un petit sous-ensemble de l'OO pour
permettre d'exprimer certains modèles, et évacue le problème en
considérant ces modèles comme des idiomes...

UML est à la fois trop empêtré et en même temps il veulent trop tout
faire (/tout pouvoir faire) avec. la nouvelle norme est abominable
(encore plus que la précédente).

Je crains que tout cela ne relève plus du fantasme marketing que de la
réalité effective... Quand on voit le fiasco qu'on été les CASE tools...

je ne suis pas non plus un évangéliste de la MDA, et je ne pense pas que
ce soit une révolution. mais je travaille pile poil dedans, dons nos
points de vue doivent êtr eun peu différent. mon humble point de vue:

MDE ne va pas résoudre tout les problème en réduisant le génie logiciel
à donner un modèle UML, cliquer sur un bouton et avoir le nouveau
système d'information de la sncf.

MDE devrait aider à apporter des solutions à des problèmes récurrents et
permettre de passer plus de temps à comprendre les besoins des
utilisateurs plutôt qu'à toujours refaire la même chose.

Les Case tools ont échoué (en partie au moins) car ils se vantaient de
fournir la réponse à tous les problèmes, ce qui est et restera
impossible. Par contre la MDE propose une approche différente: fournir
des solutions dans le cadre d'un domaine bien identifié (et non pas pour
tous les domaines). Par exemple dans le domaine de la santé, la gestion
d'un service hospitalier a toujours des grands principes similaires. par
contre les besoins de chirurgie ne sont pas les même qu'en radiologie.
il est donc intéressant de pourvoir, en tant que fournisseur de systèmes
d'informations pour services hospitaliers, de pouvoir capitaliser une
part de mon activité de développement de ces systèmes.

Il faut (AMHA) que les outils et moyens de productions soit spécifiques
au domaine d'application. je ne suis plus au niveau langage, mais
lorsque je fais un système pour la sncf j'ai envie de manipuler les
concepts de train, de réservation, de voyageur ; lorsque je fais un
système pour france telecom de manipuler les concepts de pabx, de
routeur, de backbone ; et lorsque je fais un système pour un chu de
manipuler les concepts de patient, de service, etc. et cela au niveau de
la modélisation.

Ensuite je passe à des modèles de mise en oeuvre (notre utilisation de
ce terme diverge je suis désolé), puis des modèles de mise en oeuvre
pour une technologie particulière, et enfin du code. C'est (AMHA) ce que
peux apporter les approches de types MDE. Dans le contexte (technique je
te l'accorde) des applications de type 3-niveaux (Présentation / Métier
/ Données) nous avons des protos qui montre que l'on peut générer dans
certains cas jusqu'à plus de 90% d'une application uniquement à partir
d'un modèle de ce que l'on souhaite. et c'est après avoir fait le modèle
que je choisi d'avoir une couche de présentation web ou client lourd,
utiliser tel ou tel langage et MySQL ou Postgres. [ici je te rejoints
lorsque tu mentionnais 'pour un nombre fini de langages' je rajouterai
ou technologies]

pour finir, je suis d'accord avec toi sur l'aspect pipeau marketing de
ce type d'approche en ce moment. les évangéliste de l'omg sont comme les
politique (ils n'ont pas de problèmes, que des solutions) mais lorsque
l'on travail sur les normes (qui ne vont pas tout résoudre loin de là)
nous sommes globalement d'accord pour dire que c'est un chantier de 10
ans et que nous commencerons à tirer réellement des bénéfices de ces
travaux vers 2010.

Post by bruno modulix
Pour moi, la mise en oeuvre, c'est un programme en cours d'exécution.
Tout le reste relève de la spécification - à un niveau d'abstraction ou
à un autre. Même le code binaire n'est qu'une spécification, que l'on
fournit au processeur, lequel exécute (réalise) cette spécification...

je suis d'accord avec toi

Post by bruno modulix
Le mien est: uml permet (éventuellement...) de faire un crobard, Python
permet de faire les plans, et le processeur réalise le tout.

et il reste plus simple d'appréhender un diagramme de classe uml de 20
boîtes qu'un programme python de 2000 lignes.

Il est aussi bien plus simple d'appréhender un crobard qu'un plan
d'architecte.

oui mais en architecture c'est encore différent car la partie plan est
quelque part plus distincte de la partie construction que dans
l'informatique.

Post by bruno modulix
mes deux centimes...

avec les miens cela fait 4

--
rafi

"Imagination is more important than knowledge."
(Albert Einstein)

Jacti

2005-09-12 08:48:35 UTC

nous sommes d'accord

je suis toujours d'accord, bien que je remplacerait conception par
spécification somme tu le faisais au début de ce paragraphe.

La frontière entre les deux est ténue. Très ténue.

tout à fait et cette frontière doit varier d'un point de vue à un autre
(ce qui ne me pose pas de problème)

je ne pense qu'il soit uniquement question d'introduire du dynamisme
(mais je suis plus familier des patrons structurels en général). il est
aussi question (et j'ai l'impression qu'il est surtout question) de
capitaliser. les exemples en c++ et autes ne sont que des exemples,
alors que les patrons me semblent surtout important pour réfléchir et
surtout échanger avec les autres.
quelque soit l'implementation, lorsque tu dis patron état je vois tout
de suite de quoi tu parles alors que je pourrais être un développeur c++
et toi un développeur python. je te suis aussi sur la remarque sur CLOS,
toutefois ici encore lorsque tu dis visiteur je sais de quoi tu parles
tu me cites un principe. la version langage de programmatin ne devient
alors qu'une traduction dans un auter formalisme (qu'uml).

idiomes et patrons de conception sont deux choses distincts à
deux niveaux différents.

Pas tant que ça... Quoi qu'en pensent certains, il n'y a pas de

mince je dois être en partie dans les certains ;-)

Tout à fait d'accord, mais vouloir rendre la conception totalement indépendante
de la réalisation est
une utopie. Je suis cependant d'accord que la première étape de conception doit
être la plus indépendante possible cependant.
Le "chemin" vers la réalisation doit quand même être explicité et l'on doit
"voir" et "comprendre" les raffinements
(donc les transition vers l'implémentation) de la façon la plus claire possible
(ne serait-ce que pour la maintenance).

Post by rafi
ce que je trouve important ici, c'est de souligner que l'objectif est un
utilisateur dans un domaine d'activité. et globalement c'est la priorité
de prendre en compte les besoins et contraintes de cet utilisateurs
avant les "contraintes" de la technologie de mise en oeuvre. et c'est
pourquoi les première réflexions relatives à la conceptions devraient
être le plus indépendant de la technologie que possible. (je vais
revenir sur ce point par la suite dans Case vs MDA)

Encore d'accord. La première chose à faire est de récolter et comprendre les
besoins utilisateurs (au sens métiers).
Il est toujours délicat de passer de la "machinerie" métier à la "machinerie"
informatique. Pour cette raison, ce passage
doit être fait et explicité soigneusement. Il ne faut pas tout attendre du MDA
mais c'est une approche prometteuse
à un horizon d'une dizaine d'année. Les efforts, si l'on veut pouvoir
"automatiser" le plus possible la transition
conception=>implémentation, doivent porter sur la description de la sémantique
de la plate-forme cible
(pas seulement la machine mais aussi l'environnement).

et UML n'est pas fait pour exprimer des
idiomes,

L'utilisation d'UML ne doit pas se limiter à ça mais elle doit AUSSI pouvoir
exprimer ceci.

c'est pour cela que la
comparaison UML / langage de programmation me surprend.

Personnellemnt, je la trouve évidente. Ce sont (ou ce devraient être)

si on avait exactement le même point de vue ce ne serait pas intéressant :-)

Post by bruno modulix
des niveaux d'abstraction successifs, et c'est toute l'histoire de

là par contre on est tout à fait d'accord. et comme je vois une
complémentarité je ne comprend pas la comparaison (dans le sens
comparaison à un même niveau).

UML est à la fois trop empêtré et en même temps il veulent trop tout
faire (/tout pouvoir faire) avec. la nouvelle norme est abominable
(encore plus que la précédente).

Oh que oui. Je pense que le terme "abominable" est vraiment adéquat pour
caractériser UML 2.0.
J'ai utilisé l'approche de Grady Booch dès 1985 (il n'y avait même pas
l'héritage dans son approche,
à l'époque, car Booch venait du monde ADA et ADA 83 ne possédait pas
l'héritage). C'était simple
à utiliser et ça rendait déjà de grands services.
Aujourd'hui, si on utilise UML 2.0 dans tous ses raffinements (mais ce n'est pas
le but d'un projet, en général),
on peut très facilement faire des séries de schémas totalement
incompréhensibles. Il faut donc rester
"raisonnable" dans son utilisation...

Je crains que tout cela ne relève plus du fantasme marketing que de la
réalité effective... Quand on voit le fiasco qu'on été les CASE tools...

je ne suis pas non plus un évangéliste de la MDA, et je ne pense pas que
ce soit une révolution. mais je travaille pile poil dedans, dons nos
MDE ne va pas résoudre tout les problème en réduisant le génie logiciel
à donner un modèle UML, cliquer sur un bouton et avoir le nouveau
système d'information de la sncf.

Oui cela reste clairement une utopie si on pense ça.

Post by rafi
MDE devrait aider à apporter des solutions à des problèmes récurrents et
permettre de passer plus de temps à comprendre les besoins des
utilisateurs plutôt qu'à toujours refaire la même chose.

Tout à fait d'accord.

Post by rafi
Les Case tools ont échoué (en partie au moins) car ils se vantaient de
fournir la réponse à tous les problèmes, ce qui est et restera
impossible. Par contre la MDE propose une approche différente: fournir
des solutions dans le cadre d'un domaine bien identifié (et non pas pour
tous les domaines). Par exemple dans le domaine de la santé, la gestion
d'un service hospitalier a toujours des grands principes similaires. par
contre les besoins de chirurgie ne sont pas les même qu'en radiologie.
il est donc intéressant de pourvoir, en tant que fournisseur de systèmes
d'informations pour services hospitaliers, de pouvoir capitaliser une
part de mon activité de développement de ces systèmes.

Il faut définir des patterns par domaines métiers pour les objets métiers de
différents domaines.

Post by rafi
Il faut (AMHA) que les outils et moyens de productions soit spécifiques
au domaine d'application. je ne suis plus au niveau langage, mais
lorsque je fais un système pour la sncf j'ai envie de manipuler les
concepts de train, de réservation, de voyageur ; lorsque je fais un
système pour france telecom de manipuler les concepts de pabx, de
routeur, de backbone ; et lorsque je fais un système pour un chu de
manipuler les concepts de patient, de service, etc. et cela au niveau de
la modélisation.

Tout à fait. Et, à un certain moment, il faudra montrer dans la conception,
comment ces différents objets métiers s'implémentent pas des objets
informatiques tels que
les listes chaînées, les SGBD, les piles, les ensembles, ect...
Par exemple, si je fais un logiciel de simulation de la circulation dans une
ville,
j'ai un objet "métier" plan de la ville que je peux implémenter par le "patron"
graphe générique
où les noeuds sont des carrefours (objet métier) et les arcs les axes de
circulation(à nouveau
un objet métier). Ces détails, je doit les exprmier dans les différentes étapes
de raffinements de ma conception.

Post by rafi
Ensuite je passe à des modèles de mise en oeuvre (notre utilisation de
ce terme diverge je suis désolé), puis des modèles de mise en oeuvre
pour une technologie particulière, et enfin du code. C'est (AMHA) ce que
peux apporter les approches de types MDE. Dans le contexte (technique je
te l'accorde) des applications de type 3-niveaux (Présentation / Métier
/ Données) nous avons des protos qui montre que l'on peut générer dans
certains cas jusqu'à plus de 90% d'une application uniquement à partir
d'un modèle de ce que l'on souhaite. et c'est après avoir fait le modèle
que je choisi d'avoir une couche de présentation web ou client lourd,
utiliser tel ou tel langage et MySQL ou Postgres. [ici je te rejoints
lorsque tu mentionnais 'pour un nombre fini de langages' je rajouterai
ou technologies]
pour finir, je suis d'accord avec toi sur l'aspect pipeau marketing de
ce type d'approche en ce moment. les évangéliste de l'omg sont comme les
politique (ils n'ont pas de problèmes, que des solutions) mais lorsque
l'on travail sur les normes (qui ne vont pas tout résoudre loin de là)
nous sommes globalement d'accord pour dire que c'est un chantier de 10
ans et que nous commencerons à tirer réellement des bénéfices de ces
travaux vers 2010.

Oui horizon de 10ans environ.

je suis d'accord avec toi

Post by bruno modulix
Le mien est: uml permet (éventuellement...) de faire un crobard, Python
permet de faire les plans, et le processeur réalise le tout.

et il reste plus simple d'appréhender un diagramme de classe uml de 20
boîtes qu'un programme python de 2000 lignes.

Il est aussi bien plus simple d'appréhender un crobard qu'un plan
d'architecte.

oui mais en architecture c'est encore différent car la partie plan est
quelque part plus distincte de la partie construction que dans
l'informatique.

Post by bruno modulix
mes deux centimes...

avec les miens cela fait 4

Aller je mets 4 centimes de plus...

Jacti

drkm

2005-09-10 23:36:07 UTC

Voir <URL:http://norvig.com/design-patterns/>, par exemple
<URL:http://norvig.com/design-patterns/img010.htm>.

--drkm

Bruno Desthuilliers

2005-09-11 16:21:06 UTC