Une façon d'illustrer cette phrase est d'essayer de séparer dans sa tête le "que fait t'on?" et le "comment le fait on?". Le modèle métier est le "que fait t'on" et le code (la syntaxe) est le "comment fait on".
Notre boulot d'informaticien est de transformer le "quoi" en "comment", et il en résulte le code, qui tout en représentant le quoi, il ne l'est pas vraiment. Ce qui est un problème, parce que la seule et unique chose qui nous intéresse vraiment c'est le "quoi" : le "comment", finalement n'est qu'une machinerie technique.
Donc ce que Damien veut dire, c'est qu'on essaie d'extraire le quoi du comment (le métier a partir de la syntaxe), et il a parfaitement raison de dire que c'est une approche imparfaite : le code n'est pas fait pour représenter ce qu'on veut faire, mais uniquement comment on le fait.
Le souci est d'essayer d'élever le modèle métier a un niveau d'abstraction au plus près de la conception "humaine", c'est a dire, de l'épurer au maximum du "bruit" causé par les problématiques informatiques : le code, le "comment c'est fait". Le tout doit permettre de transformer ce modèle métier en code, autant que possible. (sinon on fait de l'UML au autre qui sert a rien mis a part faire aide mémoire et joli sur le paper board).
Pour compléter je suis tenté de faire un comparaison avec un code en un langage tel le C (qui serait le métier), et sont "image" assembleur (qui serait donc le code), de ce même code compilé. Les deux font la même chose, le même "comment", pourtant il est très difficile d'extraire le "quoi" du code assembleur, on a perdu de l'information précieuse sur le modèle d'origine, qui est dans la tête du développeur.
[^] # Re: Meta-object protocol?
Posté par Anonyme . En réponse à la dépêche CodeWorker 4.4. Évalué à 5.
Notre boulot d'informaticien est de transformer le "quoi" en "comment", et il en résulte le code, qui tout en représentant le quoi, il ne l'est pas vraiment. Ce qui est un problème, parce que la seule et unique chose qui nous intéresse vraiment c'est le "quoi" : le "comment", finalement n'est qu'une machinerie technique.
Donc ce que Damien veut dire, c'est qu'on essaie d'extraire le quoi du comment (le métier a partir de la syntaxe), et il a parfaitement raison de dire que c'est une approche imparfaite : le code n'est pas fait pour représenter ce qu'on veut faire, mais uniquement comment on le fait.
Le souci est d'essayer d'élever le modèle métier a un niveau d'abstraction au plus près de la conception "humaine", c'est a dire, de l'épurer au maximum du "bruit" causé par les problématiques informatiques : le code, le "comment c'est fait". Le tout doit permettre de transformer ce modèle métier en code, autant que possible. (sinon on fait de l'UML au autre qui sert a rien mis a part faire aide mémoire et joli sur le paper board).
Pour compléter je suis tenté de faire un comparaison avec un code en un langage tel le C (qui serait le métier), et sont "image" assembleur (qui serait donc le code), de ce même code compilé. Les deux font la même chose, le même "comment", pourtant il est très difficile d'extraire le "quoi" du code assembleur, on a perdu de l'information précieuse sur le modèle d'origine, qui est dans la tête du développeur.