Discussion :

[el_slapper]

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.

J'ai presque envie de dire, au vu de mon expérience, que bosser avec des non-francophones, ou même avec des francophones mais bossant dans un fuseau horaire différent, c'est du suicide.

Quand on développe, quelle que soit la méthode, il ya toujours, à la fin, un moment ou on se pose des questions. Ou y'a un truc pas clair. Certains se disent "ça doit être ça", et font à leur idée. Evidemment, ils ont souvent tort. Et d'autres posent la question. Eh ben quand le type à qui poser la question n'est pas de l'autre coté du couloir - ou, au pire, de l'autre coté de la rue - le projet part en couille. Tout de suite. Ne serais-ce qu'au niveau du délai. Si il faut contacter par mail un gugusse, c'est fini, on prend 3 jours dans la vue. Si il faut appeler la Guyane, c'est fini, le type commence à bosser alors qu'on a déjà fini. Et si il faut communiquer dans une mauvaise langue, les subtilités ne passeront pas - UML ou pas. On aura alors un truc qui marche globalement, mais le détail sera foireux, parceque mal compris.

[gorgonite]

OK.. Mais 1) j'aimerais bien en voir en "action"

va falloir attendre un peu... où visiter un labo pour cela

je crois avoir entendu parler d'une entreprise qui a "récemment" commercialisé un outil de ce style, mais je ne m'en souviens plus trop

2) comment peux-tu exploiter le résultat puisqu'il n'y a plus de noms de variables ??

les noms de variable peuvent certes aider, mais ils ne font pas tout, et des outils pour renommer des variables ça existe... encore faut-il un humain pour donner un nom à une variable, ou alors avoir une reconnaissance de motif sur des cas particuliers (comme la multiplication matricielle )

et 3) et comment peuvent-ils faire quand il y a des timers, des événements //, des interruptions ??

étant que ce genre d'outils visent surtout à jouer dans la catégorie des codes "certifiables", il faut te dire que certaines fonctionnalités n'ont pas forcemment été étudiées.
enfin, elles l'on peut-être étées de manière détournée, mais ce n'est pas mon domaine, et je ne pourrai que conjecturer

[B.AF]

Souviron, non je ne m'emporte pas (juste hyperactif et un chouilla impusif parfois) :

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

Quand je lis ça, l'exemple que j'ai donné, c'est celui qui me vient à l'esprit.
En gros, je suis un vieux con qui n'a rien compris à la brillance et la jeunesse d'UML...

Y'a des jours...

Et c'est pas une question de vieillesse ou de jeunesse.

C'est une pure réaction au dogme :
Il y a ceux qui peuvent prendre du recul
Il y a ceux qui pensent que l'écrit est la référence.

Bref, dirait un de mes anciens profs 'Pour la grande majorité, il sont contents de pouvoir appliquer la pensée des autres'.

Et heureusement que nous ne sommes pas tous ainsi, sinon, le principe même de l'invention n'existerai pas.

Quant à la derniére assertion elle est vrai : à académiser la gestion des projets, on en oublie souvent la réalité économique de ceux -ci.
Plus le process est lourd, plus la rentabilité du projet est faible.
C'est quasiment une règle de marché.

Excusez moi, mais c'est facile de dire à 20 piges qu'on comprend tout et qu'on connait le mieux et que les vieux sont des cons qui se trompent, surtout quand à priori, on n'a jamais eu besoin ni de décider des choix, ni à faire ce qui est ingrat (licensier, pousser dehors, tension avec un client) et qu'on sort ça en sortant d'écoles ou les profs sont d'ailleurs les même vieux.
(oui, il y en a qui ont la malchance de me supporter)

L'idéalisme, c'est bien; mais bon il y a un moment, on ne vit pas non plus dans le monde des bisounours.

Déviation soit, mais déviation nécessaire pouisqu'elle montre aussi une autre réalité :
Le refus d'une méthode ou d'un outil quand les membres de l'équipe sont trop académiques dans leur mentalité, quand bien même justifiée et parfois la cause de beaucoup de problèmes.

[souviron34]

@gorgonite :

Je dirais donc que quand tu dis :

é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

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

tu te vantes et induit en erreurs les lecteurs du thread...

Ce n'est pas encore fait, ça ne tient pas compte de tout, et ça ne sort pas les noms de variables (et ça ne le peut pas). (et par conséquent on retombe sur mon argument (et celui de B.A.F.) sur le temps passé en double..car traduire "reg1 add reg2" .... en "NomExpliciteDeVariable1 + NomExpliciteDeVariable2" va prendre un temps plus que non négligeable)

Je n'appelle donc pas ça du reverse-engineering opérationnel, et ta petite pique à la fin de ton post ne me touche pas, puisque visiblement ce n'est pas d'actualité (et pas demain la veille)...

Et par conséquent ce que j'avais cité sur "le bon vieux reverse-engineeriing" tient toujours, pour quelques (bonnes) années

[souviron34]

J'ai presque envie de dire, au vu de mon expérience, que bosser avec des non-francophones, ou même avec des francophones mais bossant dans un fuseau horaire différent, c'est du suicide.

boff..

J'ai travaillé avec des Américains, Australiens, Chinois, Russes, Libanais, et Roumains, et je n'ai jamais eu de problèmes..

Mais nous communiquions en anglais...

Et c'est ce que je disais ci-dessus : si pour communiquer il fut apprendre un nouveau langage, autant apprendre l'anglais, qui servira en plus à autre chose que l'informatique pure...

Donc apprendre UML pour dire "je peux communiquer", que ce soit en français ou avec des étrangers, est très farfelu....

C'est comme l'espéranto.. Ca n'a jamais marché, parce que, pour toutes les langues, il fallait en apprendre une autre... Résultat : das la diplomatie ça a été le français , et pour le reste l'anglais.. Et maintenant c'est l'anglais partout.. Mais déjà tous les anglophones n'ont pas à apprendre forcément autre chose.. (et je parle aussi bien des anglais que des indiens ou philippins, là...)...

On peut déplorer que ce soit l'anglais, mais c'est un autre débat.. Dans celui-ci, soit on a notre langue nationale, soit on a une langue internationale qui sert à pleins de choses, dont l'informatique. Pourquoi en utiliser une nouvelle, qui restreint qui plus est l'usage à l'informatique ??

C'est tout ce que je dis depuis tout à l'heure...

[souviron34]

En gros, je suis un vieux con qui n'a rien compris à la brillance et la jeunesse d'UML...

Tu le savais pas ??

(je me suis fait dre le même truc sur un autre débat il y a peu, mais l'auteur était plus vindicatif et moins ouvert que yann2, qui ne dit pas méchamment...)

Excusez moi, mais c'est facile de dire à 20 piges qu'on comprend tout et qu'on connait le mieux et que les vieux sont des cons qui se trompent,

Nous en sommes responsables (en tous cas ma génération)...

C'est ma génération qui a mis en avant "le jeunisme"...

[chaplin]

Pourquoi en utiliser une nouveau langage (UML), qui restreint qui plus est l'usage à l'informatique ??

Uniquement pour l'informatique !!

Perso, je l'avais introduit dans l'entreprise au niveau d'une formation, le collègue n'était pas enchanté. Quand le chef a décider de s'y mettre avec Rationnal Rose, j'ai tout de suite abandonner l'idée, car il était le champion toute catégorie pour faire très compliquer quand on peut faire très simple.

En revanche, avoir un mentor pour faire un projet en UML, ça doit être fortement enrichissant. Ensuite, c'est une question de juste milieu sans faire de l'excès ni l'inverse.

[CedricMocquillon]

En même temps, lorsqu'on aborde des sujets "pointus", on doit bien définir un "cadre" bien précis, c'est ce que permet UML. On peut très bien communiquer les même idées en langue naturelle ou par des schémas mais pour être sur qu'il n'y aura pas d'ambiguïtés, il va falloir commencer par définir chaque terme que l'on va utiliser, chaque symbole de nos schémas pour être bien sûr d'être bien compris de nos interlocuteurs. Pour éviter de refaire ce travail sans arrêt et de batailler à chaque définition, autant utiliser un formalisme commun qui une fois assimilé pourra nous resservir dans d'autre projets/équipes.

PS: j'ai un peu simplifié pour mettre en évidence l'avantage d'un formalisme commun et "répandu". Après, je ne suis pas un fanatique d'UML, tout formalisme un minimum répandu peut faire l'affaire

[gorgonite]

tu te vantes et induit en erreurs les lecteurs du thread...

Ce n'est pas encore fait, ça ne tient pas compte de tout, et ça ne sort pas les noms de variables (et ça ne le peut pas). (et par conséquent on retombe sur mon argument (et celui de B.A.F.) sur le temps passé en double..car traduire "reg1 add reg2" .... en "NomExpliciteDeVariable1 + NomExpliciteDeVariable2" va prendre un temps plus que non négligeable)

1) je ne me vante pas, je dis juste qu'il existe déjà ce genre d'outils dans les labos... et quand on parle de techniques d'analyse de système, il est très clair qu'on est dans ce milieu. le niveau moyen des informaticiens "industriels" en prod en matière de sémantique & autre est quand même assez souvent proche de 0

donc si une personne essayant de comprendre le contexte de ce que je dis passe ici, il verra rapidement de quoi je parle

2) tu sembles croire que tout ce qui n'est pas fait à la main par un être humain ne peut qu'être que peu exploitable... et cela vient sans doute du fait que tu sembles grandement sous-estimer le niveau de ces outils qui ne se contentent pas sortir les instructions en asm. donc ta phrase "reg1 add reg2" .... en "NomExpliciteDeVariable1 + NomExpliciteDeVariable2" ne représente pas les problèmes réels qui vont être rencontrés

si tu t'intéresses aux représentations graphiques hiérarchisées, tu sauras qu'un ordinateur peut produire des graphes compréhensibles par un ingénieur, et qui donnent une bonne idée du code... même si ce n'est pas forcemment compteur += (condition ? 4 : -2);

3) si dans une équipe de 3/4 personnes dans un petit labo, on arrive à produire rapidement ce genre d'outils (c'est vrai qu'on connait plutot bien les aspects théoriques sous-jacents, mais faut pas pousser... quelqu'un de motivé pourra rapidement avoir les notions nécessaires pour comprendre le minimum nécessaire), il ne fait aucun doute qu'une équipe de développement en entreprise devrait réussir à faire quelque chose de similaire très rapidement. et si elle fait bien son boulot, pourrait même commercialiser un produit aux performances acceptables plus rapidement qu'un labo

Je n'appelle donc pas ça du reverse-engineering opérationnel,

je ne suis pas sûr qu'une entreprise confie une tache de reverse-engineering à une équipe lambda... et tu serais surpris du nombre d'équipes R&D qui suivent de près toute l'actualité de la recherche, et construisent des proto utilisables de choses qui pourraient sembler "inutilisables et stupides" à beaucoup d'équipe de prod

et ta petite pique à la fin de ton post ne me touche pas, puisque visiblement ce n'est pas d'actualité (et pas demain la veille)...

ce n'était pas une pique, mais un constat... je pense donc je suis (Descartes) semble être ton credo dès que quelqu'un parle de quelque chose que tu n'as pas expérimenté toi-même. c'est compréhensible, même admirable
(et tellement mieux que la mode prêt-à-penser qu'ingurgitent tant de personnes dans notre société... ces "grands intellectuels" qui attendent le journal pour savoir quoi penser d'un problème. mais un débat sur la manipulation des masses par les médias n'a pas sa place ici ^^)

[chaplin]

Une feuille blanche et un stylo, même si c'est spartiate restera toujours un bon moyen pour formuler ses idées quelque soient les méthodes, déjà pour prendre des notes.
S'il y a des bonnes choses à prendre de telle ou telle méthode ou langage ou outil, pourquoi s'en priver.

[Monstros Velu]

Plutôt que l'anglais ?

Les noms en anglais, mais les descriptions sous forme de schemas.

[GrandFather]

Se plaindre d'UML parce que certains ne l'utilisent pas toujours à bon escient, c'est un peu se plaindre du marteau parce que certains l'utilisent en le tenant par la tête ou pour enfoncer des vis...

UML est un outil fabuleux pour offrir des vues statiques et dynamiques lisibles d'une application développée avec un langage objet comme Java ou C++ ; par contre, on peut être plus circonspect sur son usage en analyse fonctionnelle, où effectivement se posent des problèmes de sémantique et d'ontologie. Ces problèmes sont pris en compte par le langage UML, qui propose notamment de les résoudre avec la création de « prototypes », mais on arrive alors à des niveaux de complexité et d'abstraction qui rendent les diagrammes totalement abscons pour des non-spécialistes. Totalement inexploitables donc pour un dialogue avec un client, par exemple.

[gorgonite]

par contre, on peut être plus circonspect sur son usage en analyse fonctionnelle, où effectivement se posent des problèmes de sémantique et d'ontologie. Ces problèmes sont pris en compte par le langage UML, qui propose notamment de les résoudre avec la création de « prototypes », mais on arrive alors à des niveaux de complexité et d'abstraction qui rendent les diagrammes totalement abscons pour des non-spécialistes.

pour ceux que ça intéresse, il y a eu pas mal de travaux sur des modélisations d'UML via les graphes hiérarchiques (Hoffmann & cie), avec des résultats parfois intéressants... même si ça a en pratique surtout aider à la réalisation de graphiques plus aérés

[souviron34]

1) je ne me vante pas, je dis juste qu'il existe déjà ce genre d'outils dans les labos...

euh...

étant "habitué" aux techniques d'analyse de système, je préfère les solutions basés sur un reverse-engineering

(comment peut-on être "habitué" à 24 ans ???)

D'autre part, tu le soulignes toi-même "dans les labos"...

et quand on parle de techniques d'analyse de système, il est très clair qu'on est dans ce milieu. le niveau moyen des informaticiens "industriels" en prod en matière de sémantique & autre est quand même assez souvent proche de 0

euh..... J'ai passé l'hiver dernier à faire de la rétro-ingéniérie (exemple déjà cité. Code de 30 ans ayant subi 1 grande modif (Fortran->C), étant en train d'en subir une deuxième (C->C++), mais ayant en cours de route changé de structure, peu doucmentée (car changement d'équipe cause rachat de boîte) il y a 7 ans)....

Pas du tout dans des labos ni de la recherche. Vraiment dans l'industrie.. Et je crois que tu sous-estimes très largement les capacités des ingénieurs "industriels"...

Que ce soit le cas des "p'tis jeunes" tout frais sortis des écoles informatiques, peut-être.. je ne sais pas.. Mais en général, les ingénieurs de bureaux d'étude ou des équipes de prod (y compris dans les SSII) dans le milieu industriel sont des gens brillants....

Encore une fois, après, si tu prends des projets avec des équipes de 200 personnes, c'est sûr qu'avec les stages, emploi-jeunes, etc, il y aura de tout.... Mais une équipe de 10 à 20 personnes en milieu industriel est constituée, la majeure partie du temps, de docteurs, d'ingénieurs, etc etc...

tu sembles croire que tout ce qui n'est pas fait à la main par un être humain ne peut qu'être que peu exploitable... et cela vient sans doute du fait que tu sembles grandement sous-estimer le niveau de ces outils qui ne se contentent pas sortir les instructions en asm. donc ta phrase "reg1 add reg2" .... en "NomExpliciteDeVariable1 + NomExpliciteDeVariable2" ne représente pas les problèmes réels qui vont être rencontrés

Non je ne dis pas ça.. Je dis que, par expérience, dans le milieu industriel des vrais softs, quand on fait de la rétro-ingénierie, c'est que les concepteurs ont disparus...

Si on en est à faire de la rétro-ingéniierie de binaire (ça m'est arrivé une fois),c'est pour du dépannage..

Sinon, ce qu'on cherche, c'est l'arborescence des fonctions et des flux de données... dans le code source.... (entreprise rachetée, équipe disparue, à la retraite, auteurs démissionnaires, etc etc).

Donc il faut les noms de variables et de fonctions...

Je dis que toi, tu sous-estimes les problèmes réels, qui sont ce traçage...

si tu t'intéresses aux représentations graphiques hiérarchisées, tu sauras qu'un ordinateur peut produire des graphes compréhensibles par un ingénieur, et qui donnent une bonne idée du code... même si ce n'est pas forcemment compteur += (condition ? 4 : -2);

Non, je ne m'y intéresse pas je suis un praticien, pas un théoricien (dans ce domaine)

(j'ai abandonné la recherche fondamentale parce que justement, j'aime bien produire quelque chose d'utilisé...)

je ne suis pas sûr qu'une entreprise confie une tache de reverse-engineering à une équipe lambda... et tu serais surpris du nombre d'équipes R&D qui suivent de près toute l'actualité de la recherche, et construisent des proto utilisables de choses qui pourraient sembler "inutilisables et stupides" à beaucoup d'équipe de prod

Encore une fois, je suis au regret de te dire que, étant dans un labo, tu ne vis pas l'expérience industrielle..

C'est un fait de la vie de tous les jours, dans l'industrie,de faire de la rétro-ingénierie (pour les raisons sus-dites)..

Je pense que là tu appliques à l'industrie ce que tu crois (et vois dans tes études et au labo), et non pas ce qui s'y passe...

En gros, ça peut éventuellement être intéressant, un truc de recherche, mais ce qui l'est encore plus, c'est que ton équipe comprenne comment le soft marche...

D'où ma remarque sur l'utilisation massive de printf...

En un mois, tu as grâce à ça décodé, documenté, identifié peut-être 10 000 ou 20 000 lignes d'un code qui marche.. et partagé l'info (un doc word attaché à un email, ou bien une page Wiki ).

[gorgonite]

euh..... J'ai passé l'hiver dernier à faire de la rétro-ingéniérie (exemple déjà cité. Code de 30 ans ayant subi 1 grande modif (Fortran->C), étant en train d'en subir une deuxième (C->C++), mais ayant en cours de route changé de structure, peu doucmentée (car changement d'équipe cause rachat de boîte) il y a 7 ans)....

faire de la traduction automatique de deux langages, si l'on se contente de jouer avec les mêmes "grandes idées", c'est juste une histoire de parseurs
après clairement si en plus il faut redocumenter intégralement le code, là ça va demander plus de boulot

Pas du tout dans des labos ni de la recherche. Vraiment dans l'industrie.. Et je crois que tu sous-estimes très largement les capacités des ingénieurs "industriels"...

je suis ingénieur de formation (même si je suis actuellement dans un labo), et j'ai de très nomberux contacts avec des ingénieurs agés de moins de 30 ans développant des applis dans des SSII... et la vision que j'en ai serait plutot l'utilisation systématique d'un sous-ensemble très pauvre des langages (souvent du à un mauvais apprentissage de la programmation, et souvent uniquement d'un sous-ensemble de la POO compatible avec Java / C# / C++), ou la programmation en mode boite noire avec l'utilisation parfois excessive des frameworks externes avec des changements en fonction des modes

j'ai également fait pas mal de petits contrats étudiants avec des entreprises pour développer des petites applis, et souvent on remarque qu'en face ils ne font pas confiance au code, même avec des tests poussés pour montrer que ça marche, et préfère un recours massif aux frameworks, et une utilisation des fonctionnalités de bases des langages

clairement, je ne connais pas trop les boites ayant des développeurs avec 30 ans d'expérience (mais mon père bossant dans l'informatique de gestion, j'ai quand même pu suivre ce qui se passait dans sa boite depuis près de 15 ans )

Que ce soit le cas des "p'tis jeunes" tout frais sortis des écoles informatiques, peut-être.. je ne sais pas.. Mais en général, les ingénieurs de bureaux d'étude ou des équipes de prod (y compris dans les SSII) dans le milieu industriel sont des gens brillants....

après, j'ai aussi vu de grosses compétences dans certaines équipes de R&D, et eu plutot de bons échos de la part de thésards CIFRE...

Si on en est à faire de la rétro-ingéniierie de binaire (ça m'est arrivé une fois),c'est pour du dépannage..

j'ai déjà vu un cas où une boite demandait à un labo de faire de la rétro-ingénierie de binaire car ils avaient perdu leurs sources... (aucun détail supplémentaire ne sera donné, même par MP)

Sinon, ce qu'on cherche, c'est l'arborescence des fonctions et des flux de données...

Donc il faut les noms de variables et de fonctions...

il est clair que le code source est plus riche que le code binaire... et le cout d'un parseur pour un langage "simple" n'est pas excessif. mais si tu te retrouves à devoir analyser du C++, la simple écriture du parseur sera en soi un projet pharaonique. et si je devais le faire, je préférerais taper dans les binaires et les retransformer dans un sous-ensemble de C

Je dis que toi, tu sous-estimes les problèmes réels, qui sont ce traçage...

je fais des débogeurs formels, et même si ce n'est pas en milieu industriel, je peux t'assurer que je connais bien ce point... plus d'infos par MP si ça t'intéresse (dès que j'aurais publier mon article en cours, enfin s'il est accepté bien sur )

Encore une fois, je suis au regret de te dire que, étant dans un labo, tu ne vis pas l'expérience industrielle..


C'est un fait de la vie de tous les jours, dans l'industrie,de faire de la rétro-ingénierie (pour les raisons sus-dites)..

Je pense que là tu appliques à l'industrie ce que tu crois (et vois dans tes études et au labo), et non pas ce qui s'y passe...

beaucoup de labos bossent régulièrement avec des équipes R&D, et le mien ne fait pas exception à la règle... donc j'ai une petite idée de ce qui se passe dans ce genre d'équipe

pour infos, si tu regardes ceci, rien que le titre de l'article que mon équipe a publié devrait te donner des indications de ce qu'on peut faire au niveau industriel...

D'où ma remarque sur l'utilisation massive de printf...

En un mois, tu as grâce à ça décodé, documenté, identifié peut-être 10 000 ou 20 000 lignes d'un code qui marche.. et partagé l'info (un doc word attaché à un email, ou bien une page Wiki ).

ben suivre les printf, et utiliser des sémantiques de traces, y a quand même un léger rapport entre les deux méthodes


-------


bon j'arrête pour ce débat... je laisse les vrais développeurs industriels continuer sur ce point.
désolé pour l'apparté, en espérant n'avoir heurté aucune sensibilité

[yann2]

Salut

Je vais commencer par mettre ça au clair (un exemple qui montre que le langage naturel peut être perçu d'une manière différente de celle utilisée lorsqu'il a été écrit)

Quand je lis ça, l'exemple que j'ai donné, c'est celui qui me vient à l'esprit.
En gros, je suis un vieux con qui n'a rien compris à la brillance et la jeunesse d'UML...

Je ne suis pas allez aussi loin dans ma pensée. Juste que je me suis demandé si tu lisais ce qu'on écrit. Puisque visiblement tu continues à confondre UML et méthode. Et, effectivement, si tu croises des gens qui utilisent UML comme une méthode, tu ne peux pas avoir un avis positif sur UML ! D'ailleurs GrandFather a très bien résumé je pense.

Surtout, que lorsqu'on parle d'agilité, je pense que ça exclut toute forme d'extrémisme. Dire "UML c'est chouette ça résout tout il faut l'utiliser pour tout", c'est de l'extrémisme. Dire "UML c'est nul ça ne résout rien il ne faut surtout pas l'utiliser", c'est de l'extrémisme.

Je ne voulais pas lancer un aussi gros débat sur UML. Surtout que j'ai bien précisé que c'était sur des micro problèmes et que ça permet facilement de communiquer avec les collègues. Je ne l'ai pas du tout placé au centre d'un quelconque process. D'ailleurs, il me semble que tous les intervenants qui pensent qu'UML peut être utile s'accordent sur ce point (arrêtez moi si je me trompe). Donc ce qui se confronte ici, c'est bien l'avis : "Non il ne faut pas du tout utiliser UML" et l'avis : "Laissez moi utilisez UML pour exprimer mon analyse" (exprimer != réaliser).

Pour moi, c'est juste un outil, rien de plus. Et, je sais que ça ne fait pas le café

Bon, je reviendrai sur la génération de code et l'ingénierie des modèles plus tard ! Je suis trop naze là (1h de bouchon )

Yann

[Garulfo]

[...]Et, je sais que ça ne fait pas le café [...]
Yann

Ce qui est dommage. Sinon je l'utiliserais.

[rakakabe]

Salut

Pour moi, c'est juste un outil, rien de plus. Et, je sais que ça ne fait pas le café

Yann

, et les methodes et tous les autres trucs specialement dedies aux informaticiens ne sont que des outils pour MIEUX atteindre l'objectif principal d'un projet = rendre service a un autre domaine.

Comme un artisan, il faut des outils, mais tous ont leurs avantages et defauts, faut simplement savoir comment les utiliser. De toute facon, en developpement, on fait plus de l'artisanat que d'industrialisation (toujours du sur-mesure), sinon pourquoi les RAD n'ont plus la cote actuellement ?

[yann2]

Salut

Ce qui est dommage. Sinon je l'utiliserais.

Pense à poser le pied droit avant le pied gauche en te levant. "Ca ne fait pas la café" c'est juste une expression pour dire que tu ne peux pas tout faire avec !

Yann

[ZeRevo]

Une feuille blanche et un stylo, même si c'est spartiate restera toujours un bon moyen pour formuler ses idées quelque soient les méthodes, déjà pour prendre des notes.
S'il y a des bonnes choses à prendre de telle ou telle méthode ou langage ou outil, pourquoi s'en priver.

L'une des précos des méthodes agiles est d'utiliser un tableau blanc. Dans mon équipe on utilise ça et c'est sympa pour partager vite des concepts.

Concernant l'UML j'ai jamais pourquoi il y avait autant de diagrammes et de complexité. J'utilise principalemement 3 diagrammes UML : USE CASE, diagramme de classe et diagramme d'activité; avec le plus de simplicité possible (un voir 2 types de fléches, pas de superflux). D'ailleurs dans le cadre d'un développement agile, si on ferait des diagrammes carrés, on accumulerait de la dette technique, vu qu'à chaque modification le coût en refactoring serait coûteux.

L'un des problèmes auquel je fait face aujourd'hui c'est comment comprendre du code quand on utilise de l'injection à outrance ? Dans notre projet, j'ai découvert que certaines injections n'étaient pas codées mais déduite par le framework (Spring), et le soucis c'est qu'on souhaite réutiliser le code ailleurs sauf qu'il y a des problèmes de conception. Des objets sont instanciés alors qu'on a pas besoin.