Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Modélisation, RAD et génération de code


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Candidat au Club
    Modélisation, RAD et génération de code
    Bonjour

    J'aimerais connaitre l'avis de la communauté sur un sujet dont on parle de plus en plus : les outils de développement rapide, la modélisation et l'avenir de la programmation.

    Aujourd'hui, de plus en plus d'entreprises externalisent et délocalisent la production de code. Les métiers purement techniques sont de moins en moins recherchés, du moins sous la forme du développement pur.

    Je suis très intéressé par cette thématique, c'est pourquoi je me suis informé et j'ai découvert tout type d'outils, allant de la modélisation UML simple (diagramme de classe et génération de POJOs) à de la programmation avec l'approche MDA (Model Driven Architecture) et de la génération de code avec JET, en passant par la génération de code à partir d'interfaces graphiques à la VB (Drag & Drop).

    Ce topic a plusieurs objectifs. D'une part connaitre la "température" générale du secteur (a la fois les grands comptes et également les petits éditeurs et SSII), et également connaitre les trouvailles de chacun et l'avis de chacun quant à l'avenir de la programmation.

    Bien sûr, certains pourront dire qu'il est abominable de délocaliser tout le développement d'application, mais je pense qu'au contraire nous devons nous adapter et évoluer dans le sens de la modélisation. J'ai notamment pu observer les solutions proposées par plusieurs éditeurs tels que IBM et son IDE RSA. Cela semble se développer dans le bon sens et associé avec des produits OpenSource tels que JET, il semble à portée de main, à partir d'une bonne modélisation, de générer des applications complètes.

    Ce qui manque de façon évidente, c'est d'une part des distributions fiables et globales et également les ponts pour aller de la modélisation à l'implémentation de frameworks aussi divers et variés que Struts, JSF, Velocity, Behive, mais également pouvoir en changeant de "transformateurs" réaliser une application lourde avec Swing ou AWT ou encore RCP...

    Que se passe-t-il dans les autres mondes (autres que la nébuleuse J2EE) dans ce domaine ?

    Enfin, quels outils utilisez vous pour modéliser vos application ? Utilisez vous du retro engeneering pour que la modélisation suive l'évolution du développement au cours d'un projet? Utilisez vous la génération de code ? Quelles référence utilisez vous pour vous former à la modélisation (UML, MDA...) ?

    Damien

  2. #2
    Expert éminent sénior
    Le message est un peu confus je ne vois pas ou tu veux en venir
    Citation Envoyé par damien.cuvillier
    Aujourd'hui, de plus en plus d'entreprises externalisent et délocalisent la production de code. Les métiers purement techniques sont de moins en moins recherchés, du moins sous la forme du développement pur.
    Damien
    De plus en plus j'en doute...délocaliser un projet n'est pas forcément la panacée.
    C'est valable pour les gros projets par exemple bancaires mais pas pour des petits qui ne mobilisent qu'une poignée de programmeurs.
    En plus il y a des problèmes culturels inhérents.

    Ceci dit oui si tu veux délocaliser un projet il faut un cahier des charges et analyse bétons et surtout des responsables de projet capable d'encadrer une équipe.

    Et tu parles de RAD c'est une bonne allusion car des outils qui permettent de batir des projets en théorie rapidement et générer du code n'ont pas besoin de grand apprentissage d'ou le risque de délocalisation de projets vers des pays à cout de main d'oeuvre moindre.
    Pour Java j'avais fait la remarque dans le débat C++/Java : c'est le langage par excellence de délocalisation de projet mais on m'avait reproché de faire du hors-sujet
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  3. #3
    Expert confirmé
    Tes questions sont très interessantes mais cela me demanderai un véritable travail de répondre point par point à tes questions , alors je préfère résumer ma vision ainsi :

    "Une nouvelle ère dans le développement des logiciels a été amorcée. Il s'agit de recentrer les efforts sur la modélisation plutôt que la programmation. La raison est que la modélisation est bien plus proche du mode de raisonnement humain que ne l'est la programmation ou en d'autres termes, c'est à la machine de se mettre à la portée de l'homme, et non l'inverse."
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  4. #4
    Membre éclairé
    Bonjour damien.cuvillier,
    je vais te donner mon avis qui n'engage que moi, pour moi et mon équipe.

    L'externalisation c'est bien (Attendez tirez pas tout de suite) pour les gros projets, gros comptes. Ca demande beaucoup de préparation avant l'exploitation. Ce n'est pas à l'avantage direct des développeurs français.

    Ensuite, il est bien heureux que de plus en plus l'approche du travail de développeur passe par une phase de modélisation. Ca évite de voir des codes imbuvables, plein de bugs, et non-upgradable (tu veux une autre version = tu recommence tout).

    Enfin, l'avantage des RAD maintenant c'est que l'on y trouve des produits performants et simple d'utilisation. Je sais que certain de mes collègues utilisent des outils comme PowerAMC ou Rose mais cela uniquement dans le but de générer une doc claire et facilement modifiable en 2 clicks. Personnellement, j'ai "découvert" récemment FileMaker Pro Advanced 8.5 et c'est très agréable.
    Le monde se divise en deux: ceux qui utilisent le tag et les autres.

  5. #5
    Futur Membre du Club
    Outil MDA RAD
    Dans la catégorie des outils MDA orientés RAD il y a aussi Leonardi de la société Lyria qaui peut etré téléchargé gratuitement http://www.lyria.com , mais c'est dans le monde Java J2EE. En dehors (.NET par ex; je ne sais pas ce qu'il existe)

  6. #6
    Candidat au Club
    Hey, dites les gens, il faudrait voir à pas foncer tête baissée vers tous les mirages marketings que vous voyez dans 01 informatique ou SVM.

    Ca fait bien 2 ans que les bloggeurs anglophones (autant dire, en IT, le reste du monde) s'accordent à dire que MDA ça n'est que du vent, et malgré tout, les legendes de "grands comptes" générant du code automatiquement persistent sur les forums. Pour le fun j'aimerai bien voir des "faits" et non des vagues rumeurs. Ou des affirmations gratuites comme "Aujourd'hui, de plus en plus...". Hein damien ?

    Ensuite :

    - "MDA is not a silver bullet". Pourquoi ? Toute abstraction finit par faillir à un moment ou un autre. Il est impossible de complètement de capturer toute la complexité d'un programme par la modélisation, quel que soit l'outil ou la méthode. Et cela restera vrai probablement à jamais, faut se le rentrer dans la tête une bonne fois pour toutes.

    - Les projets d'externalisation qui fonctionnent sont ceux qui concernent la maintenance d'un produit "fini" uniquement. Et encore. L'idée que l'ont puisse découpler l'activité de modélisation de l'activité de programmation, activités inextricablement liées et iteratives, est un pur fantasme de DSI issu d'un milieu non technique qui ne comprends rien à l'informatique et qui croit qu'on construit un logiciel comme on construit un pont.

    - La vérité est dans les livres. Malheureusement, beaucoup de conneries sont aussi dans les livres. Ceci dit, sachez qu'une grande partie des problemes qui semblent nouveaux sont décrits depuis environ 20 ou 30 ans.

    - Désolé de vous décevoir, mais l'ingénerie logicielle est grosso dans le même état de performance depuis des années et des années. Ni la programmation objet, ni les IDE, les RAD, les framework ou autre plateformes n'ont fait diminuer le taux d'échec des projets ou les surcouts.

    Il n'y a pas de "nouvelle ère". Il n'y en aura pas de sitot. En attendant, la situation n'est pas désespérée. Mais un peu de sagesse et de recul est nécessaire.

  7. #7
    Expert éminent sénior
    Il est EVIDENT qu'il n'y aura jamais de solution miracle.

    Je n'ai JAMAIS vu au cours de ma carrière une modélisation qui marche. Oh bien sûr, ça permet de faire de belles présentations, d'être dans le vent, de se dire qu'on ne peut pas échouer, qu'on a tout sous contrôle, qu'on est sûr des délais..... Et c'est une ILLUSION.....

    Quant aux RAD et autres EDI, ils peuvent faciliter la programmation (et encore, je pense que ça n'est utilisé réellement que parce qu'on utilise du personnel qu'on a formé à ça, et pas à la réflexion dans l'absolu (ou là là je sens venir les flammes .... )), mais ils ne garantissent en rien ni l'écriture d'un code propre, ni l'absence de bug, ni la maintenabilité....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  8. #8
    Membre éprouvé
    ce que je pourrais juste ajouter encore d'apres mon experience,
    c'est que ce sont les hommes dans le projet qui font la difference, pas les outils qu'ils utilisent.

    Beaucoup de gens autour de moi pensent que le framework abc va resoudre tous leur probleme, en partie c'est vrai ils corrigent certains problemes, et en generent souvent pas mal d'autres.

    Pareil pour la modelisation, c'est bien pour une vue d'ensemble, maintenant il faut des programmers qui tiennent la route derriere sinon c'est voué a l'echec.

    C'est justement la tendance du moment de croire qu'on peut avoir des programmers moyens voire debutants si on a de bons architectes.

    d'autre part, si l'architecte et les programmers ne sont pas ensemble, alors l'architecte perdra en experience inevitablement.

    a+

  9. #9
    Expert confirmé
    J'ai précisé qu'une nouvelle ère avait été amorcée avec une ébauche de reflexion collective autour du développement centré-modèles. (le MDA n'est qu'une vision parmis d'autres). Je n'ai pas dis que l'on était dans une nouvelle ère. D'ailleurs, comme tu le fais remarquer ces technologies sont encore immatures et n'interessent évidemment pas l'industrie.

    Simplement moi je réponds à la question du topic : "l'avenir de la programmation".
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  10. #10
    Expert éminent sénior
    Qui a dèjà vu dans sa vie une analyse ou spec système qui tienne la route jusqu'à la livraison ???????

    Et de plus , comme le dit Epsilon, et comme j'avais mentionné en filigrane, tout dépend des HOMMES...

    tu peux prendre la meilleure technologie possible, si les mecs qui l'utilise sont pas au top, eh ben ça marche pas....

    Je me souviens d'avoir été consultant sur un très gros projet (16 ans de projet. équipe de 60 personnes. 2 millions de ligne de code. 75 millions d'euros de budget. Normes de gestion, Normes de programmation, Normes de documentation). Appelé à l'aide car finalement utilisateurs voulaient même pas tester l'appli. car trop compliquée. En 8 mois à 6 on refait 75% de l'appli (sans normes de gestion,et avec normes "élastiques" pour le reste). Satisfaction des utilisateurs (qui veulent nous acheter ce qu'on a fait). 8 mois restent avant la date de sortie du logiciel. Là le Directeur nous dit "oui, mais vous, vous coûtez trop cher". Ce à quoi on lui répond : "On est 6. On demande 4 personnes de plus, mais des comme nous et on vous GARANTI que le programme sera prêt". Décision du Directeur : il prend 20 jeunes débutants (moins cher) de plus (donc équipe de 80 personnes), et met fin à notre contrat. Résultat : 8 mois plus tard, date de livraison dépassée, et faillite. La boîte a fermé. )

    C'est une constante du développement et des DSI ou autres dirigeants. Croire que, dans la production de logiciels, tout le monde est remplaçable, comme dans une chaîne d'usine. c'est FAUX.

    Et donc croire qu'il exsterait une solution miracle due aux outils est une absurdité en soi... C'est comme dire (et ça se passe d'ailleurs parallèlement aujourdhui dans notre société), que parce que tu fumes pas, tu bois pas, tu fais du sport, tu mourras pas....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  11. #11
    Membre éprouvé
    Je suis d'accord, meme constat de mon côté.

  12. #12
    Candidat au Club
    Citation Envoyé par Hephaistos007
    Simplement moi je réponds à la question du topic : "l'avenir de la programmation". Toi tu parles du présent alors forcement...
    Pas vraiment, je disais qu'en terme d'efficacite et de productivite, l'avenir est essentiellement equivalent au present, modulo les abbreviations a la mode. Il faut, ceci dit, beaucoup temps et d'introspection de pour arriver a cette conclusion douloureuse mais ineluctable.

    Un ou deux rites de purification peuvent aider a retrouver le chemin de la sagesse.

    Et si vous voulez mon avis, la programmation, c'est trop complique pour la plupart des programmeurs. Ca, ca n'est pas moi qui le dit:

    Citation Envoyé par Edsger W.Dijkstra
    Good programming is probably beyond the intellectual abilities of today's "average programmer".
    Et ca va aller en empirant, grace aux futurs processeurs multicoeurs et a la programmation parrallele. Voila ce qui vous attend veritablement, et ca sera aussi bordelique que les jours presents.

    Les bugs et le code pourri ont encore de magnifiques decennies devant eux.

  13. #13
    Rédacteur en Chef

    D'après mes informations, il y à quand meme plus de 50% des grandes entreprise qui ont standardisé sur UML, c'est quand même pas rien.

    Et sur UML il faut aussi faire attention, les outils ne sont pas équivalents les uns des autres. Certains outils (chers) pour UML sont extrémement efficaces, et permettent non seulement la génération de code à partir d'UML mais surtout avec le même outil le réverse enginering qui permet à partir du code de mettre à jour la partie UML, bref ce qu'on appelle un outil bi-directionnel.

    C'est façile d'avoir une mauvaise opinion d'une technologie qu'on ne maitrise pas bien, et en utilisant un mauvais outil de surcrois (ou un outil incomplet ou bas de gamme).

    Mais quand on maitrise une technologie, et qu'on utilise un outil à la pointe, il y à des résultats.

    De toute façon si aussi bien un développeur tout seul peu faire n'importe quoi dans son coin, et c'est en effet très courant (et alors la bonjour pour la pérénité de l'application si elle doit etre reprise), dans la mesure ou on est sur un grand projet, des méthodes sont indispensables, aussi bien pour l'écriture de code, que pour la gestion du travail en équipe.

    Bon maintenant comme il à été écrit plus haut, dans la profession il y à des "bons" et des "moins bons", et c'est possible d'avoir une équipe qui rate avec des méthodes, et des équipes qui réussissent sans, parce que des méthodes ou des outils ne peuvent pas remplacer le talent.

    Ressources :

    UML (et MDA). Le Forum UML.

    SCM / gestion de projets. La F.A.Q SCM. Le Forum SCM.
    Ne pas me contacter pour le forum et je ne répondrai à aucune question technique. Pour contacter les différents services du club (publications, partenariats, publicité, ...) : Contacts

    15 000 offres d'emploi développeurs et informatique
    Cours et tutoriels développeurs et informatique
    Les FAQ's & Les Livres
    Codes sources
    Téléchargements

  14. #14
    Expert confirmé
    Citation Envoyé par fabien-b
    Et si vous voulez mon avis, la programmation, c'est trop complique pour la plupart des programmeurs. Ca, ca n'est pas moi qui le dit:
    Et ca va aller en empirant, grace aux futurs processeurs multicoeurs et a la programmation parrallele. Voila ce qui vous attend veritablement, et ca sera aussi bordelique que les jours presents.
    En gros tu dis la même chose que moi. L'informatique va se compexifier de plus en plus et il importe de pouvoir maitriser cette complexité par des abstractions. Il n'est pas envisageable d'appliquer les méthodes actuelles sur les projets de demain. Heureusement que les chercheurs se bougent le cul à votre place ...
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  15. #15
    Membre éprouvé
    Citation Envoyé par Hephaistos007
    L'informatique va se compexifier de plus en plus et il importe de pouvoir maitriser cette complexité par des abstractions. Il n'est pas envisageable d'appliquer les méthodes actuelles sur les projets de demain. Heureusement que les chercheurs se bougent le cul à votre place ...
    C'est ce qu'on arrete pas de dire que ca se complexifie, alors on mets des frameworks pour abstraire ... des fois c'est bien des fois c'est beaucoup moins drole. A la fin ce qu'on sait c'est qu'il y a plein de fichier XML partout, et qu'a la fin je ne sais pas ce qu'ils apportent tellement ces frameworks.

    Maintenant pour les multi coeurs, he bien je ne vois que OpenMP dans l'immediat et bien sur les threads, mais la c'est bien le talent des programmers qui vont faire la difference. J'en connais beaucoup qui disent qu'une boucle for c'est de l'algorithme alors ....

    et puis les projets de demain, bien malin qui pourra nous dire a quoi ils ressembleront... certainement a ceux d'hier vu qu'on n'invente strictement rien ....

    La modelisation UML et Shema de classe oui, un grand oui.
    les diagrammes de sequence, oui oui oui.

    ... mais destinés à une doc d'architecture, pour donner les lignes a suivre et decrire un probleme et quelques lignes d'implementation.

    Par contre generer du code a travers ces shemas UML, non un grand non.
    Tout d'abord parce qu'il y a toujours des problemes d'implementation, et qu'il faudra toujours des vrais programmers pour y repondre, enfin plutot des vrais developers, ceux qui n'ecrivent pas betement des lignes d'ecritures ...

    Je trouve ce débat intéressant parce qu'il montre bien une tendance qui est de tout vouloir modeliser et que le code soit fait "automatiquement"

    Derriere cette volonté de tout modeliser a l'extreme, il y a l'offshore en demi-teinte, puis le desir obsessionel de documentation pour ne plus etre dependant de aucun programmer, ou tout du moins pouvoir les rendre interchangeable.

    Par experience, je sais que cela ne marche pas, et que je reserve cette modelisation pour des documents d'architecture. Maintenant modelisation represente pour moi une vision plus reducteur (UML) que pour d'autre.

    Je repondais franchement simplement d'une personne donnant son avis sur le sujet avec un peu d'experience (je pense) la autour.

  16. #16
    Membre habitué
    Bien sûr que les projets basés sur la modélisation marchent ! (Dans l'aéronautique, il n'y a pratiquement que ça).
    Et s'il y a de plus en plus d'outils dits Model-Driven, c'est parce que le marché devient mature.
    Quand à croire que c'est une tactique pour faire de l'offshore, c'est justement l'inverse !
    Si nous n'utilisons pas des outils de développement plus rapides et exigeant des compétences métiers, quel intérêt y-a-t-il pour un gestionnaire moyen de ne pas externaliser ces projets la où la main d'oeuvre coute dix fois moin cher ?

  17. #17
    Rédacteur

    Citation Envoyé par limon

    Quand à croire que c'est une tactique pour faire de l'offshore, c'est justement l'inverse !
    100% d'accord
    a coté de chez moi, on a une boite qui reussi a faire certains projet pour 2 fois moins cher que ce qu'ils faisait chez les indiens il y a de cela quelques années grace a un developpement très fortement basé sur les modèles, mais surtout, sur les transformations de modèles.
    En gros, ils on une grosse base de donnée de connaissances pré-programmée du genre (exemple a la con) transformer automatiquement tel classe en singleton (ca c'est simple), ou encore transformer ces 15 methode en pattern Command etc.
    grace a ca, et a des outils bidirectionnels, il arrive a produire une très grosse majorité de leur code directement depuis les modèles, et quand ca ne va pas, il vont dans le code, le modifient et reviennent sur le modèle.
    bref, dans leur cas, ils ne capitalisent pas sur le fait de pouvoir créer de beau modèles UML, mais sur leur experience en terme de transformation de modèles
    * Il est infiniment plus simple de faire rapidement un code qui marche que de faire un code rapide qui marche
    * pour faciliter les recherches, n'oubliez pas de voter pour les réponses pertinentes
    Mes articles

  18. #18
    Expert éminent sénior
    Je ne crois pas que ce soit pour faire de l'offshore, mais je pense que c'est très très très politique, dans le mauvais sens du terme (comme la fracture sociale, les délocalisations, la précarité... Dans les années 70 c'était le choc pétrolier. Dans les annes 80 c'était "on sort du tunnel"....)

    Je crois que comme toute incantation de ce type, ça ne peut amener qu'à l'échec, car appliquée partout sans discernement.

    Tout chose est bonne, SI ELLE EST APPLIQUEE A CE POURQUOI ELLE A ETE FAITE AU DEPART, et éventuellement à quelques retombées non prévues.. Ce n'est pas la solution miracle des problèmes de conception, de maintenance, etc..


    Mais c'est comme les 35h, comme la supression des 35h, etc.. Quand ça devient un dogme et pas la solution à un problème, c'est rigide et donc inadaptable, et donc à une durée de vie finie.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  19. #19
    Membre éprouvé
    Citation Envoyé par bafman
    100% d'accord
    a coté de chez moi, on a une boite qui reussi a faire certains projet pour 2 fois moins cher que ce qu'ils faisait chez les indiens il y a de cela quelques années grace a un developpement très fortement basé sur les modèles, mais surtout, sur les transformations de modèles.
    ... j'espere que vous avez / aurez raison !
    ce n'est malheureusement pas l'experience que j'en ai

    a+

  20. #20
    Candidat au Club
    Perennisation & pragmatisme
    Ce message n'a pas pu être affiché car il comporte des erreurs.

###raw>template_hook.ano_emploi###