Discussion :

[B.AF]

Et puis Yann,

Très honnêtement, la nouvelle génération de développeur ferait mieux de tirer les leçons des erreurs passées sur la gestion de projet plutôt que de s'enfermer dans l'académisme.

Faut ouvrir les fenêtres, créer, ne pas être dogmatique.


C'est aussi l'informatique : la créativité, la possibilité de voir et de faire différemment.

Et ce n'est pas parce que certaines réalités ne sont pas expliquées dans les écoles qu'il faut pour autant en déduire qu'elles n'ont pas leur place; bien au contraire.

[chaplin]

Donc tu admets que ce n'est pas "straightforward".. par rapport à une simple écriture et pensée.

Pas plus "straightforward" que les maths. Pour résoudre une équation différentielle, il faut pas mal d'années d'étude de math, de la maternelle jusqu'au bac à par les surdoués.
Donc, il faut apprendre les maths, est ce que le langage informatique est compris par les utilisateurs ?
Il ne reste que les dessins pour simplifier la communication entre les utilisateurs et les informaticiens,
la différence, c'est qu'UML simplifie cette communication en utilisant un langage commun qui hélas est laissé aux initiés.
Mais les maths sont aussi l'appanage des initiés, ils savent très bien communiquer en utilisant la notation mathématique
comme les langages objets pourraient s'appuyer sur le langage UML, pour faire l'analogie.
Je préfère utilisé la notation arabe des chiffres à celle des romains pour faire des calculs, pour prendre un exemple.
Si UML était mieux enseigné et pas juste une pompe à fric, on pourrait en tirer un grand bénéfice.
Il faut bien comprendre qu'UML est un langage comme les langages informatiques et qu'il faut un temps incompressible
pour les apprendre, mais on peut pas dénigrer le fait qu'il apporte des avantages quand on le maîtrise.

Que de concepts informatiques !!!!

Je pense utiliser les mots par rapports à leur définition, et surtout pas pour frimer, car il y a un sens derrière.
Ce qui m'interesse c'est de comprendre, ça ne fais pas de moi quelqu'un de plus riche .

Tu te rendras vite compte dans la vraie vie qu'entre les supérieurs idiots ou léche-culs, les incompétents, les décisions qui te dépassent dans l'intérêt du Groupe, les guerres entre services, ou le poids de tel ou tel client, etc etc, le "plaisir" n'est de loin pas le moteur d'un développement ...

- Absolument d'accord.

Il ne faut pas dénigrer UML pour autant car il a son utilité.

[yann2]

B.AF

Je n'ai vrament pas le temps de développer (dommage) mais, quand je lis ça :

UML....Ca me fait rire...

Tu mets 10 personnes dans la salle à faire de la modélisation UML sur le même sujet, il n'y en a pas une qui te sort le même process..

UML c'est une vaste blague...

Ca sert à quoi d'avoir un formalisme de présentation alors que la perception et donc la concpetion et par nature spécifique à la personne ?

Tu finis par te retrouver avec une application complêtement incohérente, mais au moins elles sont écrites...

Ca me montre tout simplement que soit tu ne sais pas à quoi sert UML soit que tu penses que les développeurs informatiques sont des cons qui croient qu'UML est une solution magique.

Si tu ne sais pas à quoi sert UML tu peux commencer par lire les retours des gens qui ont certainement une meilleur vision et recul que toi et moi : http://www.sewatech.fr/article-uml.html

Enfin, je pense que ce n'est pas la peine de me remonter ce vieil adage du si vieillesse pouvait et si jeunesse savait. Parce que tout au long de mes recherches personnelles ce que je priorise c'est les retours d'expériences. Ce que je fais même sur ce topic. J'ai plus l'impression que tu nies tout ce qui ne t'intéresse pas en bloc sans même regarder ce que ça pourrait t'apporter !

Yann

[CedricMocquillon]

Autant j'étais parfaitement d'accord avec souviron jusque là, mais sur l'intérêt d'UML, je ne suis plus du tout d'accord. L'intérêt est justement de communiquer et lorsque l'on cherche à communiquer, on se pose la question de l'interlocuteur visé. UML est parfait pour communiquer d'un point de vue technique et je pense qu'il est plus adapté qu'une forme plus littéraire (un petit schéma vaut mieux qu'un long discours). L'autre avantage est de partager un "langage de communication" commun ce qui peut éviter des quiproquos. Je suis donc d'accord que ce n'est pas un outil adapté pour présenter son travail à des personnes du métier mais ce n'est pas non plus son but.

[rakakabe]

L'intérêt est justement de communiquer et lorsque l'on cherche à communiquer, on se pose la question de l'interlocuteur visé. UML est parfait pour communiquer d'un point de vue technique et je pense qu'il est plus adapté qu'une forme plus littéraire (un petit schéma vaut mieux qu'un long discours). L'autre avantage est de partager un "langage de communication" commun ce qui peut éviter des quiproquos. Je suis donc d'accord que ce n'est pas un outil adapté pour présenter son travail à des personnes du métier mais ce n'est pas non plus son but.

Ok, . Et UML peut aider a la comprehension des milliers de code que l'on doit deboguer ou faire evoluer des mois ou des annees plus tard.

Pour les personnes de metier, mieux vaut utiliser des tas de dessins IHM (plutot que de citer les besoins fonctionnelles qui ne permettent pas de garantir la validite du produit final) car cela facilite la communication (du moins dans mon cas).

Mais

[souviron34]

Enfin, je pense que ce n'est pas la peine de me remonter ce vieil adage du si vieillesse pouvait et si jeunesse savait. Parce que tout au long de mes recherches personnelles ce que je priorise c'est les retours d'expériences. Ce que je fais même sur ce topic. J'ai plus l'impression que tu nies tout ce qui ne t'intéresse pas en bloc sans même regarder ce que ça pourrait t'apporter !

C'est moi qui l'ai dit.. Mais ce n'est pas contre toi ou "les jeunes" du tout...

C'est juste qu'avec l'expérience et le nombre de projets et d'équipes (je dois en être à quelque chose comme 20 ou 25, dans des environnements très divers, de toutes petites boîtes à des multinationales, de consultant à chef de projet, de public à privé, d'indutriel à R&D à banques, ...) on a évidemment bien plus de "statistiques" sur les comportements et humains, et des projets, et un recul sur les techniques et modes..

Il est normal que l'on soit enthousiaste sur tel ou tel "nouveau" truc quand on est jeune... Mais il est également normal que 27 ans de métier t'apprennent d'autres choses... C'est tout ce que je voulais dire

mais sur l'intérêt d'UML, je ne suis plus du tout d'accord. L'intérêt est justement de communiquer et lorsque l'on cherche à communiquer, on se pose la question de l'interlocuteur visé. UML est parfait pour communiquer d'un point de vue technique et je pense qu'il est plus adapté qu'une forme plus littéraire (un petit schéma vaut mieux qu'un long discours). L'autre avantage est de partager un "langage de communication" commun ce qui peut éviter des quiproquos. Je suis donc d'accord que ce n'est pas un outil adapté pour présenter son travail à des personnes du métier mais ce n'est pas non plus son but.

Je n'ai pas dit de ne pas faire de schéma

J'ai dit qu'on pouvait très bien les faire avec Word ou sur un papier à la main, sans avoir besoin d'un langage particulier...

Le meilleur langage pour "partager" est celui que nous avons tous en commun, soit ici le français..

Le français est une langue précise, un dessin (ou un organigramme) peut très bien se faire avec Word.

Ta dernière phrase , pour moi, est bien le fond du problème : pourquoi avoir 2 outils pour communiquer, un pour les gens "techniques", et un pour les autres ??? Que de perte de temps....


Je ne dis pas que "ne pas profiter d'un nouvel outil" est ce qu'il faut faire. Je suis simplement contre (mais alors résolument) l'espèce de "déification" d'un outil (ou d'une méthode, ou d'un concept).

Et quand on voit les offres d'emploi, c'est exactement ça..

[souviron34]

Si tu ne sais pas à quoi sert UML tu peux commencer par lire les retours des gens qui ont certainement une meilleur vision et recul que toi et moi : http://www.sewatech.fr/article-uml.html

en gros, ce qu'il dit c'est qu'il l'utilise par habitude...

Mais que tout ce qui est basé dessus est trop lourd, coûteux, déjà obsolète, etc etc...

[chaplin]

Enfin, j’utilise souvent UML dans les missions d’audit, plus particulièrement les fonctions de reverse-engineering des outils. cela permet d’avoir rapidement une vue d’ensemble du système et de faire ressortir quelques éléments fondamentaux d’une conception objet : l’architecture en couches et les dépendances entre packages

Cette partie là est très interessante, car elle permet de tirer une documentation à partir d'un existant sous condition évidemment que le programme soit écrit avec un langage objet et qu'il y est un outil capable de faire du reverse-engineering.

[B.AF]

B.AF

Je n'ai vrament pas le temps de développer (dommage) mais, quand je lis ça :


Ca me montre tout simplement que soit tu ne sais pas à quoi sert UML soit que tu penses que les développeurs informatiques sont des cons qui croient qu'UML est une solution magique.

Si tu ne sais pas à quoi sert UML tu peux commencer par lire les retours des gens qui ont certainement une meilleur vision et recul que toi et moi : http://www.sewatech.fr/article-uml.html

Enfin, je pense que ce n'est pas la peine de me remonter ce vieil adage du si vieillesse pouvait et si jeunesse savait. Parce que tout au long de mes recherches personnelles ce que je priorise c'est les retours d'expériences. Ce que je fais même sur ce topic. J'ai plus l'impression que tu nies tout ce qui ne t'intéresse pas en bloc sans même regarder ce que ça pourrait t'apporter !

Yann

C'est toujours risible de lire ça, c'est un peu la catholique qui refuse de comprendre l'athée, en lui expliquant que c'est idiot de ne pas être catholique...

Quant à juger les développeurs qui croient en UML, non, je ne les juge pas, je ne les prend pas pour des cons, mais je ne crois pas qu'UML soit une révolution ou une avancée particuliére.

Maintenant, je comprends aussi que quelqu'un qui vend de la méthode, UML, c'est une garantie.
Pour moi, au quotidien, c'est juste un coût supplémentaire (formations, templates, motifs de conception de base...) qui n'apporte pas de valeur ajoutée particuliére.

L'essentiel est dans le use case (dans le sens défini par souviron) après que ça finisse en document powerpoint ou en séquence UML,...Ca ne change pas la qualité du fond.

UML, comme tout langage, tu peux faire tout et surtout n'importe quoi avec.
C'est un peu comme la génération de code : Il n'y a pas d'intelligence, si UML pouvait spécifier du métier, ça se saurait.

Donc même si tu veux spécifier du métier en UML tu es obligé de définir des terminologies, leur sens...En bref, tu te retrouves confrontée à l'éternelle problèmatique du wording, qui est déjà suffisamment complexe avec un langage naturel.


Quand tu en arrives à te décider à formaliser en UML (après, on peut rentrer dans des débats de basse cours sur "UML n'est pas une formalisation mais un langage", "UML machin" --> quand tu produit un document tu formalises, quel que soit le moyen qui soit à l'origine du document) c'est qu'à priori, tu as fait 90% du boulot qui est de comprendre.

Maintenant, la limite d'UML est qu'il n'est toujours pas la réponse à la communication entre métier et développement du fait d'absence de terminologies communes.

C'est un peu ce gap qu'essayent plus ou moins heureusement toutes les méthodes et les outils de résoudre. Mais pas de magie, la technique ne peut pas "comprendre".

UML c'est "encore" une couche qui ajoute une distance supplémentaire entre toi et ton client.

Déjà que souvent on se perd à traduire du langage naturel en langage informatique, pourquoi ajouter un langage intermédiaire qui lui va induire aussi des problèmes de traductions dans les deux sens.

Là où tu as 2 risques d'incompréhension majeur (bi directionnel métier / développeur); tu en ajoutes finalement
Métier <--> Analyste = 2
Analyste <--> UML = 2
UML <--> métier par transparence =2
UML <--> développeur =2
Analyste <--> dévelopeur =2

Tu montes à 10 sources d'erreurs de conception, uniquement basée sur la capacité des gens à comprendre et à traduire.

Après tu peux aussi décider que tout le monde fait de l'UML...Mais ton client ne va nécessairement apprècier les reportings, donc tu feras un report client, basé sur une traduction d'UML, donc tu trouveras faire un change tracking de ton doc vers UML, et finalement, la réalité sera dans ton document client, qui sera fait des terminologies du client, donc tu feras un autre document pour permettre en maintenance de traduire tes terminologies. Qui elles mêmes vont évoluer...etc,etc....

UML est un buzz commercial rien de plus.
Comme SOA, comme WEB 2.0 comme plein d'autres termes (RIA, etc,etc...)
Parce qu'en informatique on vend AUSSI de la techno et du process.

Es-tu simplement certain que tu comprends sur un gros projet, l'incidence et les coûts d'UML ? Non.

[souviron34]

Cette partie là est très interessante, car elle permet de tirer une documentation à partir d'un existant sous condition évidemment que le programme soit écrit avec un langage objet et qu'il y est un outil capable de faire du reverse-engineering.

Sauf que ces 2 conditions ne sont que très très rarement présentes...

Un bon vieux reverse-engineering consiste à se taper le code, en général mettre tout un tas de printf pour suivre au run-time, et faire un schéma à côté, en général (plus rapide car au fur et à mesure), en texte dans un document style Word ou Notepad ou n'importe quoi.

..

[souviron34]

C'est toujours risible de lire ça, c'est un peu la catholique qui refuse de comprendre l'athée, en lui expliquant que c'est idiot de ne pas être catholique...
...
Es-tu simplement certain que tu comprends sur un gros projet, l'incidence et les coûts d'UML ? Non.

Pour tout le reste je suis d'accord, mais pour ça il y a d'autres moyens de le dire..

Visiblement yann2 est très ouvert, mais il n'a juste pas l'expérience de développement suffisante. Cela n'en fais cependant pas un "bouché".... et convaincre se fait en respectant les gens, pas en les méprisant... (ce que tu défends par ailleurs, surtout si tu es à l'origine un des signataires du Manifeste Agile).

tu t'es laissé emporter....

..Tu montes à 10 sources d'erreurs de conception, uniquement basée sur la capacité des gens à comprendre et à traduire.

C'est également valable pour toute méthode (ou méthodologie) demandant (exigeant) de la documentation avant une action... Surtout (et c'est ce que je voulais dire par "industrialisation") dans un contexte où on a une grosse équipe....

La dilution et l'arborescence des "responsabilités" implique une traduction à chaque niveau, ce qui se fait forcément en perdant de l'information. Et comme elle doit se faire dans les 2 sens (haut vers bas, puis bas vers haut) on double les pertes... (le fameux "téléphone arabe")...

C'est la raison qui fait que, quelle que soit la méthode utilisée, je préconisais de petites équipes... N'importe quelle grosse équipe se retrouve prise dans ce dilemne.. Et du coup cette perte d'information.

Et même une petite équipe, comme tu le dis, dès l'instant où elle "perverti" le langage de l'usager et la description haut niveau,, introduit une erreur de traduction.


Maintenant, je suis 100% d'accord avec tout le reste

[gorgonite]

Sauf que ces 2 conditions ne sont que très très rarement présentes...

Un bon vieux reverse-engineering consiste à se taper le code, en général mettre tout un tas de printf pour suivre au run-time, et faire un schéma à côté, en général (plus rapide car au fur et à mesure), en texte dans un document style Word ou Notepad ou n'importe quoi.

là je ne suis pas trop d'accord... car ajouter des printf & cie est quand même très fastidieux.
étant "habitué" aux techniques d'analyse de système, je préfère les solutions basés sur un reverse-engineering du binaire avec reconstruction d'une hiérarchie par différentes techniques d'inférence et d'abstraction. ce n'est pas toujours la panacée, et il existe des cas où la montée en abstraction reste très limitée, mais ça a l'avantage de marcher quelque soit le langage de départ, et pouvoir sortir des graphes de dépendances assez rapidement


quelques liens :
http://citeseer.ist.psu.edu/compress...gel04static.ps
http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf

[souviron34]

là je ne suis pas trop d'accord... car ajouter des printf & cie est quand même très fastidieux.
étant "habitué" aux techniques d'analyse de système, je préfère les solutions basés sur un reverse-engineering du binaire avec reconstruction d'une hiérarchie par différentes techniques d'inférence et d'abstraction. ce n'est pas toujours la panacée, et il existe des cas où la montée en abstraction reste très limitée, mais ça a l'avantage de marcher quelque soit le langage de départ, et pouvoir sortir des graphes de dépendances assez rapidement

Eventuellement (je dis bien éventuellement) possible si tu as un seul binaire, mais si ton appli est constituée de plusieurs binaires en // (genre des "serveurs d'objets") ???

Et comme même un outil automatique ne t'empêchera pas de devoir aller vérifier que c'est bien comme ça que ça se passe, il te faudra de toutes façons mettre ton nez dans le code...

Alors peut-être qu'avec un soft de 5000 lignes ça marche..

Mais avec des softs "normaux" de 500 000 à 5 millions de lignes, c'est hors de question.. Non seulement l'outil ne démèlera pas l'architecture, mais le temps passé à vérifier 2 choses en // (comprendre le soft, et vérifier que l'outil automatique a bien fait le travail) est doubler le temps...

Par expérience, mettre des printf est très souvent - je dirais même quasi tout le temps - l'alternative la plus rapide pour s'y retrouver...

Même quand on a les sources...

La seule autre indication est les répertoires, leurs noms, et les noms des fichiers... Mais ça ne fait pas tout le boulot, en particulier les appels croisés ou les dialogues clients/serveurs..

[gorgonite]

Et comme même un outil automatique ne t'empêchera pas de devoir aller vérifier que c'est bien comme ça que ça se passe, il te faudra de toutes façons mettre ton nez dans le code...

comme tout outil automatique, il ne fait qu'aider... il faut donc savoir quand ça vaut le coup de l'utiliser

Alors peut-être qu'avec un soft de 5000 lignes ça marche..

Mais avec des softs "normaux" de 500 000 à 5 millions de lignes, c'est hors de question.. Non seulement l'outil ne démèlera pas l'architecture,

j'ai ajouté des liens... peut-être changeras-tu d'avis après les avoir consultés ? je n'entrerais pas plus dans les détails ici, mais tu sembles trop souvent douter de tout ce que tu n'as pas testé durant 20 ans

mais le temps passé à vérifier 2 choses en // (comprendre le soft, et vérifier que l'outil automatique a bien fait le travail) est doubler le temps...

Par expérience, mettre des printf est très souvent - je dirais même quasi tout le temps - l'alternative la plus rapide pour s'y retrouver...

pourquoi devoir vérifier que l'outil a bien fait son boulot... le genre d'outil dont je parle ne monte en niveau d'abstraction que s'ils sont sûrs du résultat. cela aura l'inconvénient de parfois mixer différents niveaux d'abstraction dans le "pseudo-code" résultat. mais au moins inutile de se demander s'il n'a pas un peu trop fait d'hypothèses

[souviron34]

@elitost :

tu ne te doutais pas que ton thread ferait un tel ramdam , hein

[souviron34]

j'ai ajouté des liens... peut-être changeras-tu d'avis après les avoir consultés ? je n'entrerais pas plus dans les détails ici, mais tu sembles trop souvent douter de tout ce que tu n'as pas testé durant 20 ans



pourquoi devoir vérifier que l'outil a bien fait son boulot... le genre d'outil dont je parle ne monte en niveau d'abstraction que s'ils sont sûrs du résultat. cela aura l'inconvénient de parfois mixer différents niveaux d'abstraction dans le "pseudo-code" résultat. mais au moins inutile de se demander s'il n'a pas un peu trop fait d'hypothèses

Euh.. Là on ne parle pas de "pseudo-code"..

On parle de déassemblage..

Or tout nom de variable, fonction, et les commentaires, sont perdus dans un binaire "opérationnel", non compilé avec l'option debug..

Et même compilé avec debug, un simple "strip", sur système unixoide, enlève toutes les chaînes de caractères....

Donc avoir des lignes d'assembleur et un flow-chart n'indiquant ni les noms de variables (ni éventuellement les noms de fonctions) ni les commentaires ne servira pas à grandchose pour du reverse-engineeriing.... (Avoir une inversion de matrice par le pivot de Gauss en assembleur ne te faclitera pas grandement la tâche)

Ce qu'ils disent dans ces articles est que 1) c'est de la recherche et 2) c'est fait pour pouvoir faire des patchs de binaires.. Pas pour faire du reverse-engineering..

Très bonne approche, mais inutile pour du reverse-engineeriing...

[gorgonite]

Ce qu'ils disent dans ces articles est que 1) c'est de la recherche et 2) c'est fait pour pouvoir faire des patchs de binaires.. Pas pour faire du reverse-engineering..

Très bonne approche, mais inutile pour du reverse-engineeriing...

ceux sont des exemples... il existe des applications pour donner du pseudo-code, mais ça n'est pas encore trop sorti des labos en effet

si je dis que ça a une application concrète en reverse engineering, c'est que j'ai déjà vu des programmes en faire

[Monstros Velu]

Concernant UML, je me permet de signaler que pour du développement franco-français, c'est peut-être plus simple d'utiliser le Français, mais que quand on travaille avec, par exemple, des chinois, des roumains ou des polonais, un coup d'UML est bien pratique pour être sur de la compréhension.

[souviron34]

Concernant UML, je me permet de signaler que pour du développement franco-français, c'est peut-être plus simple d'utiliser le Français, mais que quand on travaille avec, par exemple, des chinois, des roumains ou des polonais, un coup d'UML est bien pratique pour être sur de la compréhension.

Plutôt que l'anglais ?

[souviron34]

ceux sont des exemples... il existe des applications pour donner du pseudo-code, mais ça n'est pas encore trop sorti des labos en effet

si je dis que ça a une application concrète en reverse engineering, c'est que j'ai déjà vu des programmes en faire

OK.. Mais 1) j'aimerais bien en voir en "action", 2) comment peux-tu exploiter le résultat puisqu'il n'y a plus de noms de variables ?? et 3) et comment peuvent-ils faire quand il y a des timers, des événements //, des interruptions ??